kubernetes dashboard 认证及分级授权

Posted 2022-08-01 crazymagic

概述

前面介绍了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　

 

部署脚本

# Copyright 2017 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: 1
  revisionHistoryLimit: 10
  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: 8443
          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: 8443
          initialDelaySeconds: 30
          timeoutSeconds: 30
      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: 443
      targetPort: 8443
  selector:
    k8s-app: kubernetes-dashboard

kubernetes-dashboard.yml

 

 使用补丁的方式将 service类型为clusterIP类型，我们需要将其改为nodeport类型

kubectl patch svc kubernetes-dashboard -p ‘"spec":"type":"NodePort"‘ -n kube-system
service/kubernetes-dashboard not patched

 

查看暴露的服务

kubectl get svc -n svc --all-namespaces

访问

https://192.168.228.138:32602

 

 

token认证

 创建一个serviceaccount

kubectl create serviceaccount dashboard-admin -n kube-system

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

kubectl create clusterrolebinding dashboard-cluster-admin --clusterrole=cluster-admin --serviceaccount=kube-system:dashboard-admin

　

查看 dashboard secret

kubectl get  secret  -n kube-system

 

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

kubectl describe secret dashboard-admin-token-vqqxh -n kube-system

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