概述
前面介绍了kubernetes的两个东西，认证和授权
在kubernetes中我们对API server的一次访问大概会包含哪些信息？简单来讲它是restfule风格接口，也就是某个用户对某个操作执行了某个操作。 subject --> action --> object
- 因此我们授权定义也是围绕这种方式展开的，同时我们也不能允许所有用户随意就能够访问我们k8s
- 所以我们讲到了认证，讲到了它的两种认证方式，第一种叫token，一种叫证书认证，即tls，当然还有第三种方式认证，账号和密码（user/passwd），这种方式很少用。重点介绍了tls认证，并且我们还自己建了证书而且构建了一个所谓的基于kubectl 访问的内部账号，但是在此我们需要交代的是我们用户账号有两类，第一类叫UserAccount（虽然存在于k8s之上但是我们不需要单独去创建它，它只是一个对应的用户身份标识，无论通过token还是tls认证完以后用户宣称自己是什么用户他就是什么用户），第二类称为ServiceAccount，也叫sa
授权的方式RBAC
- 其有四个标准的资源：role，rolebinding，clusterrole，clusterrolebinding
- 能够作为授权中的subject使用的大概有三类主体，第一类称为用户（user），第二类称为组（group），第三类称为serviceaccount
- 还有我们k8s上的三种资源object： resouce_group resource non-resource url
- 在role或者clusterrole之上我们定义的是能够对哪些对象执行哪些操作，所以接下来就是action:有get，list，watch,path,delete,deletecollection等
- rolebinding或者clusterrolebinding就是为了指明subject，指明role或者clusterrole以及怎么绑
Dashboard
到目前为止我们一直都是用kubernetes的kubectl或者使用kube proxy或者使用curl命令在命令行中去请求k8s的api，我们dashboard是作为我们kubernetes的核心附件（addons）存在的，我们系统安装时就默认就自动安装了一个附件叫做coredns，coredns是作为名称解析和服务发现的一个非常重要的凭据。在1.10及以前的版本中它用的是kube-dns，在1.8之后我们去部署kube-dashboard时它有个更复杂的权限检查了，传统的我们在互联网上看到的开放访问的方式大都不一定支持了，所以我们把它放到最后来讲因为kubeadm部署安装的k8s集群默认是强制启用的RBAC的，而dashbord它的接口是管理整个k8s集群的接口，所以他在实现认证和管理时不是自我认证的，可以认为它只是一个k8s集群的前端，也就是说你登陆dashbord时输入的账号和密码一定是k8s之上的账号和密码，和k8s的dashboard自身没有任何关系，它自己不做认证，它是一个认证代理，所有的账号都应该是k8s之上的账号，所有的授权应该也都是k8s之上的授权
部署一个dashboard，首先我们使用一个在线的配置清单，它会根据定义去下载镜像
拉取镜像
docker pull mirrorgooglecontainers/kubernetes-dashboard-amd64:v1.10.1
重新打标签
tag mirrorgooglecontainers/kubernetes-dashboard-amd64:v1.10.1 k8s.gcr.io/kubernetes-dashboard-amd64:v1.10.1
删除无用镜像
docker rmi mirrorgooglecontainers/kubernetes-dashboard-amd64:v1.10.1
部署 dashboard
kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v1.10.1/src/deploy/recommended/kubernetes-dashboard.yaml
看dashboard的POD是否正常启动，如果正常说明安装成功
kubectl get pods --namespace=kube-system
