kubernete编排技术六:RBAC权限控制

发布于 2022-5-1 09:01
浏览
0收藏

作者 |  朱晋君
来源 | 君哥聊技术(ID:gh_1f109b82d301)

这是kubernete编排技术的第六篇,本文主要讲一下RBAC。之前讲过,kubernete所有API对象,都保存在etcd里。要访问和操作这些对象,一定会通过apiserver,因为apiserver可以做授权工作。

kubernete发展至今,授权模式一共有如下6种,其中RBAC这种授权模式从1.8开始已经成了稳定功能,只要设置通过设置–authorization-mode=RBAC就可以启用。

  • 基于属性的访问控制ABAC
  • 基于角色的访问控制RBAC
  • Webhook
  • Node
  • 总是拒绝AlwaysDeny
  • 总是允许AlwaysAllow

作为业务开发者,我们多多少少也接触过授权,比如spring security,sso等。其实RBAC的授权很类似,它有3个角色相关定义:Role(角色)、Subject(主体或被作用者)和RoleBinding(绑定),还有2个规则:资源、操作类型。

所以在RBAC中,需要api授权的时候,首先需要定义Role,然后需要定义Role和subject绑定关系RoleBinding,定义角色的时候需要指定该角色可以访问的资源和操作类型。

定义Role和ClusterRole

Role首先是一个api对象,在kubernete中有2种,Role和ClusterRole,很明显这2个就是普通角色和集群角色。定义的时候只要把yaml中的kind指定为Role就可以了。下面我们定义了一个名字叫test-role的Role,这个Role可以对namespace是mynamespace的pod进行get、watch和list操作。

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

下面我们再定义一个名字叫secret-reader的ClusterRole,需要注意集群角色是没有namespace的(因为集群角色不需要namespace进行逻辑隔离),这里定义的资源类型是secrets,secrets也是一种api对象,后面再讲,操作类型跟上面的Role一样。

kind:ClusterRole
apiVersion:rbac.authorization.k8s.io/v1
metadata:
  name:secret-reader
rules:
- apiGroups:[""]
  resources:["secrets"]
  verbs:["get","watch","list"]

注意:

1.如果我们要给当前角色赋予所有权限,可以定义verbs如下:

verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

2.这儿也可以针对具体的对象进行设置,比如下面就是只能对name是my-config的configmaps资源进行get操作。

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

3.kubernete提供了四个预先定义好的ClusterRole供用户使用:cluster-admin(集群中所有操作)、admin(单节点所有操作)、edit(读写操作)、view(只读操作)。

需要提一下的是,cluster-admin对应的是整个集群中的最高权限(verbs=*)。下面的命令可以看出每个角色的权限列表:

kubectl describe clusterrole cluster-admin -n kube-system
kubectl describe clusterrole admin -n kube-system
kubectl describe clusterrole edit -n kube-system
kubectl describe clusterrole view -n kube-system

角色的绑定RoleBinding

RoleBinding也是一个api对象,所以定义的时候只要申明kind是RoleBinding就可以了。下面这个RoleBinding名字叫test-rolebinding,定义了一个subjects即被作用对象,是一个叫jinjunzhu的用户。简而言之,就是jinjunzhu这个用户绑定了test-role这个角色,从而绑定了资源的get、watch和list操作。

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

RoleBinding也可以绑定集群角色角色,这个绑定只能在mynamespace中生效,绑定的正是我们前面定义的名字叫做secret-reader的ClusterRole,这样管理员可以在集群中复制这个公共角色,然后在命名空间中进行复用。yaml文件代码如下:

kind:RoleBinding
apiVersion:rbac.authorization.k8s.io/v1
metadata:
  name:read-secrets
  namespace:mynamespace
subjects:
- kind:User
  name:jinjunzhu
  apiGroup:rbac.authorization.k8s.io
roleRef:
  kind:ClusterRole
  name:secret-reader
  apiGroup:rbac.authorization.k8s.io

下面再看一个ClusterRoleBinding,这儿定义的被作用者subject是一个名字叫做jinjunzhu的Group,绑定关系是名字叫做secret-reader,这个绑定允许jinjunzhu这个组中的所有用户对集群中任何namespace中的secrets进行get、watch和list操作。

kind:ClusterRoleBinding
apiVersion:rbac.authorization.k8s.io/v1
metadata:
  name:read-secrets-global
subjects:
- kind:Group
  name:jinjunzhu
  apiGroup:rbac.authorization.k8s.io
roleRef:
  kind:ClusterRole
  name:secret-reader
  apiGroup:rbac.authorization.k8s.io

注意:这个绑定关系是没有namespace定义的。

主体或被作用者subject

在上面的subjects定义中,使用到了User和Group。

首先我们介绍一下User,它实际上是一个为了授权的逻辑概念。一般情况下,kubernete集群为我们提供的内置用户就能满足我们使用了,我们也可以通过外部认证服务比如keystone或者直接给APIServer指定用户名密码文件来指定。

如下是名字是jinjunzhu的用户:

subjects:
- kind:User
  name:jinjunzhu
  apiGroup:rbac.authorization.k8s.io

而Group只是一组User,这一组用户也可以由外服授权服务来提供。

下面这个定义是用户名为jinjunzhu的Group:

subjects:
- kind:Group
  name:jinjunzhu
  apiGroup:rbac.authorization.k8s.io

注意:

ServiceAccount中Users,在kubernete里对应的name是:

system:serviceaccount:<Namespace名字>:<ServiceAccount名字>

ServiceAccount中Group,在kubernete里对应的name是:

system:serviceaccounts:<Namespace名字>

下面这个定义是所有的用户:

subjects:
- kind:Group
  name:system:authenticated #授权过的
  apiGroup:rbac.authorization.k8s.io
- kind:Group
  name:system:unauthenticated #未授权过的
  apiGroup:rbac.authorization.k8s.io

下面的定义是所有内置用户:

subjects:
- kind:Group
  name:system:serviceaccounts
  apiGroup:rbac.authorization.k8s.io

下面的定义是所有namespace是jinjunzhu的所有内置用户:

subjects:
- kind:Group
  name:system:serviceaccounts:jinjunzhu
  apiGroup:rbac.authorization.k8s.io

关于如何使用外部授权服务,这里就不再详细介绍了。

进行试验

上面我们提到过,一般情况下,kubernete为我们提供的内置用户就能满足我们使用了,这个内置用户或者用户组就是ServiceAccount。

首先我定义一个name是jinjunzhu的ServiceAccount,serviceaccount.yaml文件内容如下:

apiVersion: v1
kind: ServiceAccount
metadata:
  namespace: mynamespace
  name: jinjunzhu

接着我们定义一个Role,Role.yaml文件内容如下:

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

然后我们定义RoleBinding,RoleBinding.yaml文件内容如下:

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

因为上面用到了mynamespace,我们需要创建这个namespace, mynamespaces.yaml文件内容如下:

apiVersion: v1
kind: Namespace
metadata:
   name: mynamespace
   labels:
     name: mynamespace

下面我们创建这4个api对象,命令如下:

kubectl create -f mynamespaces.yaml
kubectl create -f serviceaccount.yaml 
kubectl create -f Role.yaml 
kubectl create -f RoleBinding.yaml 

创建成功后,首先我们看一下ServiceAccount,kubernete为它分配了简写sa,查看时可以使用:

[root@master rbac]# kubectl get sa -n mynamespace -o yaml
apiVersion: v1
items:
- apiVersion: v1
  kind: ServiceAccount
  metadata:
    creationTimestamp: "2020-08-16T07:11:37Z"
    name: default
    namespace: mynamespace
    resourceVersion: "2354"
    selfLink: /api/v1/namespaces/mynamespace/serviceaccounts/default
    uid: 4d234ef6-7a44-4ffc-bcd2-3a1a490eef0a
  secrets:
  - name: default-token-2tjlh
- apiVersion: v1
  kind: ServiceAccount
  metadata:
    creationTimestamp: "2020-08-16T07:14:34Z"
    name: jinjunzhu
    namespace: mynamespace
    resourceVersion: "2761"
    selfLink: /api/v1/namespaces/mynamespace/serviceaccounts/jinjunzhu
    uid: 31e92f92-e2dd-40dc-8a73-822b3be4c637
  secrets:
  - name: jinjunzhu-token-qxttq
kind: List
metadata:
  resourceVersion: ""
  selfLink: ""

从上面的输出可以看到,kubernete为jinjunzhu这个ServiceAccount分配了一个secrets,这个名字叫jinjunzhu-token-qxttq的secrets,它就是用来跟apiserver进行交互的token信息,只不过是以secrets对象的格式信息保存在etcd当中。

然后,我们从下面的输出可以看出,Role和RoleBinding已经创建成功了。

[root@master rbac]# kubectl get Role -n mynamespace
NAME        AGE
test-role   6m19s
[root@master rbac]# kubectl get RoleBinding -n mynamespace
NAME               AGE
test-rolebinding   6m8s

这时我们定义一个pod,这个pod名字叫sa-pod,镜像是我之前使用的一个springboot镜像,我们定义这个pod使用我们刚刚创建的名字叫jinjunzhu的ServiceAccount,

apiVersion: v1
kind: Pod
metadata:
  namespace: mynamespace
  name: sa-pod
spec:
  containers:
  - name: spingboot-mybatis
    imagePullPolicy: IfNotPresent
    image: zjj2006forever/springboot-mybatis:1.3
  ports:
    - containerPort: 8300
  serviceAccountName: jinjunzhu

这个文件我们命名为sa-pod.yaml,然后创建这个pod,命令如下:

kubectl create -f sa-pod.yaml

创建成功后,我们用describe看一下这个pod的详情:

[root@master rbac]# kubectl describe pod sa-pod -n mynamespace
Name:         sa-pod
Namespace:    mynamespace
Priority:     0
Node:         worker1/192.168.59.141
Start Time:   Sun, 16 Aug 2020 03:40:56 -0400
Labels:       <none>
Annotations:  <none>
Status:       Running
IP:           10.244.1.2
IPs:
  IP:  10.244.1.2
Containers:
  spingboot-mybatis:
    Container ID:   docker://8cb76ef92f94f128adedddd3dfc1d401cc238b2eef74af507c39b3d3e210814e
    Image:          zjj2006forever/springboot-mybatis:1.3
    Image ID:       docker-pullable://zjj2006forever/springboot-mybatis@sha256:502c368a0a0ea9dc38c8175f2b97aa7527336dea314b3712151fccefe957eaf8
    Port:           8300/TCP
    Host Port:      0/TCP
    State:          Running
      Started:      Sun, 16 Aug 2020 03:40:57 -0400
    Ready:          True
    Restart Count:  0
    Environment:    <none>
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from jinjunzhu-token-qxttq (ro)
Conditions:
  Type              Status
  Initialized       True 
  Ready             True 
  ContainersReady   True 
  PodScheduled      True 
Volumes:
  jinjunzhu-token-qxttq:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  jinjunzhu-token-qxttq
    Optional:    false
QoS Class:       BestEffort
Node-Selectors:  <none>
Tolerations:     node.kubernetes.io/not-ready:NoExecute for 300s
                 node.kubernetes.io/unreachable:NoExecute for 300s
Events:
  Type    Reason     Age   From               Message
  ----    ------     ----  ----               -------
  Normal  Scheduled  102s  default-scheduler  Successfully assigned mynamespace/sa-pod to worker1
  Normal  Pulled     101s  kubelet, worker1   Container image "zjj2006forever/springboot-mybatis:1.3" already present on machine
  Normal  Created    101s  kubelet, worker1   Created container spingboot-mybatis
  Normal  Started    101s  kubelet, worker1   Started container spingboot-mybatis

上面输出的Mounts部分信息我们可以看到,前面我们创建jinjunzhu这个ServiceAccount时生成的token已经挂载到了一个目录下面,这是我们进入这个容器内部,如下所示:

[root@worker1 kubernetes]# kubectl exec -it sa-pod -n mynamespace -- /bin/sh
/ # cd /var/run/secrets/kubernetes.io/serviceaccount
/run/secrets/kubernetes.io/serviceaccount # ls
ca.crt     namespace  token

可以看到容器里面已经有了一个ca.crt文件,容器里的应用就是用这个文件来访问apiserver的。根据前面Role定义,这个ServiceAccount的操作权限只有get、watch和list。

最后要说的是,如果我们声明pod的时候,没有定义serviceAccountName,kubernete会怎么控制pod的操作权限呢?

还是上面的sa-pod.yaml,我们删除serviceAccountName,重新创建pod,然后用describe看一下详情,下面是我截取了部分输出:

[root@master rbac]# kubectl describe pod sa-pod -n mynamespace
Name:         sa-pod
Namespace:    mynamespace
Priority:     0
Node:         worker1/192.168.59.141
Start Time:   Sun, 16 Aug 2020 04:12:02 -0400
Labels:       <none>
Annotations:  <none>
Status:       Running
IP:           10.244.1.3
IPs:
  IP:  10.244.1.3
Containers:
  spingboot-mybatis:
    Container ID:   docker://8c73ccba58581c6d78714463d65fb75cb5733a7a6aa4b57d635a8fc4e2068f0f
    Image:          zjj2006forever/springboot-mybatis:1.3
    Image ID:       docker-pullable://zjj2006forever/springboot-mybatis@sha256:502c368a0a0ea9dc38c8175f2b97aa7527336dea314b3712151fccefe957eaf8
    Port:           8300/TCP
    Host Port:      0/TCP
    State:          Running
      Started:      Sun, 16 Aug 2020 04:12:03 -0400
    Ready:          True
    Restart Count:  0
    Environment:    <none>
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-2tjlh (ro)
Conditions:
  Type              Status
  Initialized       True 
  Ready             True 
  ContainersReady   True 
  PodScheduled      True 
Volumes:
  default-token-2tjlh:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  default-token-2tjlh
    Optional:    false
QoS Class:       BestEffort
Node-Selectors:  <none>
Tolerations:     node.kubernetes.io/not-ready:NoExecute for 300s
                 node.kubernetes.io/unreachable:NoExecute for 300s
Events:
  Type    Reason     Age   From               Message
  ----    ------     ----  ----               -------
  Normal  Scheduled  37s   default-scheduler  Successfully assigned mynamespace/sa-pod to worker1
  Normal  Pulled     37s   kubelet, worker1   Container image "zjj2006forever/springboot-mybatis:1.3" already present on machine
  Normal  Created    37s   kubelet, worker1   Created container spingboot-mybatis
  Normal  Started    36s   kubelet, worker1   Started container spingboot-mybatis

可以看到,kubernete会为这个pod创建一个名字叫default的ServiceAccount,然后为它绑定一个特殊的Secret,我们看一下详情:

[root@master rbac]# kubectl get secret
NAME                  TYPE                                  DATA   AGE
default-token-zjndz   kubernetes.io/service-account-token   3      81m
[root@master rbac]# kubectl describe secret default-token-zjndz
Name:         default-token-zjndz
Namespace:    default
Labels:       <none>
Annotations:  kubernetes.io/service-account.name: default #这个可以看到这个Secret会跟名字是default的ServiceAccount进行绑定
              kubernetes.io/service-account.uid: f7cd1a1e-9be7-42ba-a0fc-0aa7a8150a9e

Type:  kubernetes.io/service-account-token

Data
====
ca.crt:     1025 bytes
namespace:  7 bytes
token:      eyJhbGciOiJSUzI1NiIsImtpZCI6IlNvT3BWUkY0WWlrQWd2Qm1iT2cwZGJDdF94UU9JT3JrREszbWpLZ0RDZHcifQ.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJkZWZhdWx0Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZWNyZXQubmFtZSI6ImRlZmF1bHQtdG9rZW4tempuZHoiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC5uYW1lIjoiZGVmYXVsdCIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50LnVpZCI6ImY3Y2QxYTFlLTliZTctNDJiYS1hMGZjLTBhYTdhODE1MGE5ZSIsInN1YiI6InN5c3RlbTpzZXJ2aWNlYWNjb3VudDpkZWZhdWx0OmRlZmF1bHQifQ.YUt48ZYexbxpioOoODGQ6UnrK6urKMFU5NwaGT1PCJe-inqM4ZKWuCxAb6Rd8JubRtf7JhKQOkjNIQcEe0jrjrSu25q0Zc485b_Nm20GRvB6smWC59lG6wJ2U4aanx4IAewTFCZsmct-1G8CU5YxY7gyvklbf2FWzplvCkeLOXx2kH-KHETbZuRDcNUXq-qo2G_X5_feyGRnDrL9tKuk7aBKsSYoQcwE2GWzSClPn9w8T7F2U139cWtI2T_Rk7K_85bk_-4o5AIdTcSLFckB8J4gbm2lDTS5sVxG-njFb7rOZq50xMsMfamPc350MZibgSiszqYzNNb_GgLqIwL16A

注意:default的ServiceAccount拥有的访问apiserver的权限比较多,所以我们一般应该声明一个ServiceAccount进行绑定,用来对操作权限进行控制。

总结

kubernete基于角色的访问控制,其实是通过Role和RoleBinding来实现的,角色中定义了操作权限,然后跟User进行绑定,这个User一般可以用ServiceAccount对象。跟集群相关的访问控制还有ClusterRole和ClusterRoleBinding,这2个对象是集群范围的,不受namespace的限制。

收藏
回复
举报
回复
添加资源
添加资源将有机会获得更多曝光,你也可以直接关联已上传资源 去关联
    相关推荐