Kubernetes 学习17 dashboard认证及分级授权

一、概述

　　1、我们前面介绍了kubernetes的两个东西，认证和授权

　　2、在kubernetes中我们对API server的一次访问大概会包含哪些信息？简单来讲它是restfule风格接口，也就是某个用户对某个操作执行了某个操作。 subject --> action --> object。

　　　　a、因此我们授权定义也是围绕这种方式展开的，同时我们也不能允许所有用户随意就能够访问我们k8s。

　　　　b、所以我们讲到了认证，讲到了它的两种认证方式，第一种叫token，一种叫证书认证，即tls，当然还有第三种方式认证，账号和密码（user/passwd），这种方式很少用。重点介绍了tls认证，并且我们还自己建了证书而且构建了一个所谓的基于kubectl 访问的内部账号，但是在此我们需要交代的是我们用户账号有两类，第一类叫UserAccount（虽然存在于k8s之上但是我们不需要单独去创建它，它只是一个对应的用户身份标识，无论通过token还是tls认证完以后用户宣称自己是什么用户他就是什么用户），第二类称为ServiceAccount，也叫sa。

　　　　c、我们讲了授权的方式RBAC

　　　　　　1）、其有四个标准的资源：role，rolebinding，clusterrole，clusterrolebinding。

　　　　　　2）、能够作为授权中的subject使用的大概有三类主体，第一类称为用户（user），第二类称为组（group），第三类称为serviceaccount。

　　　　　　3）、还有我们k8s上的三种资源object： resouce_group   resource  non-resource url

　　　　　　4）、在role或者clusterrole之上我们定义的是能够对哪些对象执行哪些操作，所以接下来就是action:有get，list，watch,path,delete,deletecollection等...

　　　　　　5）、rolebinding或者clusterrolebinding就是为了指明subject，指明role或者clusterrole以及怎么绑。

二、Dashboard

　　1、到目前为止我们一直都是用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之上的授权。

　　2、部署一个dashboard，首先我们使用一个在线的配置清单，它会根据定义去下载镜像。

[root@k8smaster ~]# kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v1.10.1/src/deploy/recommended/kubernetes-dashboard.yaml
secret/kubernetes-dashboard-certs created
serviceaccount/kubernetes-dashboard created
role.rbac.authorization.k8s.io/kubernetes-dashboard-minimal created
rolebinding.rbac.authorization.k8s.io/kubernetes-dashboard-minimal created
deployment.apps/kubernetes-dashboard created
service/kubernetes-dashboard created

[root@k8smaster ~]# kubectl get pods --all-namespaces -o wide |grep dash
kube-system     kubernetes-dashboard-5dd89b9875-tfqvw      /       Running             2m        10.244.1.157    k8snode1

　　　　a、我们看一下部署脚本

[root@k8smaster ~]# cat kubernetes-dashboard.yml
# Copyright  The Kubernetes Authors.
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
#     http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.

# ------------------- Dashboard Secret ------------------- #

apiVersion: v1
kind: Secret
metadata:
  labels:
    k8s-app: kubernetes-dashboard
  name: kubernetes-dashboard-certs
  namespace: kube-system
type: Opaque

---
# ------------------- Dashboard Service Account ------------------- #

apiVersion: v1
kind: ServiceAccount
metadata:
  labels:
    k8s-app: kubernetes-dashboard
  name: kubernetes-dashboard
  namespace: kube-system

---
# ------------------- Dashboard Role & Role Binding ------------------- #

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: kubernetes-dashboard-minimal
  namespace: kube-system
rules:
  # Allow Dashboard to create 'kubernetes-dashboard-key-holder' secret.
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["create"]
  # Allow Dashboard to create 'kubernetes-dashboard-settings' config map.
- apiGroups: [""]
  resources: ["configmaps"]
  verbs: ["create"]
  # Allow Dashboard to get, update and delete Dashboard exclusive secrets.
- apiGroups: [""]
  resources: ["secrets"]
  resourceNames: ["kubernetes-dashboard-key-holder", "kubernetes-dashboard-certs"]
  verbs: ["get", "update", "delete"]
  # Allow Dashboard to get and update 'kubernetes-dashboard-settings' config map.
- apiGroups: [""]
  resources: ["configmaps"]
  resourceNames: ["kubernetes-dashboard-settings"]
  verbs: ["get", "update"]
  # Allow Dashboard to get metrics from heapster.
- apiGroups: [""]
  resources: ["services"]
  resourceNames: ["heapster"]
  verbs: ["proxy"]
- apiGroups: [""]
  resources: ["services/proxy"]
  resourceNames: ["heapster", "http:heapster:", "https:heapster:"]
  verbs: ["get"]

---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: kubernetes-dashboard-minimal
  namespace: kube-system
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: kubernetes-dashboard-minimal
subjects:
- kind: ServiceAccount
  name: kubernetes-dashboard
  namespace: kube-system

---
# ------------------- Dashboard Deployment ------------------- #

kind: Deployment
apiVersion: apps/v1
metadata:
  labels:
    k8s-app: kubernetes-dashboard
  name: kubernetes-dashboard
  namespace: kube-system
spec:
  replicas:
  revisionHistoryLimit:
  selector:
    matchLabels:
      k8s-app: kubernetes-dashboard
  template:
    metadata:
      labels:
        k8s-app: kubernetes-dashboard
    spec:
      containers:
      - name: kubernetes-dashboard
        image: k8s.gcr.io/kubernetes-dashboard-amd64:v1.10.1
        ports:
        - containerPort:
          protocol: TCP
        args:
          - --auto-generate-certificates
          # Uncomment the following line to manually specify Kubernetes API server Host
          # If not specified, Dashboard will attempt to auto discover the API server and connect
          # to it. Uncomment only if the default does not work.
          # - --apiserver-host=http://my-address:port
        volumeMounts:
        - name: kubernetes-dashboard-certs
          mountPath: /certs
          # Create on-disk volume to store exec logs
        - mountPath: /tmp
          name: tmp-volume
        livenessProbe:
          httpGet:
            scheme: HTTPS
            path: /
            port:
          initialDelaySeconds:
          timeoutSeconds:
      volumes:
      - name: kubernetes-dashboard-certs
        secret:
          secretName: kubernetes-dashboard-certs
      - name: tmp-volume
        emptyDir: {}
      serviceAccountName: kubernetes-dashboard
      # Comment the following tolerations if Dashboard must not be deployed on master
      tolerations:
      - key: node-role.kubernetes.io/master
        effect: NoSchedule

---
# ------------------- Dashboard Service ------------------- #

kind: Service
apiVersion: v1
metadata:
  labels:
    k8s-app: kubernetes-dashboard
  name: kubernetes-dashboard
  namespace: kube-system
spec:
  ports:
    - port:
      targetPort:
  selector:
    k8s-app: kubernetes-dashboard

　　　　b、可以看到最后的这个service类型为clusterIP类型，我们需要将其改为nodeport类型

[root@k8smaster ~]# kubectl patch svc kubernetes-dashboard -p '{"spec":{"type":"NodePort"}}' -n kube-system
service/kubernetes-dashboard not patched

　　3、登陆。

　　　　a、然后从外部登陆，可以看到有两种登陆认证方式。可以看到我们的kubectl就能使用kubeconfig认证，我们可以把我们的kubectl中的kubeconfig拿过来放到宿主机上然后载入即可。我们的kubeconfig拥有什么权限这儿就有什么权限。我们的admin的kubeconfig文件为 /root/.kube/config，载入即可。

　　　　　　

　　　　b、载入时我们会发现有报错而无法登陆,提示没有足够的认证信息来进行认证。其实我们可以创建一个专门的文件来进行加载，默认情况下我们admin的config文件应该是没有问题的，这个文件因为我们自己修改过所以有点问题。

　　　　　　

　　　　c、那么我们需要怎么来做呢？第一步，虽说其工作在这个接口之上，因为这个dashboard在部署时有可能它提供https服务的证书得是我们当前这个CA签署并认可的证书，如果不是当前CA签署的证书我们部署完以后一定会有问题的，就是上述报错现象。如果新版本没有改变过那我们部署dashboard的时候像这种部署方式就需要提前给它创建一个secret，用我们当前系统上的CA给它做授权，然后利用当前系统上的CA发的证书来提供https服务它才能认证我们这儿的kubeconfig配置文件。

　　　　d、首先我们先删掉我们部署的这个dashboard

[root@k8smaster ~]# kubectl delete -f kubernetes-dashboard.yml
secret "kubernetes-dashboard-certs" deleted
serviceaccount "kubernetes-dashboard" deleted
role.rbac.authorization.k8s.io "kubernetes-dashboard-minimal" deleted
rolebinding.rbac.authorization.k8s.io "kubernetes-dashboard-minimal" deleted
deployment.apps "kubernetes-dashboard" deleted
service "kubernetes-dashboard" deleted

　　4、（此章节为坑）重做一下config文件，如果这个版本没有改变那么我们接下来应该做的步骤是这样的。

　　　　a、在/etc/kubernetes/pki/目录下给我们dashboard创建一个专用的证书。首先生成一个私钥

[root@k8smaster /]# cd /etc/kubernetes/pki/
[root@k8smaster pki]# ls
apiserver.crt              apiserver-etcd-client.key  apiserver-kubelet-client.crt  ca.crt  ca.srl  front-proxy-ca.crt  front-proxy-client.crt  sa.key  wohaoshuai.crt  wohaoshuai.key
apiserver-etcd-client.crt  apiserver.key              apiserver-kubelet-client.key  ca.key  etcd    front-proxy-ca.key  front-proxy-client.key  sa.pub  wohaoshuai.csr
[root@k8smaster pki]# (umask ;openssl genrsa -out dashboard.key )
Generating RSA private key,  bit long modulus
.....................................+++
...........................+++
e is  (0x10001)
[root@k8smaster pki]# 

　　　　b、我们需要给他生成一个证书签署请求就靠当前apiserver的CA来签证，不然我们的dashboard中内部的https他会自己生成一个证书，这个自己生成的证书用kubeconfig认证时是认证不通过的，刚刚不通过的原因就是这样的，因此第二部我们需要去建立一个证书签署请求

[root@k8smaster pki]# openssl req -new -key dashboard.key -out dashboard.csr -subj "/O=wohaoshuai/CN=dashboard" #将来如果要用域名访问时域名一定要和CN定义的保持一致，比如CN=ui.wohaoshuai.com时就使用ui.wohaoshuai.com来访问

　　　　c、现在我们需要给这个证书签证，用我们系统上自己的ca.crt和ca.key签，签完以后这个证书要拿来让我们的dashboard提供https服务

[root@k8smaster pki]# openssl x509 -req -in dashboard.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out dashboard.crt -days
Signature ok
subject=/O=wohaoshuai/CN=dashboard
Getting CA Private Key

　　　　d、我们现在需要把刚才生成的私钥和证书创建成为一个secret，这个secret是什么类型呢？我们之前说过secret一共有三种类型，这儿我们需要创建一个TLS类型的证书，我们虽然认为需要创建TLS格式的证书但是由于它内部在dashboard，dashboard是一个应用程序，它是在应用程序内部使用的，不是简单的配置为https服务，因此这儿我需要给其定义成为generic，接下来我们开始创建

[root@k8smaster pki]# kubectl create secret generic dashboard-cert -n kube-system --from-file=dashboard.crt=./dashboard.crt --from-file=dashboard.key=./dashboard.key
secret/dashboard-cert created

　　　　e、接下来我们部署我们的dashboard，来完成应用，但是在应用时我们需要特别指定它去加载我们对应的dashboard，加载我们对应的文件（即刚刚定义的secret）为我们对应的https提供的应用。

　　5、解释一下刚才的概念，假如我们有一个集群，dashboard自身是作为一个pod在运行，这个pod自己是不做认证的，我们必须为其提供https倒不是最关键的一点，而是说他既然自己必须运行为pod那么我们用户通过浏览器来进行登录时刚才之所以不能认证并不是因为这个pod使用的不是我们自己定义的证书而导致的，而是因为我们提供的证书必须里面的账号是一个ServiceAccount，哪怕你在浏览器里登录去提供的这个证书中的主体，我们此前复制过来的那个config文件它是一个userAccount，里面是一个kubernetes-admin用户，或者是一个叫wohaoshuai的用户，这两个是代表两个正常的用户账号，他们不是ServiceAccount账号，所以这就导致不能登录，而不是第一次解释说dashboard中运行必须额外定义由我们自己的CA签署的证书，因为无论谁签署的证书我们选择信任就可以了。我们在nginx上部署应用的时候，比如我们在nginx上自己做一个CA，给我们的nginx发了证书，做了私钥，然后让nginx配置为https登陆的时候因为物理机可能不信任这个签证CA，它会提示我们说可能不安全有风险，但是我们点击继续前往照样能打开，所以这儿不是这个问题导致的。因此这儿不能登陆的原因应该是我们提供的所谓的kubeconfig配置文件里的账号它不是一个serviceAccount而是一个useraccount导致的。这儿因为我们dashboard是一个pod我们所提供的信息是让我们的pod认证到我们的k8s集群上去的，而不是让我们自己认证，是让pod认证到k8s集群上去的。因此我们这儿需要给这个dashboard pod提供一个kubeconfig，当然其主体必须是一个serviceaccount。

　　　　因此我们刚刚其实可以不用delete掉dashboard，也意味着我们后面只需要补充创建一个secret，这个secret之所以定义成generic是因为我们等一会儿需要把这个证书和我们的私钥文件定义成一个serviceaccount。

　　6、说到这儿我们再来先说一下token认证

　　　　a、就算是要做token认证我们也需要创建一个serviceaccount

[root@k8smaster pki]# kubectl create serviceaccount dashboard-admin -n kube-system
serviceaccount/dashboard-admin created

　　　　b、接下来我们需要通过所谓的rolebinding把这个dashboard-admin和我们的集群管理员建立起绑定关系来，不然它无法透过我们的rbac的权限检查。什么意思呢？dashboard接下来部署完以后登录进来后期望dashboard做什么事？假如我要做整个集群的管理，做整个集群的管理也就意味着运行此pod的serviceaccount应该具有整个集群的访问权限，所以我们就需要把这个dashboard-admin使用clusterrolebinding绑定在cluster-admin这个角色上，因此我们接下来做第二步，把我们serviceaccount绑定在cluster-admin这个集群角色上

[root@k8smaster pki]# kubectl create clusterrolebinding dashboard-cluster-admin --clusterrole=cluster-admin --serviceaccount=kube-system:dashboard-admin
clusterrolebinding.rbac.authorization.k8s.io/dashboard-cluster-admin created

　　　　c、绑定完过后我们接下来就可以获取对应的serviceaccount的secret的信息并且我们通过这个secret就可以访问集群了。

[root@k8smaster pki]# kubectl describe secret dashboard-admin-token-vb26s -n kube-system
Name:         dashboard-admin-token-vb26s
Namespace:    kube-system
Labels:       <none>
Annotations:  kubernetes.io/service-account.name=dashboard-admin
              kubernetes.io/service-account.uid=4f81561a-b81e-11e9--000c29d142be

Type:  kubernetes.io/service-account-token

Data
====
ca.crt:      bytes
namespace:   bytes
token:      eyJhbGciOiJSUzI1NiIsImtpZCI6IiJ9.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJrdWJlLXN5c3RlbSIsImt1YmVybmV0ZXMuaW8vc2Vy
dmljZWFjY291bnQvc2VjcmV0Lm5hbWUiOiJkYXNoYm9hcmQtYWRtaW4tdG9rZW4tdmIyNnMiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC5uYW1lIjoiZGFzaGJvYXJkLWFkbWluIiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZXJ2aWNlLWFjY291bnQudWlkIjoiNGY4MTU2MWEtYjgxZS0xMWU5LTg4MTgtMDAwYzI5ZDE0MmJlIiwic3ViIjoic3lzdGVtOnNlcnZpY2VhY2NvdW50Omt1YmUtc3lzdGVtOmRhc2hib2FyZC1hZG1pbiJ9.iMYY1B48Iff9kjy04vvbQdD2C75hLp8Qf2bFJ9ogfrF20pX4usxtixhm4aSWaM8zO1amwxb1ISt1VmbgfOGUp7y8kpUOkX8KYgGnOpLH-rz_6anPx6ctw7NHEnnnexA-dp7mVkmywJqsURdvIQxPPHeULlZy94SSF4e2Azf6CodKY4fjN93M9wXfPxiezK7tAZ-MVHYrF9frVgaJhzX0DfgUf7JKYi7-TCBy1dJw2ysMvYKsmQZwhARhttZzv-e34n5RNjKuLtt7fg4g-RkcKkXXcDn9fq4-2gewN44Zir5VZl9LNQcmx-UjOAj24PToCwVRRVdGt1z0wORIQSJgyw

　　　　我们可以看到这个token令牌，将这个令牌复制出来就可以登录了

　　　　d、上述为管理员的token，也可以给名称空间做一个token，只能管理当前的名称空间

[root@k8smaster kube]# kubectl create serviceaccount def-ns-admin -n default
serviceaccount/def-ns-admin created
[root@k8smaster kube]# kubectl create rolebinding def-ns-admin --clusterrole=admin --serviceaccount=default:def-ns-admin
rolebinding.rbac.authorization.k8s.io/def-ns-admin created
[root@k8smaster kube]# kubectl get secret
NAME                       TYPE                                  DATA      AGE
admin-token-xnplt          kubernetes.io/service-account-token            28d
def-ns-admin-token-mm92j   kubernetes.io/service-account-token            1m
default-token-jvtl7        kubernetes.io/service-account-token            90d
mysql-root-password        Opaque                                         48d
tomcat-ingress-secret      kubernetes.io/tls                              54d
[root@k8smaster kube]# kubectl describe secret def-ns-admin-token-mm92j
Name:         def-ns-admin-token-mm92j
Namespace:    default
Labels:       <none>
Annotations:  kubernetes.io/service-account.name=def-ns-admin
              kubernetes.io/service-account.uid=451c305f-b8f4-11e9-8f84-000c29d142be

Type:  kubernetes.io/service-account-token

Data
====
namespace:   bytes
token:      eyJhbGciOiJSUzI1NiIsImtpZCI6IiJ9.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJkZWZhdWx0Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNl
YWNjb3VudC9zZWNyZXQubmFtZSI6ImRlZi1ucy1hZG1pbi10b2tlbi1tbTkyaiIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50Lm5hbWUiOiJkZWYtbnMtYWRtaW4iLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC51aWQiOiI0NTFjMzA1Zi1iOGY0LTExZTktOGY4NC0wMDBjMjlkMTQyYmUiLCJzdWIiOiJzeXN0ZW06c2VydmljZWFjY291bnQ6ZGVmYXVsdDpkZWYtbnMtYWRtaW4ifQ.Z8qE3j1xp884MkDObYvd6bDNByWmJcfV_Hxbxvlsm7vlFL-lmMMtNBDazSnLDrf4ePg2fTE2QYPRfqoKzSo8U4uKQl1G-o7Wnt7890HcPhfsWw5rpnJQmiW0OkadWnt-j6EXeiNvwTCrxHjMNQQQlDQ2wnJAJLwxqHmNwLSGoXU-2CMYIQImylZTPIwiX9A-ppcldzTWU0XshLNkk4_9Loo2aE8tlVMIh4IEB09HshHrxZz6T4TATOV2XcKy7lU5TCEd6q9ZmniWZg9q_zsMIcIByx3Wv2FIOMLVL-1YTvVJJZQMIGrIfOPUYli3HwNVtjfIpU4SdorNYDw9Pg7iqg

　　7、现在我们换一个方式装在一个文件中来认证。这样我们就要为serviceaccount来创建一个配置文件

　　　　a、新设置一个集群

[root@k8smaster pki]# kubectl config set-cluster kubernetes --certificate-authority=./ca.crt --server="https://172.20.0.70:6443" --embed-certs=true --kubeconfig=/root/def-ns-admin.conf
Cluster "kubernetes" set.
[root@k8smaster pki]# kubectl config view --kubeconfig=/root/def-ns-admin.conf
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: REDACTED
    server: https://172.20.0.70:6443
  name: kubernetes
contexts: []
current-context: ""
kind: Config
preferences: {}
users: []

　　　　b、设置用户账号，我们刚开始创建了证书和私钥，我们现在试一下不用私钥行不行，直接用刚刚创建的serviceaccount的token来作为认证信息

[root@k8smaster ~]# kubectl get secret
NAME                       TYPE                                  DATA      AGE
admin-token-xnplt          kubernetes.io/service-account-token            29d
def-ns-admin-token-mm92j   kubernetes.io/service-account-token            21h
default-token-jvtl7        kubernetes.io/service-account-token            91d
mysql-root-password        Opaque                                         49d
tomcat-ingress-secret      kubernetes.io/tls                              55d
[root@k8smaster ~]# DEF_NS_ADMIN_TOKEN=$(kubectl get secret def-ns-admin-token-mm92j -o jsonpath={.data.token} |base64 -d)
[root@k8smaster ~]# echo ${DEF_NS_ADMIN_TOKEN}
eyJhbGciOiJSUzI1NiIsImtpZCI6IiJ9.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJkZWZhdWx0Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9z
ZWNyZXQubmFtZSI6ImRlZi1ucy1hZG1pbi10b2tlbi1tbTkyaiIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50Lm5hbWUiOiJkZWYtbnMtYWRtaW4iLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC51aWQiOiI0NTFjMzA1Zi1iOGY0LTExZTktOGY4NC0wMDBjMjlkMTQyYmUiLCJzdWIiOiJzeXN0ZW06c2VydmljZWFjY291bnQ6ZGVmYXVsdDpkZWYtbnMtYWRtaW4ifQ.Z8qE3j1xp884MkDObYvd6bDNByWmJcfV_Hxbxvlsm7vlFL-lmMMtNBDazSnLDrf4ePg2fTE2QYPRfqoKzSo8U4uKQl1G-o7Wnt7890HcPhfsWw5rpnJQmiW0OkadWnt-j6EXeiNvwTCrxHjMNQQQlDQ2wnJAJLwxqHmNwLSGoXU-2CMYIQImylZTPIwiX9A-ppcldzTWU0XshLNkk4_9Loo2aE8tlVMIh4IEB09HshHrxZz6T4TATOV2XcKy7lU5TCEd6q9ZmniWZg9q_zsMIcIByx3Wv2FIOMLVL-1YTvVJJZQMIGrIfOPUYli3HwNVtjfIpU4SdorNYDw9Pg7iqg
[root@k8smaster ~]# kubectl config set-credentials def-ns-admin --token=${DEF_NS_ADMIN_TOKEN} --kubeconfig=/root/def-ns-admin.conf
User "def-ns-admin" set.
[root@k8smaster ~]# kubectl config view --kubeconfig=/root/def-ns-admin.conf
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: REDACTED
    server: https://172.20.0.70:6443
  name: kubernetes
contexts: []
current-context: ""
kind: Config
preferences: {}
users:
- name: def-ns-admin
  user:
    token: eyJhbGciOiJSUzI1NiIsImtpZCI6IiJ9.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJkZWZhdWx0Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlY
WNjb3VudC9zZWNyZXQubmFtZSI6ImRlZi1ucy1hZG1pbi10b2tlbi1tbTkyaiIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50Lm5hbWUiOiJkZWYtbnMtYWRtaW4iLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC51aWQiOiI0NTFjMzA1Zi1iOGY0LTExZTktOGY4NC0wMDBjMjlkMTQyYmUiLCJzdWIiOiJzeXN0ZW06c2VydmljZWFjY291bnQ6ZGVmYXVsdDpkZWYtbnMtYWRtaW4ifQ.Z8qE3j1xp884MkDObYvd6bDNByWmJcfV_Hxbxvlsm7vlFL-lmMMtNBDazSnLDrf4ePg2fTE2QYPRfqoKzSo8U4uKQl1G-o7Wnt7890HcPhfsWw5rpnJQmiW0OkadWnt-j6EXeiNvwTCrxHjMNQQQlDQ2wnJAJLwxqHmNwLSGoXU-2CMYIQImylZTPIwiX9A-ppcldzTWU0XshLNkk4_9Loo2aE8tlVMIh4IEB09HshHrxZz6T4TATOV2XcKy7lU5TCEd6q9ZmniWZg9q_zsMIcIByx3Wv2FIOMLVL-1YTvVJJZQMIGrIfOPUYli3HwNVtjfIpU4SdorNYDw9Pg7iqg

　　　　c、现在我们Users的name也有了，token也有了，现在我们来设置context

[root@k8smaster ~]# kubectl config use-context def-ns-admin@kubernetes --kubeconfig=/root/def-ns-admin.conf
Switched to context "def-ns-admin@kubernetes".
[root@k8smaster ~]# kubectl config view --kubeconfig=/root/def-ns-admin.conf
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: REDACTED
    server: https://172.20.0.70:6443
  name: kubernetes
contexts:
- context:
    cluster: kubernetes
    user: def-ns-admin
  name: def-ns-admin@kubernetes
current-context: def-ns-admin@kubernetes
kind: Config
preferences: {}
users:
- name: def-ns-admin
  user:
    token: eyJhbGciOiJSUzI1NiIsImtpZCI6IiJ9.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJkZWZhdWx0Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlY
WNjb3VudC9zZWNyZXQubmFtZSI6ImRlZi1ucy1hZG1pbi10b2tlbi1tbTkyaiIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50Lm5hbWUiOiJkZWYtbnMtYWRtaW4iLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC51aWQiOiI0NTFjMzA1Zi1iOGY0LTExZTktOGY4NC0wMDBjMjlkMTQyYmUiLCJzdWIiOiJzeXN0ZW06c2VydmljZWFjY291bnQ6ZGVmYXVsdDpkZWYtbnMtYWRtaW4ifQ.Z8qE3j1xp884MkDObYvd6bDNByWmJcfV_Hxbxvlsm7vlFL-lmMMtNBDazSnLDrf4ePg2fTE2QYPRfqoKzSo8U4uKQl1G-o7Wnt7890HcPhfsWw5rpnJQmiW0OkadWnt-j6EXeiNvwTCrxHjMNQQQlDQ2wnJAJLwxqHmNwLSGoXU-2CMYIQImylZTPIwiX9A-ppcldzTWU0XshLNkk4_9Loo2aE8tlVMIh4IEB09HshHrxZz6T4TATOV2XcKy7lU5TCEd6q9ZmniWZg9q_zsMIcIByx3Wv2FIOMLVL-1YTvVJJZQMIGrIfOPUYli3HwNVtjfIpU4SdorNYDw9Pg7iqg

　　　　d、将def-ns-admin.conf导出然后登陆时选择此文件即可

三、总结

　　1、部署：

kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v1.8.3/src/deploy/recommended/kubernetes-dashboard.yaml

　　2、将service改为NodePort

kubectl patch svc kubernetes-dashboard -p '{"spec":{"type":"NodePort"}}' -n kube-system

　　3、认证：认证时的账号必须为ServiceAccount:因为它是dashboard的pod拿来认证到k8s之上，被dashboard pod拿来由kubernetes来进行认证。

　　　　a、直接使用token

　　　　　　1）、创建ServiceAccount，根据其管理目标，使用rolebinding或clusterrolebinding绑定至合理role或clusterrole；这个role或clusterrole也可以自己定义，比如让用户登录进来以后只能读，不能修改，这样我们就需要自定义role，绑定完以后会自动生成一个认证信息

　　　　　　2）、获取到此serviceaccount的secret，这个secret就包含了认证到k8s上的认证信息,查看secret的详细信息，其中就有token。

　　　　b、把创建的ServiceAccount的token封装为kubeconfig文件

　　　　　　使用json的输出机制来加载它的json格式的输出的token，然后把它使用base64解码，解码完后把它当做token封装到我们的kubeconfig中。

　　　　　　1）、创建ServiceAccount，根据其管理目标，使用rolebinding或clusterrolebinding绑定至合理role或clusterrole；

　　　　　　2）、kubectl get secret|awk '/^ServiceAccount/{print $1}'

　　　　　　　　KUBE_TOKEN=$(kubectl get secret SERVICEACCOUNT_SERECT_NAME -o jsonpath={.data.token} |base64 -d)

　　　　　　3）、生成kubeconfig文件

　　　　　　　　kubectl config set-cluster   --kubeconfig=/PATH/TO/SOMEFILE

　　　　　　　　kubectl config set-credentials NAME --token=${KUBE_TOKEN}

　　　　　　　　kubectl config set-context

　　　　　　　　kubectl config use-context

　　　　c、所以我们需要注意的是虽然都是获取token但是我们获取token的方式不一样

　　4、对于k8s来讲有三种管理方式。

　　　　a、命令式: create ，run，expose，delete，edit ...

　　　　b、命令式配置文件 ：create -f /PATH/TO/RESOURCE_CONFIGURATION_FILE，delete -f ，replace -f

　　　　c、声明式配置文件　： apply -f ，patch

　　　　d、一般建议不要混合使用这三种方式，第一第二可以混合但是不要和第三种混合，因为第三种是能做就地修改的，第二种做的是替换，任何修改都只能是替换。