Kubernetes RBAC角色权限控制

2023年 5月 4日 34.7k 0

RBAC是基于角色的访问控制 (Role-Based Access Control) 在RBAC中,权限与角色相关联。Kubernetes 基于角色的访问控制使用rbac.authorization.k8s.io API组来实现权限控制,RBAC允许管理员通过Kubernetes API动态的配置权限策略。如果需要开启RBAC授权需要在apiserver组件中指定--authorization-mode=Node,RBAC
Kubernetes RBAC角色权限控制
Kubernetes
在Kubernetes中所有的API对象都保存在ETCD里,可是,对这些API对象的操作,却一定是通过访问kube-apiserver实现的。我们需要APIServer来帮助我们授权工作,而在Kubernetes项目中,负责完成授权(Authorization)的工作机制就是RBAC: 基于角色的访问控制 (Role-Based Access Control)
RBAC是基于角色的访问控制 (Role-Based Access Control) 在RBAC中,权限与角色相关联。Kubernetes 基于角色的访问控制使用rbac.authorization.k8s.io API组来实现权限控制,RBAC允许管理员通过Kubernetes API动态的配置权限策略。如果需要开启RBAC授权需要在apiserver组件中指定--authorization-mode=Node,RBAC

Kubernetes 1.14 二进制集群安装

新闻联播老司机

  • 19年8月13日
  • 喜欢:1
  • 浏览:18.6k
  • 修改完毕后需要重启apiserver,在我提供的二进制安装已经将下面参数添加进去。如果使用的是kubeadm安装在1.6版本默认已经启用了RBAC
    这里我们需要明确三个RBAC最基本的概念

  • Role: 角色,它定义了一组规则,定义了一组对Kubernetes API对象的操作权限
  • Subject: 被作用者,既可以是"人",也可以是机器,当然也可以是我们Kubernetes中定义的用户(ServiceAccount主要负责kubernetes内置用户)
  • RoleBinding: 定义了"被作用者"和"角色"的绑定关系
  • RBAC API对象
    Kubernetes有一个很基本的特性就是它的所有资源都是模型化的API对象,允许执行CRUD(Create、Read、Update、Delete)操作。资源如下

  • Pods
  • ConfigMaps
  • Deployments
  • Nodes
  • Secrets
  • Namespaces
  • 资源对象可能存在的操作有如下

  • create
  • get
  • delete
  • list
  • update
  • edit
  • watch
  • exec
  • 这些资源和API Group进行关联,比如Pods属于Core API Group,而Deployment属于apps API Group,要在kubernetes中进行RBAC授权

    Role && Rolebinding

    实际上,Role本身就是一个Kubernetes的API对象,定义文件如下

    kind: Role
    apiVersion: rbac.authorization.k8s.io/v1
    metadata:
      namespace: mynamespace
      name: example-role
    rules:
    - apiGroups: [""]
      resources: ["pods"]
      verbs: ["get", "watch", "list"]
    

    文件解释
    首先,Role对象指定了它能产生作用的Namespace(mynamespace)。Namespace是kubernetes项目中的一个逻辑管理单位。不同Namespace的API对象,在通过kubectl命令进行操作的时候,是互相隔离的
    namespace并不会提供任何实际的隔离或者多租户能力,如果没有设置namespace默认则是default
    rules字段定义它的是权限规则,这条规则的含义就是允许"被作用者",对namespace下面pod (resources中定义)有哪些权限
    用户的权限对应的API资源对象已经创建了,但是还没有绑定。也就是只有一个规则没有规定哪些用户使用这个权限
    这里进行Rolebinding介绍

    kind: RoleBinding
    apiVersion: rbac.authorization.k8s.io/v1
    metadata:
      name: example-rolebinding
      namespace: mynamespace
    subjects:
    - kind: User
      name: example-user
      apiGroup: rbac.authorization.k8s.io
    roleRef:
      kind: Role
      name: example-role
      apiGroup: rbac.authorization.k8s.io
    

    在Rolebinding中定义了一个subject字段,即"被作用者"。它的类型是User,即Kubernetes里的用户,名称为example-user
    在kubernetes里的User,也就是用户,只是一个授权系统里的逻辑概念。它需要通过外部认证服务,比如Keystone,来提供。或者直接给APIServer指定一个用户名、密码文件。那么kubernetes的授权系统就能够从这个文件里找到对象的用户
    Rolebinding对象通过roleRef字段可以直接通过名字,来引用前面定义的Role对象(example-role),从而定义了"被作用者(Subject)"和"角色(Role)"之间的绑定关系
    Role和RoleBinding 他们的权限限制规则仅仅在他们自己的namespace内有效,roleRef也只能引用当前namespace里的Role对象

    ClusterRole && ClusterRoleBinding

    对于某一个role想要作用的namespace的时候,就必须需要使用ClusterRole和ClusterRoleBinding两个组合。这两个API 对象的用法跟Role和Rolebinding完全一样

    kind: ClusterRole
    apiVersion: rbac.authorization.k8s.io/v1
    metadata:
      name: example-clusterrole
    rules:
    - apiGroups: [""]
      resources: ["pods"]
      verbs: ["get", "watch", "list"]
    
    ###############################################
    kind: ClusterRoleBinding
    apiVersion: rbac.authorization.k8s.io/v1
    metadata:
      name: example-clusterrolebinding
    subjects:
    - kind: User
      name: example-user
      apiGroup: rbac.authorization.k8s.io
    roleRef:
      kind: ClusterRole
      name: example-clusterrole
      apiGroup: rbac.authorization.k8s.io
    

    在上面的例子中,ClusterRole和ClusterRoleBinding的组合,意味着名叫example-user的用户,拥有对所有namespace里的Pod进行Get、Watch、List操作的权限。
    类似的,Role对象的rules字段也可以进一步细化,可以只针对某一个具体权限对象进行设置

    rules:
    - apiGroups: [""]
      resources: ["configmaps"]
      resourceNames: ["my-config"]
      verbs: ["get"]
    

    上面的例子表示,这条规则的"被作用者",只对my-config的configmap对象有权限进行get操作
    前面也说过,在Kubernetes中已经内置了很多个位系统保留的ClusterRole,它们的名字都是以system:开头。一般来说,这些内置的ClusterRole,是绑定给Kubernetes系统组件对应的ServiceAccount使用

    #我们可以通过下面的命令获取到
    [root@abcdocker sa-test]# kubectl get clusterroles
    NAME                                                                   AGE
    admin                                                                  93d
    approve-node-server-renewal-csr                                        93d
    cluster-admin                                                          93d
    edit                                                                   93d
    ...
    system:public-info-viewer                                              93d
    system:volume-scheduler                                                93d
    traefik-ingress-controller                                             45d
    view                                                                   93d
    

    此外,Kubernetes还提供了四个预先定义好的ClusterRole来提供用户直接使用

  • cluster-admin
  • admin
  • edit
  • view
  • 其中cluster-admin角色,对应的是整个Kubernetes项目中最高权限(verbs=*)

    #我们可以通过下面的命令查看clusterrole的权限
    [root@abcdocker sa-test]# kubectl describe clusterrole cluster-admin -n kube-system
    Name:         cluster-admin
    Labels:       kubernetes.io/bootstrapping=rbac-defaults
    Annotations:  rbac.authorization.kubernetes.io/autoupdate: true
    PolicyRule:
      Resources  Non-Resource URLs  Resource Names  Verbs
      ---------  -----------------  --------------  -----
      *.*        []                 []              [*]
                 [*]                []              [*]
    

    ServiceAccount

    前面所介绍的大多数不使用,ServiceAccount主要负责kubernetes内置用户,下面简单定义一个ServiceAccount

    apiVersion: v1
    kind: ServiceAccount
    metadata:
      namespace: mynamespace
      name: example-sa
    

    我们定义了一个serverAccount对象,只需要name以及namespace最基础字段就可以。然后通过编写rolebinding的yaml文件,来为这个serviceAccount分配权限

    kind: RoleBinding
    apiVersion: rbac.authorization.k8s.io/v1
    metadata:
      name: example-rolebinding
      namespace: mynamespace
    subjects:
    - kind: ServiceAccount
      name: example-sa
      namespace: mynamespace
    roleRef:
      kind: Role
      name: example-role
      apiGroup: rbac.authorization.k8s.io
    

    在Rolebinding对象里,subject字段的类型(kind),不在是一个User,而是一个名叫example-sa的ServerAccount。而roleRef引用的Role对象,依然名叫example-role。也就是我们上面定义的
    接下来我们创建演示

    #yaml文件如下
    [root@abcdocker serveraccount]# cat pod-sa.yaml
    apiVersion: v1
    kind: Pod
    metadata:
      namespace: mynamespace
      name: sa-token-test
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
      serviceAccountName: example-sa
    
    
    [root@abcdocker serveraccount]# cat role-binding.yaml
    kind: RoleBinding
    apiVersion: rbac.authorization.k8s.io/v1
    metadata:
      name: example-rolebinding
      namespace: mynamespace
    subjects:
    - kind: ServiceAccount
      name: example-sa
      namespace: mynamespace
    roleRef:
      kind: Role
      name: example-role
      apiGroup: rbac.authorization.k8s.io
    
    
    [root@abcdocker serveraccount]# cat role.yaml
    kind: Role
    apiVersion: rbac.authorization.k8s.io/v1
    metadata:
      namespace: mynamespace
      name: example-role
    rules:
    - apiGroups: [""]
      resources: ["pods"]
      verbs: ["get", "watch", "list"]
    
    
    [root@abcdocker serveraccount]# cat role-binding.yaml
    kind: RoleBinding
    apiVersion: rbac.authorization.k8s.io/v1
    metadata:
      name: example-rolebinding
      namespace: mynamespace
    subjects:
    - kind: ServiceAccount
      name: example-sa
      namespace: mynamespace
    roleRef:
      kind: Role
      name: example-role
      apiGroup: rbac.authorization.k8s.io
    
    
    #接下来我们创建命名空间
    [root@abcdocker serveraccount]# kubectl create namespace mynamespace
    namespace/mynamespace created
    [root@abcdocker serveraccount]# kubectl apply -f .
    rolebinding.rbac.authorization.k8s.io/example-rolebinding created
    role.rbac.authorization.k8s.io/example-role created
    serviceaccount/example-sa created
    
    [root@abcdocker serveraccount]# kubectl get sa  -n mynamespace
    NAME         SECRETS   AGE
    default      1         26s
    example-sa   1         22s
    
    [root@abcdocker serveraccount]# kubectl get sa -n mynamespace example-sa -o yaml
    apiVersion: v1
    kind: ServiceAccount
    metadata:
      annotations:
        kubectl.kubernetes.io/last-applied-configuration: |
          {"apiVersion":"v1","kind":"ServiceAccount","metadata":{"annotations":{},"name":"example-sa","namespace":"mynamespace"}}
      creationTimestamp: "2019-11-28T08:01:22Z"
      name: example-sa
      namespace: mynamespace
      resourceVersion: "14579937"
      selfLink: /api/v1/namespaces/mynamespace/serviceaccounts/example-sa
      uid: 4481a40f-11b5-11ea-a57e-525400d7b284
    secrets:
    - name: example-sa-token-wms94
    

    Kubernetes会为ServiceAccount自动创建一个Secret对象,即ServiceAccount定义最下面的secrets字段。其中,这里的secret就是ServiceAccount对应来跟APIServer进行交互的授权文档,一般为TOken,保存证书和密码等,它以一个Secret对象保存在ETCD中
    这时候我们就可以直接引用这个sa(serviceAccount)了

    apiVersion: v1
    kind: Pod
    metadata:
      namespace: mynamespace
      name: sa-token-test
    spec:
      containers:
      - name: nginx
        image: nginx
      serviceAccountName: example-sa
    
     #在最下面一行我们定义了一个名为example-sa
    

    接下来我们可以通过describe查看pod状态

    [root@abcdocker serveraccount]# kubectl describe pod -n mynamespace sa-token-test
    Name:               sa-token-test
    Namespace:          mynamespace
    ...
        Mounts:
          /var/run/secrets/kubernetes.io/serviceaccount from example-sa-token-wms94 (ro)
    ...
    

    ServiceAccount的token也就是secret对象是被Kubernetes自动挂载到了容器/var/run/secrets/kubernetes.io/serviceaccount目录下
    我们可以到Pod目录进行查看

    $ kubectl exec -it sa-token-test -n mynamespace -- /bin/bash
    root@sa-token-test:/# ls /var/run/secrets/kubernetes.io/serviceaccount
    ca.crt namespace  token
    

    在Kubernetes集群访问主要是通过ca.crt来访问Apiserver,更重要的是此时它只可以做GET、WATCH和LIST操作。因为example-sa这个ServiceAccount的权限已经被我们绑定了role限制
    如果一个Pod没有声明sa,Kubernetes会自动在它的namespace创建一个名称为default的默认ServiceAccount,然后分配给Pod。但是这种情况下默认ServiceAccount没有关联任何Role。也就是说它有APIServer的绝大多数权限

    User && Group

    Kubernetes除了有用户(User),还拥有用户组(Group)概念,如果我们Kubernetes配置了外部认证服务的话,这个用户组的概念就由外部认证服务提供
    一个ServiceAccount在Kubernetes对应的用户的名字是

    system:serviceaccount:<ServiceAccount名字>
    

    而对应的用户组则是

    system:serviceaccounts:<Namespace名字>
    

    比如,我们可以在RoleBinding中定义如下subjects

    subjects:
    - kind: Group
      name: system:serviceaccounts:mynamespace
      apiGroup: rbac.authorization.k8s.io
    
    #这就意味着role的规则权限,作用于mynamespace里的所有ServiceAccount,这就用到了用户组的概念
    
    
    
    subjects:
    - kind: Group
      name: system:serviceaccounts
      apiGroup: rbac.authorization.k8s.io
    
    #这个role的规则权限,则作用于整个系统里ServiceAccount
    

    在Kubernetes中已经内置了很多歌为系统保留的ClusterRole,它们的名字都以system:开头,可以使用kubectl get clusterroles查找到
    现在我们可以理解,所谓的角色(Role),其实就是一组规则权限列表,而我们分配这些权限的方式,就是通过创建RoleBinding对象,将被用者(subject)和权限列表绑定。
    而对应的ClusterRole和ClusterRoleBinding,则是Kubernetes集群级别的Role和RoleBinding,它们不受namespace限制

    一、创建一个只能访问某个namespace的ServiceAccount

    当我们创建一个sa之后,会自动帮我们创建一个secrets

    [root@abcdocker ~]# kubectl create sa test-sa -n kube-system
    serviceaccount/test-sa created
    

    接下来可以查看一下sa

    [root@abcdocker ~]# kubectl get sa -n kube-system test-sa -o yaml
    apiVersion: v1
    kind: ServiceAccount
    metadata:
      creationTimestamp: "2019-11-28T09:32:54Z"
      name: test-sa
      namespace: kube-system
      resourceVersion: "14590921"
      selfLink: /api/v1/namespaces/kube-system/serviceaccounts/test-sa
      uid: 0e218ad3-11c2-11ea-a57e-525400d7b284
    secrets:
    - name: test-sa-token-fs4fx
    

    可以通过get secret查看

    [root@abcdocker ~]# kubectl get secrets -n kube-system |grep test-sa-token
    test-sa-token-fs4fx                              kubernetes.io/service-account-token   3      17h
    

    我们需要创建一个role (角色)对象与sa进行关联

    #yaml文件如下
    cat >>sa-role.yaml<<EOF
    apiVersion: rbac.authorization.k8s.io/v1
    kind: Role
    metadata:
      name: sa-role
      namespace: kube-system
    rules:
    - apiGroups: [""]
      resources: ["pods"]
      verbs: ["get", "list"]
    - apiGroups: ["apps", "extensions"]
      resources: ["pods", "deployment", "replicasets"]
      verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
    EOF
    #这里我们创建的role设置的权限是对pod有get和list权限,对deployment有下面其他权限
    
    
    #执行文件yaml
    [root@abcdocker ~]# kubectl apply -f  sa-role.yaml
    role.rbac.authorization.k8s.io/sa-role created
    
    #检查状态
    [root@abcdocker ~]# kubectl get role -n kube-system
    NAME                                             AGE
    extension-apiserver-authentication-reader        93d
    prometheus-k8s                                   15d
    sa-role                                          9s
    ...
    #我们刚刚在kube-sytem下创建一个名称为sa-role的role
    

    角色创建完成之后我们就需要创建一个RoleBinding

    cat >>sa-rolebinding.yaml<<EOF
    apiVersion: rbac.authorization.k8s.io/v1
    kind: RoleBinding
    metadata:
      name: sa-rolebinding
      namespace: kube-system
    subjects:
    - kind: ServiceAccount
      name: test-sa
      namespace: kube-system
    roleRef:
      kind: Role
      name: sa-role
      apiGroup: rbac.authorization.k8s.io
    EOF
    
    #执行
    
    [root@abcdocker ~]# kubectl apply -f sa-rolebinding.yaml
    rolebinding.rbac.authorization.k8s.io/sa-rolebinding created
    
    [root@abcdocker ~]# kubectl get rolebinding -n kube-system|grep sa
    sa-rolebinding                                      28s
    

    这时候我们创建的ServerAccount已经和我们role进行绑定了,通过rolebinding进行绑定。下面可以进行测试
    #首先我们复制我们创建sa中secret里面的token

    [root@abcdocker ~]# kubectl get sa -n kube-system test-sa -o yaml
    apiVersion: v1
    kind: ServiceAccount
    metadata:
      creationTimestamp: "2019-11-28T09:32:54Z"
      name: test-sa
      namespace: kube-system
    ...
    secrets:
    - name: test-sa-token-fs4fx
    #这个name为我们secret名称,创建sa的时候会自动给我们创建secret
    
    
    #接下来我们查看这个secret中的token
    [root@abcdocker ~]# kubectl get secrets test-sa-token-fs4fx -n kube-system -o yaml
    apiVersion: v1
    data:
    ...
      namespace: a3ViZS1zeXN0ZW0=
      token: ZXlKaGJHY2lPaUpTVXpJMU5pSXNJbXRwWkNJNklpSjkuZXlKcGMzTWlPaUpyZFdKbGNtNWxkR1Z6TDNObGNuWnBZMlZoWTJOdmRXNTBJaXdpYTNWaVpYSnVaWFJsY3k1cGJ5OXpaWEoyYVdObFlXTmpiM1Z1ZEM5dVlXMWxjM0JoWTJVaU9pSnJkV0psTFhONWMzUmxiU0lzSW10MVltVnlibVYwWlhNdWFXOHZjMlZ5ZG1salpXRmpZMjkxYm5RdmMyVmpjbVYwTG01aGJXVWlPaUowWlhOMExYTmhMWFJ2YTJWdUxXWnpOR1o0SWl3aWEzVmlaWEp1WlhSbGN5NXBieTl6WlhKMmFXTmxZV05qYjNWdWRDOXpaWEoyYVdObExXRmpZMjkxYm5RdWJtRnRaU0k2SW5SbGMzUXRjMkVpTENKcmRXSmxjbTVsZEdWekxtbHZMM05sY25acFkyVmhZMk52ZFc1MEwzTmxjblpwWTJVdFlXTmpiM1Z1ZEM1MWFXUWlPaUl3WlRJeE9HRmtNeTB4TVdNeUxURXhaV0V0WVRVM1pTMDFNalUwTURCa04ySXlPRFFpTENKemRXSWlPaUp6ZVhOMFpXMDZjMlZ5ZG1salpXRmpZMjkxYm5RNmEzVmlaUzF6ZVhOMFpXMDZkR1Z6ZEMxellTSjkuU04yRm0wemdiUi1XU21oVTdOYkxMWDZFRVNiSnNpNDNWRHZpOXJUdG1UcDVzSXl0RzJKNkFqUGNBeGxqSHE1dkdqVWNTTGpoOXd2aDBSV25HMXUydzZ3MHUtTGd0S0g3NllZNWVHRGVtSUxJaTcxeDZDNXlrTE85a3hNVU1sOG9WQmxnVGhFRVVrZEJjRk96X3pveEZCc1lGRV9xcm1NSGNma29RU0Y3UGRWSnp0VjBuYkZmem9fdWJ4cU5Zd2RaYzJIc2wyZ1VOT3NzcGRVdlV2ZXd6WGIwZzJwZnJ4NlVuUkpWU1FoSjJWbjdBWlFrXzJ6c0p2SXJPeXNLSlpJSm5RRlZFUGJCSXhIazNaR2o4WExjRUVEcmMySWRHUDNLcGFwdHlkU21hXzdXS1lmMFlQSThkdmZvZmdJcTlyUFd4YjRqeEg0NFFUZ0xtS1lHZ0VxR2x3
    ...
    

    这里我们复制token,使用bease64进行解密
    echo "xxx" |base64 -d
    6DF5431D-A1AD-4CB3-A554-9492D93ED0F4.png-832kB
    现在token已经创建好了,我们使用dashboard进行演示

    Kubernetes Dashboard 设置用户密码登陆

    新闻联播老司机

  • 19年5月20日
  • 喜欢:0
  • 浏览:6k
  • 接下来我们打开dashboard的地址,将解密后的token复制进去
    kubernetes dashboard建议使用火狐浏览器
    77067D28-91C3-44AB-8472-B4C821EDBFCC.png-152.9kB
    我们登陆到dashboard界面上,默认访问的为default命名空间,因为我们授权的是kube-system空间,所以很多地方没有权限。会有下面的报错
    FE3284DD-C4A9-4027-827C-BF76CB8898D1.png-645.5kB
    在我们配置role的yaml文件中,只分配了pod和deployment以及replicasets相关权限,像pvc这种并没有分配所以会提示firidden
    我们将default修改为kube-system即可
    085FB3C9-EDAF-4991-A498-24428243DC68.png-470.2kB
    我们还可以直接通过rolebinding绑定系统提供的role权限

    二、创建一个可以访问所有namespace的ServiceAccount

    上面创建单个namespace访问权限主要是用了role和rolebinding,接下来我们使用clusterRole和ClusterRoleBinding进行演示。使用role和rolebinding只会绑定特定的namespace下,clusterRole会绑定到集群下
    首先我们创建一个ServiceAccount对象

    #这次我们不使用kubectl命令行创建,采用yaml的方式,关于sa的yaml定义格式可以参考上面的sa的介绍,并且我们将所有的配置文件写在一个yaml中
    
    cat >>sa.yaml<<EOF
    apiVersion: v1
    kind: ServiceAccount
    metadata:
      name: abcdocker-sa
      namespace: kube-system
    
    ---
    
    apiVersion: rbac.authorization.k8s.io/v1
    kind: ClusterRoleBinding
    metadata:
      name: abcdocker-clusterrolebinding   #clusterrolebinding的名称
    subjects:      #被作用者
    - kind: ServiceAccount    #类型
      name: abcdocker-sa      #sa名称
      namespace: kube-system  #sa命名空间
    roleRef:     #角色引用
      kind: ClusterRole   #类型为clusterRole
      name: cluster-admin   #clust-admin为rbac系统最大权限
      apiGroup: rbac.authorization.k8s.io
    #这里的clusterRole我们直接使用系统内置的变量,我们直接创建clusterrolebinding就可以了
    EOF
    
    
    #接下来开始创建
    [root@abcdocker sa-test]# kubectl apply -f  sa.yaml
    serviceaccount/abcdocker-sa created
    clusterrolebinding.rbac.authorization.k8s.io/abcdocker-clusterrolebinding created
    
    #这里我们可以看到sa和clusterrolebinding已经被创建
    

    我们可以过滤到sa和clusterrolebinding

    [root@abcdocker sa-test]# kubectl get sa,clusterrolebinding -n kube-system|grep abcdocker
    serviceaccount/abcdocker-sa                         1         7m50s
    
    clusterrolebinding.rbac.authorization.k8s.io/abcdocker-clusterrolebinding                           7m50s
    

    接下来我们验证还是使用创建的sa中的secret token进行访问dashboard,查看对应权限是否正常

    [root@abcdocker sa-test]# kubectl describe sa -n kube-system abcdocker-sa
    Name:                abcdocker-sa
    Namespace:           kube-system
    Labels:              
    Annotations:         kubectl.kubernetes.io/last-applied-configuration:
                           {"apiVersion":"v1","kind":"ServiceAccount","metadata":{"annotations":{},"name":"abcdocker-sa","namespace":"kube-system"}}
    Image pull secrets:  
    Mountable secrets:   abcdocker-sa-token-qkb7c
    Tokens:              abcdocker-sa-token-qkb7c
    Events:              
    [root@abcdocker sa-test]# kubectl get secrets -n kube-system abcdocker-sa-token-qkb7c -o yaml
    apiVersion: v1
    data:
    ...
      token: ZXlKaGJHY2lPaUpTVXpJMU5pSXNJbXRwWkNJNklpSjkuZXlKcGMzTWlPaUpyZFdKbGNtNWxkR1Z6TDNObGNuWnBZMlZoWTJOdmRXNTBJaXdpYTNWaVpYSnVaWFJsY3k1cGJ5OXpaWEoyYVdObFlXTmpiM1Z1ZEM5dVlXMWxjM0JoWTJVaU9pSnJkV0psTFhONWMzUmxiU0lzSW10MVltVnlibVYwWlhNdWFXOHZjMlZ5ZG1salpXRmpZMjkxYm5RdmMyVmpjbVYwTG01aGJXVWlPaUpoWW1Oa2IyTnJaWEl0YzJFdGRHOXJaVzR0Y1d0aU4yTWlMQ0pyZFdKbGNtNWxkR1Z6TG1sdkwzTmxjblpwWTJWaFkyTnZkVzUwTDNObGNuWnBZMlV0WVdOamIzVnVkQzV1WVcxbElqb2lZV0pqWkc5amEyVnlMWE5oSWl3aWEzVmlaWEp1WlhSbGN5NXBieTl6WlhKMmFXTmxZV05qYjNWdWRDOXpaWEoyYVdObExXRmpZMjkxYm5RdWRXbGtJam9pTW1VMVpXRmpOV1F0TVRJNE9DMHhNV1ZoTFdFMU4yVXROVEkxTkRBd1pEZGlNamcwSWl3aWMzVmlJam9pYzNsemRHVnRPbk5sY25acFkyVmhZMk52ZFc1ME9tdDFZbVV0YzNsemRHVnRPbUZpWTJSdlkydGxjaTF6WVNKOS5uQlpIc0c5Yjhfa1ExcktDVFoyVDRlVjYzWGFsNnJ5TnRuOHBIODNEYnJSTTJMZEdwWThfa1hVWWYxd1dUMHFVTk1oVUZhZ2FaNXc2cmpwM2pwVkhwZEVCYnM2akhCRTJzY0tJYXZHMFVlQUtfaWl6TDRDWU8xakMwa0pxWk5YcmhWdWVfb0xsY0NLVTNCRHZ0QWVSS2tTbWZJdGpLZU5VT1pSZWlPT05KMzJIcmNpdUdDZ2xkWXpXSXp5OFd1dElXaGRoRVRHUjRNY2FZUVB0eWR5Sjk5bU5fMGk1NVdKQmI0a1VjbFBZeERmWlFnMlg0UmFxdl84ZS1ySGtoWnBjQThFVmQwQ0JfZFMyVTRCSjNRN0VqQ2tnOFZvNUkxa1llMFlDMEJxWS1NS2dGekR1QXphblpiTTV5dU9nanBxTG9Gd0s5UHYya0t3Mld5Vjh0NWM1RWc=
    ...
    

    同样还是将token使用base64进行解密
    echo "xx" |base64 -d
    image_1dqr7kqf7do84001rp317et1ipe54.png-628.5kB
    接下来我们使用获取到的token访问dashboard,查看相关权限是否正常 (clusterRoleBinding权限最大,所以说应该所有权限都有)
    image_1dqr7n4sc1etk1sak919g31e9t5h.png-74.1kB
    访问进来就没有error报错,也就是现在sa已经绑定到最高权限的clusterrole。可以访问所有资源对象,并且增删改查权限都有
    image_1dqr7onu2jo8lkiun8ls19u5u.png-205.9kB

    Kubernetes Dashboard 设置用户密码登陆

    新闻联播老司机

  • 19年5月20日
  • 喜欢:0
  • 浏览:6k
  • 相关文章:

    1. Kubernetes 1.14 二进制集群安装
    2. Kubenetes 1.13.5 集群二进制安装
    3. Kuerbernetes 1.11 集群二进制安装
    4. CentOS 7 ETCD集群配置大全

    相关文章

    KubeSphere 部署向量数据库 Milvus 实战指南
    探索 Kubernetes 持久化存储之 Longhorn 初窥门径
    征服 Docker 镜像访问限制!KubeSphere v3.4.1 成功部署全攻略
    那些年在 Terraform 上吃到的糖和踩过的坑
    无需 Kubernetes 测试 Kubernetes 网络实现
    Kubernetes v1.31 中的移除和主要变更

    发布评论