[Kubernetes]基于角色的权限控制之RBAC

电玩女神 2022-03-19 08:14 337阅读 0赞

Kubernetes中有很多种内置的编排对象,此外还可以自定义API资源类型和控制器的编写方式.那么,我能不能自己写一个编排对象呢?答案是肯定的.而这,也正是Kubernetes项目最具吸引力的地方.  
毕竟在互联网级别的大规模集群里,Kubernetes内置的编排对象,很难做到完全满足所有需求,所以很多实际的容器化工作,都会要求设计一个自己的编排对象,实现自己的控制器模式.  
所以,我们可以基于插件机制来完成这些工作,而不需要修改任何一行代码.但是,如果要通过外部插件,在Kubernetes中实现新增和操作API对象,那么就必须先了解一个非常重要的知识:RBAC.  
什么是RBAC呢?我们知道,Kubernetes中所有的API对象,都保存在Etcd里,但是呢,对这些API对象的操作,却一定都是通过访问kube-apiserver来实现的.其中一个非常重要的原因,就是你需要APIServer来帮助你做授权工作.而在Kubernetes项目中,负责完成授权(Authorization)工作的机制,就是RABC:基于角色的访问控制(Role-Based Access Control).

*  通过这篇文章,能明确三个基本的概念,就可以说收获不少了:  
    
    
     *  Role:角色.它其实是一组规则,定义了一组对Kubernetes API对象的操作权限 
     *  Subject:被作用者.既可以是"人",也可以是"机器",也可以是你在Kubernetes里定义的"用户"
     *  RoleBinding:定义了"被作用者"和"角色"的绑定关系.
 *  这三个概念,可以说是整个RABC体系的核心所在.所以接下来详细讲解一下. 
    
    <table> 
     <tbody> 
      <tr> 
       <td><font>Role</font></td> 
      </tr> 
     </tbody> 
    </table>
    
    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并不会提供任何实际的隔离或者多租户能力.  
    Role对象的rules字段,就是它所定义的权限规则.在这里规则的意思就是:允许"被作用者",对mynamespace下面的Pod对象,进行GET,WATCH和LIST操作.  
    那么,这个具体的"被作用者"又是如何指定的呢?这就需要通过RoleBinding来实现了.
    
    <table> 
     <tbody> 
      <tr> 
       <td><font>Subject与RoleBinding</font></td> 
      </tr> 
     </tbody> 
    </table>
    
    RoleBinding本身也是Kubernetes的API对象.定义如下:
    
        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对象里定义了一个subjects字段,即"被作用者".它的类型是User,即Kubernetes中的用户,这个用户的名字是example-user.但是,在Kubernetes中,并没有一个叫做"User"的API对象,这个User到底是从哪儿来的呢?  
    实际上,Kubernetes中的"User"就是"用户",只是一个授权系统里的逻辑概念.它需要通过外部认证服务来提供,或者也可以直接给APIServer指定一个用户名,密码文件.那么Kubernetes的授权系统,就可以从这个文件里找到对应的"用户".其实在大多数私有的使用环境中,只要使用Kubernetes提供的内置"用户",就足够了.  
    好像有点儿扯远了.这个等下再详细说吧.
    
    再往下看,能够看到roleRef字段.正是通过这个字段,RoleBinding对象就可以直接通过名字,来引用我们前面定义的Role对象(example-role),从而定义了"被作用者(Subject)"和"角色(Role)"之间的绑定关系.  
    在这里需要强调一下:Role和RoleBinding对象都是Namespaced对象,它们对权限的限制规则仅在它们自己的Namespace内有效,roleRef也只能引用当前Namespace中的Role对象.  
    那么,对于非Namespaced(Non-namespaced)对象(比如:Node),或者某一个Role想要作用于所有的Namespace时,我们又该怎么去做授权呢?  
    这时,就必须要使用ClusterRole和ClusterRoleBinding这两个组合了.这两个API对象的用法和Role与RoleBinding完全一样,只不过它们的定义里,没有了Namespace字段.  
    具体如下所示:
    
        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
    
    上面的例子中,意味着名叫example-user用户,拥有对所有Namespace里的Pod进行GET,WATCH和LIST操作的权限.更进一步的说,在Role或者ClusterRole里面,如果要赋予用户example-user所有权限,那么就可以给它指定一个verbs字段的全集,如下所示:
    
        verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
    
    当然,也可以根据自己的需求,只针对某一个具体的对象进行权限设置.比如:
    
        rules:
        - apiGroups: [""]
          resources: ["configmaps"]
          resourceNames: ["my-config"]
          verbs: ["get"]
    
    这个例子就表示,这条规则的"被作用者",只对名叫"my-config"的ConfigMap对象,有进行GET操作权限.  
    在上面提了一下,大多数时候,我们其实都不太使用"用户"这个功能,而是直接使用Kubernetes中的"内置用户",而这个"内置用户"就是:ServiceAccount.
    
    <table> 
     <tbody> 
      <tr> 
       <td><font>ServiceAccount分配权限的过程</font></td> 
      </tr> 
     </tbody> 
    </table>
    
    通过一个实例,来讲解一下为ServiceAccount分配权限的过程.  
    首先,需要定义一个ServiceAccount.它的API对象非常简单,如下所示:
    
        apiVersion: v1
        kind: ServiceAccount
        metadata:
          namespace: mynamespace
          name: example-sa
    
    可以看到,一个最简单的ServiceAccount对象,只需要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
    
    接下来,我们用kubectl命令创建这三个对象:
    
        $ kubectl create -f svc-account.yaml
        $ kubectl create -f role-binding.yaml
        $ kubectl create -f role.yaml
    
    然后,来查看一下ServiceAccount的详细信息:
    
        $ kubectl get sa -n mynamespace -o yaml
        - apiVersion: v1
          kind: ServiceAccount
          metadata:
            creationTimestamp: 2018-09-08T12:59:17Z
            name: example-sa
            namespace: mynamespace
            resourceVersion: "409327"
            ...
          secrets:
          - name: example-sa-token-vmfg6
    
    可以看到,Kubernetes会为一个ServiceAccount自动创建并分配一个Secret对象.这个Secret就是这个ServiceAccount对应的,用来和APIServer进行交互的授权文件,一般称它为:Token.  
    Token文件的内容一般是证书或者密码,它以一个Secret对象的方式,保存在Etcd当中.  
    此时,用户的Pod就可以声明使用这个ServiceAccount了.
    
    <table> 
     <tbody> 
      <tr> 
       <td><font>对以上内容的总结</font></td> 
      </tr> 
     </tbody> 
    </table>
    
    上面内容有些多,最后来一个总结:  
    所谓角色(Role),其实就是一组权限规则列表.分配这些权限的方式,就是通过创建RoleBinding对象,将被作用者(Subject)和权限列表进行绑定.  
    另外,与之对应的ClusterRole和ClusterRoleBinding,则是Kubernetes集群级别的Role和RoleBinding,它们的作用范围不受Namespace限制.  
    尽管权限的被作用者可以用很多种(比如,User,Group等),但在我们平常的使用中,最普遍的用法还是ServiceAccount.所以,Role+RoleBinding+ServiceAccount的权限分配方式,是最应该掌握的内容.
    
    以上内容来自我学习<深入剖析Kubernetes>专栏文章之后的一些见解,有偏颇之处,还望指出.  
    感谢您的阅读~