修改配置文件

1	cd /opt/k8s/work/kubernetes/cluster/addons/dashboard

修改 service 定义，指定端口类型为 NodePort，这样外界可以通过地址 NodeIP:NodePort 访问 dashboard；

cat dashboard-service.yaml
apiVersion: v1
kind: Service
metadata:
  name: kubernetes-dashboard
  namespace: kube-system
  labels:
    k8s-app: kubernetes-dashboard
    kubernetes.io/cluster-service: "true"
    addonmanager.kubernetes.io/mode: Reconcile
spec:
  type: NodePort # 增加这一行
  selector:
    k8s-app: kubernetes-dashboard
  ports:
  - port: 443
    targetPort: 8443

修改镜像地址mirrorgooglecontainers/kubernetes-dashboard-amd64:v1.10.1在dashboard-controller.yaml中

执行所有定义文件

1	kubectl apply -f .

查看分配的 NodePort

[root@node1 dashboard]# kubectl get deployment kubernetes-dashboard  -n kube-system

NAME                   READY   UP-TO-DATE   AVAILABLE   AGE

kubernetes-dashboard   1/1     1            1           23h



[root@node1 dashboard]# kubectl --namespace kube-system get pods -o wide
NAME                                    READY   STATUS    RESTARTS   AGE     IP             NODE    NOMINATED NODE   READINESS GATES
coredns-8854569d4-g2hth                 1/1     Running   4          5d22h   172.30.40.2    node1   <none>           <none>
kubernetes-dashboard-7848d45466-6pm2q   1/1     Running   0          23h     172.30.200.3   node2   <none>           <none>
metrics-server-5f7cf7659-59swk          1/1     Running   0          2d5h    172.30.40.3    node1   <none>           <none>


[root@node1 dashboard]# kubectl get services kubernetes-dashboard -n kube-system
NAME                   TYPE       CLUSTER-IP      EXTERNAL-IP   PORT(S)         AGE
kubernetes-dashboard   NodePort   10.254.234.85   <none>        443:32681/TCP   23h

访问 dashboard

1	https://192.168.6.101:32681

创建登录 Dashboard 的 token 和 kubeconfig 配置文件

dashboard 默认只支持 token 认证（不支持 client 证书认证），所以如果使用 Kubeconfig 文件，需要将 token 写入到该文件。

创建登录 token

kubectl create sa dashboard-admin -n kube-system
kubectl create clusterrolebinding dashboard-admin --clusterrole=cluster-admin --serviceaccount=kube-system:dashboard-admin
ADMIN_SECRET=$(kubectl get secrets -n kube-system | grep dashboard-admin | awk '{print $1}')
DASHBOARD_LOGIN_TOKEN=$(kubectl describe secret -n kube-system ${ADMIN_SECRET} | grep -E '^token' | awk '{print $2}')
echo ${DASHBOARD_LOGIN_TOKEN}

使用输出的 token 登录 Dashboard。

创建使用 token 的 KubeConfig 文件

source /opt/k8s/bin/environment.sh
# 设置集群参数
kubectl config set-cluster kubernetes \
  --certificate-authority=/etc/kubernetes/cert/ca.pem \
  --embed-certs=true \
  --server=${KUBE_APISERVER} \
  --kubeconfig=dashboard.kubeconfig

# 设置客户端认证参数，使用上面创建的 Token
kubectl config set-credentials dashboard_user \
  --token=${DASHBOARD_LOGIN_TOKEN} \
  --kubeconfig=dashboard.kubeconfig

# 设置上下文参数
kubectl config set-context default \
  --cluster=kubernetes \
  --user=dashboard_user \
  --kubeconfig=dashboard.kubeconfig

# 设置默认上下文
kubectl config use-context default --kubeconfig=dashboard.kubeconfig

用生成的 dashboard.kubeconfig 登录 Dashboard。

为kubernetes dashboard访问用户添加权限控制

Role

Role表示是一组规则权限，只能累加，Role可以定义在一个namespace中，只能用于授予对单个命名空间中的资源访问的权限。比如我们新建一个对默认命名空间中Pods具有访问权限的角色：

kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""] # "" indicates the core API group
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

ClusterRole

ClusterRole具有与Role相同的权限角色控制能力，不同的是ClusterRole是集群级别的，可以用于:

集群级别的资源控制(例如 node 访问权限)
非资源型 endpoints(例如 /healthz 访问)
所有命名空间资源控制(例如 pods)

比如我们要创建一个授权某个特定命名空间或全部命名空间(取决于绑定方式)访问secrets的集群角色：

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  # "namespace" omitted since ClusterRoles are not namespaced
  name: secret-reader
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]

RoleBinding和ClusterRoleBinding

RoloBinding可以将角色中定义的权限授予用户或用户组，RoleBinding包含一组权限列表(subjects)，权限列表中包含有不同形式的待授予权限资源类型(users、groups、service accounts)，RoleBinding适用于某个命名空间内授权，而 ClusterRoleBinding适用于集群范围内的授权。

比如我们将默认命名空间的pod-reader角色授予用户jane，这样以后该用户在默认命名空间中将具有pod-reader的权限：

# This role binding allows "jane" to read pods in the "default" namespace.
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: read-pods
  namespace: default
subjects:
- kind: User
  name: jane
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

RoleBinding同样可以引用ClusterRole来对当前 namespace 内用户、用户组或 ServiceAccount 进行授权，这种操作允许集群管理员在整个集群内定义一些通用的 ClusterRole，然后在不同的 namespace 中使用 RoleBinding 来引用

例如，以下 RoleBinding 引用了一个 ClusterRole，这个 ClusterRole 具有整个集群内对 secrets 的访问权限；但是其授权用户 dave 只能访问 development 空间中的 secrets(因为 RoleBinding 定义在 development 命名空间)

# This role binding allows "dave" to read secrets in the "development" namespace.
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: read-secrets
  namespace: development # This only grants permissions within the "development" namespace.
subjects:
- kind: User
  name: dave
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

最后，使用 ClusterRoleBinding 可以对整个集群中的所有命名空间资源权限进行授权；以下 ClusterRoleBinding 样例展示了授权 manager 组内所有用户在全部命名空间中对 secrets 进行访问

# This cluster role binding allows anyone in the "manager" group to read secrets in any namespace.
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: read-secrets-global
subjects:
- kind: Group
  name: manager
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

例子

新增一个新的用户sy
该用户只能对命名空间kube-system下面的pods和deployments进行管理

第一步新建一个ServiceAccount：

1 2	[root@node1 dashboard]# kubectl create sa sy -n kube-system serviceaccount/sy created

然后我们新建一个角色role-sy：(role.yaml)

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: kube-system
  name: role-sy
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]
- apiGroups: ["extensions", "apps"]
  resources: ["deployments"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

注意上面的rules规则：管理pods和deployments的权限。

然后我们创建一个角色绑定，将上面的角色role-sy绑定到**sy**的ServiceAccount`上：(role-bind.yaml)

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: role-bind-sy
  namespace: kube-system
subjects:
- kind: ServiceAccount
  name: sy
  namespace: kube-system
roleRef:
  kind: Role
  name: role-sy
  apiGroup: rbac.authorization.k8s.io

分别执行上面两个yaml文件：

[root@node1 dashboard]# kubectl create -f role.yaml
role.rbac.authorization.k8s.io/role-sy created
[root@node1 dashboard]# kubectl create -f role-bind.yaml 
rolebinding.rbac.authorization.k8s.io/role-bind-sy created

接下来该怎么做？和前面一样的，我们只需要拿到sy这个ServiceAccount的token就可以登录Dashboard了：

[root@node1 dashboard]# kubectl get secret -n kube-system |grep sy
sy-token-5cmnl                                   kubernetes.io/service-account-token   3      3m2s

[root@node1 dashboard]# kubectl get secret sy-token-5cmnl  -o jsonpath={.data.token} -n kube-system |base64 -d
# 会生成一串很长的base64后的字符串

这样就可以控制权限了，需要将登录地址改为namespace=kube-system