Kubernetes生产实践系列之一：Kubernetes基于RBAC的访问权限控制

红太狼 2022-01-14 11:09 413阅读 0赞

### 一、前言 ###

在Kubernetes的使用过程中，用户和集群各类资源对象的关系是最初始也是最基本的需要解决的问题。在Kubernetes的体系中，用户账号叫做subject，包括两个种类：User和ServiceAccount，前者给个人使用，后者给Pod使用；而所有的namespace级别和集群级别的资源叫做object；Kubernetes使用RBAC机制操作subject和object，来向外部提供干预系统状态的干预者的认证和授权机制。在v1.6之前，Kubernetes使用ABAC进行权限管理，在v1.8之后RBAC机制进入稳定阶段。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Nsb3VkdnRlY2g_size_16_color_FFFFFF_t_70][]

通过使用RBAC机制，是的系统管理员、研发、测试等不同集群使用者就能更细粒度使用和管理集群的资源，满足多namespace、多种权限(只读、读写、跨namespace读/写)等需求。

转载自https://blog.csdn.net/cloudvtech

### 二、用户账户的建立和认证 ###

集群外部实体(管理员、namespace用户或者服务研发)和集群内部实体(Kubernetes系统和部署于集群上应用)都会有访问和调控系统资源的需求，外部实体使用User(Kubernetes有一个User类型的资源来代表)进行集群访问接入，内部实体(Pod里面的进程)使用ServiceAccount进行集群访问接入。User账户是没有namespace属性的，ServiceAccount账户是有namespace属性的。

对于外部用户账户，实际上，使用集群ca证书和用户的签名证书为用户颁发的集群访问证书，只是表明外部用户被认证过能访问API Server接口，但是在管理员将这个用户通过Kind:User注册到集群之前， API Server是不会响应资源操作请求的。除了上述使用签名证书方式来验证外部用户(用户的名字在制作证书的时候的CN属性里面填写)之外，还可以通过静态token文件或者静态密码文件进行外部用户验证，但是这要求在API Server启动的时候指定这些静态文件。

对于内部用户账户ServiceAccount(sa)，可以用于授权Pod里面的进程访问API Server，它所对应的secret的token可以用于集群外部进程访问API Server。API Server被创建之后，token controller会为这个sa建立一个secret object：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Nsb3VkdnRlY2g_size_16_color_FFFFFF_t_70 1][]

在POD启动时，如果指定使用该sa，则sa对应secret里面的token和ca文件会被自动挂载到容器的/var/run/secrets/kubernetes.io/serviceaccount/目录：

> Containers:
> 
>   nginx:
> 
>     Container ID:   docker://d5fee046729b8010c7fa0f6d7abd0c6bf08238dce0041979124bd143e6b3eb53
> 
>     Image:          172.2.2.11:5000/nginx:1.14
> 
>     ......
> 
>     Mounts:
> 
> **      /var/run/secrets/kubernetes.io/serviceaccount from default-token-khs2h (ro)**
> 
> ......
> 
> **Volumes:**
> 
> **  default-token-khs2h:**
> 
>     Type:        Secret (a volume populated by a Secret)
> 
>     SecretName:  default-token-khs2h
> 
>     Optional:    false

### 2.1 建立外部认证用户 ###

**为用户生成证书**

Generate private key
    openssl genrsa -out myuser.key 2048
    Generating RSA private key, 2048 bit long modulus
    .................+++
    .......................................+++
    e is 65537 (0x10001)
    
    Generate CSR(证书签名请求)
    openssl req -new -key myuser.key -out myuser.csr -subj "/CN=myuser/O=MGM”
    
    通过集群的CA证书和之前创建的csr文件，来为用户颁发证书
    openssl x509 -req -in myuser.csr -CA  /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out myuser.crt -days 3650

其中CN为用户名；最后将证书(myuser.crt)和私钥(myuser.key)保存起来，这两个文件将被用来验证API请求。

### 2.2 建立内部认证用户 ###

apiVersion: v1
    kind: ServiceAccount
    metadata:
      name: mynamespace-user
      namespace: mynamespace

转载自https://blog.csdn.net/cloudvtech

### 三、Kubernetes中可被管理的资源 ###

Kubernetes所有可被管理的资源实体叫做object，在kubernetes.io网站上关于object的描述如下：

> *Kubernetes objects* are persistent entities in the Kubernetes system. Kubernetes uses these entities to represent the state of your cluster. Specifically, they can describe:
> 
>  *  What containerized applications are running (and on which nodes)
>  *  The resources available to those applications
>  *  The policies around how those applications behave, such as restart policies, upgrades, and fault-tolerance

Kubernetes集群的工作就是根据obejct的spec(yaml)，使用各种controller将object调整到期望的状态(Status)；而向Kubernetes集群提出object描述及其状态期望，就会使用到User或者ServiceAccount。集群认可的object由如下一些字段进行描述：

>  *  `apiVersion` 
>  *  `kind`
>  *  `metadata` 
>  *  `spec`

这些object有的是具有namepace属性的(比如pods、deployments、services、serviceaccounts、ingresses、configmaps、persistentvolumeclaims等)，有的是全集群范围的(比如nodes、namespaces、persistentvolumes、storageclasses等)，一个示例集群的object及其属性状况可以通过运行kubectl api-resources命令获得：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Nsb3VkdnRlY2g_size_16_color_FFFFFF_t_70 2][]

针对这些对象还可以执行不同的动作(verbs)：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Nsb3VkdnRlY2g_size_16_color_FFFFFF_t_70 3][]

后续在进行集群权限管理的时候，这些object是进行管理的最小集合，而针对某个object，还有create、get、list、watch、update、patch、delete等verb操作进行行为权限的细粒度控制。在RBAC管理机制中的Role其实就是一系列object+verbs的组合，比如下面这个例子就是一个可以创建和读取POD的Role：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Nsb3VkdnRlY2g_size_16_color_FFFFFF_t_70 4][]

转载自https://blog.csdn.net/cloudvtech

### 四、基于RABC的授权管理 ###

计算机系统的权限管理不是一个新话题，无论是VAX这样的早期共享系统、网络防火墙、商业数据库还是Linux内核，都需要根据自己的业务特点来设计一套权限管理机制，保证系统的状态在不同的粒度上可调可控。权限系统模型根据业务需求会有各种变种，基本的一些模型包括ACL、DAC、MAC、RBAC、ABAC等，Kubernetes在v1.8以后提供稳定版本的RABC权限管理机制。

在RBAC模型中，需要Subject、Resource Entity和Operation进行组合来赋予某个账户特定的操作权限：

> Subject：User、ServiceAccount
> 
> Resource Entity：Kubernetes Objects
> 
> Operations：Verbs(create、get、list、watch、update、patch、delete)

RBAC模型的核心概念如下：

>  *  Verbs和Kubernetes Objects的组合叫做role，针对namespaced的object的叫做Role，而针对非namespaced的object叫做ClusterRole
>  *  将Role和Subject进行关联的行为叫做RoleBinding
>  *  将ClusterRole和Subject进行关联的行为叫做ClusterRoleBinding

在Kubernetes的RBAC模型中Objects、Verbs、Role、ClusterRole、RoleBinding和ClusterRoleBinding的相互交互关系如下：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Nsb3VkdnRlY2g_size_16_color_FFFFFF_t_70 5][]

### 4.1 给外部账户授权 ###

定义一个在mynamespace这个namespace对POD只有只读权限的Role：

apiVersion: rbac.authorization.k8s.io/v1
    kind: Role
    metadata:
      namespace: mynamespace
      name: pod-reader
    rules:
    - apiGroups: [""] # "" indicates the core API group
      resources: ["pods"]
      verbs: ["get", "watch", "list"]

将这个Role授权给之前建立的myuser这个外部账户，RoleBinding.yaml :

kind: RoleBinding
    apiVersion: rbac.authorization.k8s.io/v1beta1
    metadata:
      name: my-rolebinding
      namespace: mynamespace
    subjects:
    - kind: User
      name: myuser
      apiGroup: ""
    roleRef:
      kind: Role
      name: pod-reader
      apiGroup: ""

为人员使用外部账户创建kubeconfig，将myuser.crt和myuser.key文件的内容放入myuser.kubeconfig(需要注意的是这个kubeconfig是无法用于dashboard登陆的，kubeconfig文件需要配置token字段之后才能用于dashboard登陆)：

apiVersion: v1
    kind: Config
    preferences: {}
    # Define the cluster
    clusters:
    - cluster:
        certificate-authority-data: k8s_ca_data
        # You'll need the API endpoint of your Cluster here:
        server: https://128.0.0.1:6443
      name: myuser-cluster
    # Define the user
    users:
    - name: myuser
      user:
        client-certificate-data: client_ca_data
        client-key-data: client_key_data
    # Define the context: linking a user to a cluster
    contexts:
    - context:
        cluster: myuser-cluster
        namespace: mynamespace
        user: myuser
      name: myuser-context
    # Define current context
    current-context: myuser-context

### 4.2 给内部账户授权 ###

access.yaml(这是一个mynamespace只读的例子)：

---
    apiVersion: v1
    kind: ServiceAccount
    metadata:
      name: mynamespace-user
      namespace: mynamespace
    ---
    kind: Role
    apiVersion: rbac.authorization.k8s.io/v1beta1
    metadata:
      name: mynamespace-user-full-access
      namespace: mynamespace
    rules:
    - apiGroups: ["", "extensions", "apps"]
      resources: ["*"]
      verbs: ["*"]
    - apiGroups: ["batch"]
      resources:
      - jobs
      - cronjobs
      verbs: ["*"]
    ---
    kind: RoleBinding
    apiVersion: rbac.authorization.k8s.io/v1beta1
    metadata:
      name: mynamespace-user-view
      namespace: mynamespace
    subjects:
    - kind: ServiceAccount
      name: mynamespace-user
      namespace: mynamespace
    roleRef:
      apiGroup: rbac.authorization.k8s.io
      kind: Role
      name: mynamespace-user-full-access

同时也可以通过

> kubectl get secret mynamespace-user-token-h67bk -n mynamespace -o "jsonpath=\{.data.token\}" | base64 -d

和

> kubectl get secret mynamespace-user-token-h67bk -n mynamespace -o "jsonpath=\{.data\['ca\\.crt’\]\}"

分别获取token和ca来构建针对这个serviceaccount的kubeconfig文件mynamespace.kubeconfig：

apiVersion: v1
    kind: Config
    preferences: {}
    # Define the cluster
    clusters:
    - cluster:
        certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUN5RENDQWJDZ0F3SUJBZ0lCQURBTkJna3Foa2lHOXcwQkFRc0ZBREFWTVJNd0VRWURWUVFERXdwcmRXSmwKY201bGRHVnpNQjRYRFRFNE1Ea3hPVEEyTlRZME9Gb1hEVEk0TURreE5qQTJOVFkwT0Zvd0ZURVRNQkVHQTFVRQpBeE1LYTNWaVpYSnVaWFJsY3pDQ0FTSXdEUVlKS29aSWh2Y05BUUVCQlFBRGdnRVBBRENDQVFvQ2dnRUJBT2lhCjhSTWs2N0FRNWVpelBvYVcvTWptQlBtU2xoSFowVkkxcUcwcjI4bnVON2Jya29XeGNTMzgvdklkSFZySmR4Z3MKTS9iQzBORnFwZW54dkRTK2ZyY21TdnhYWDRmdHZ2MkdNRC8vVHdtRGxzNVU1eEZFR1pkNCtBbEZ5N3hnK0FTegpweHd5RDlXZVRwRi9Dc2c1RVBPTk5rSVJodFRVZFJxM2xVVGpDK1hZUGFVTzlUb3hkdkNzQ0VocWRpZGUrL3p4CitPbEhuVXplQzBCVVZvQTJkNGMwbUZEYVhLZFE5NlFIR0FqSGJiMTBoMlNXTDNSNXlpM1dVQjBQcjZxUzZsa08KL3Y5anBBVmRjLzNoeFRsbWZ4UWFMT284cUxpKzFtTmsvSTRwYXZkY0F0emVhUHRZVWw5ME1EaUNla2hCcTNPUQpORllGTXlmRDF4Z3o5ODRPQ1hNQ0F3RUFBYU1qTUNFd0RnWURWUjBQQVFIL0JBUURBZ0trTUE4R0ExVWRFd0VCCi93UUZNQU1CQWY4d0RRWUpLb1pJaHZjTkFRRUxCUUFEZ2dFQkFBMzd6NDVpYjhwMWxwRnYwbW90aHZpR3NBOEEKV0IzOVNGWnRySXJkVmtpSXgzd2huVWtXcWVhUHc3T3JZVE5IanFTNjJiS1RwcENQT2pFc09WUnlyaHg4S0FZQwpTTG5CS3p5ZG1PdUgvNmFrWjA4bUliSkl5d2dIajJpVmRuYXc3N25kTGVxNWlESERLQW5ZcGVuUjYyOTVYdCtXCjgvVGVVYnBhUEdONnZDYWF2Qks2enQyMjRuWERhQlBQbHNXeVlVMWVZL1hsb0liTXluelcwQy81aGhYbFY0aGwKLzNVdEozM1duNVNpK2lHRHNoeXpnUDZNSXJ6UGxFaTE2b0EweTNHRHFxQm16NEJZMnV4V2hpZXFQc0JnazlWQgpISVI5eUx0YUIzU2VGcVl3R21zRlhtMzE1M0VhY0VTSzhTRktacTFhWXNSNXoxZ1pFV3BITXQ1M00rRT0KLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo=
        # You'll need the API endpoint of your Cluster here:
        server: https://128.0.0.1:6443
      name: my-cluster
    # Define the user
    users:
    - name: mynamespace-user
      user:
        as-user-extra: {}
        token: eyJhbGciOiJSUzI1NiIsImtpZCI6IiJ9.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJteW5hbWVzcGFjZSIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VjcmV0Lm5hbWUiOiJteW5hbWVzcGFjZS11c2VyLXRva2VuLWg2N2JrIiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZXJ2aWNlLWFjY291bnQubmFtZSI6Im15bmFtZXNwYWNlLXVzZXIiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC51aWQiOiI3ODBhMjhjNS1jZGMxLTExZTgtOTEzNS1mYTE2M2ViZGExYjgiLCJzdWIiOiJzeXN0ZW06c2VydmljZWFjY291bnQ6bXluYW1lc3BhY2U6bXluYW1lc3BhY2UtdXNlciJ9.erWv2a6WdzD9ikWc2zvykudwFuxE65nYJhtkf7m3b_EoIwdAGEoKU-zqVRbwl7e9uGMba6nAQZIP155t93KSu23ZynAnjyHci1k9raTec92sb_d-YyuWWEs6IK4a-ziQaeTUHa6p6dvlmBoYLYFJDhkjX705OyOvr8-Zz3LZWc1TgYdtuD398jEAGQ74kg3sms6PBBDDisOJRTHxSiZ41GG9iGnqGdv2LGVV1S7K724pu-QcFQHMom1i3FTkBo3pGeZK-EF-ZPKCkHCG586T_F2phWAK5YVUSCwYwNhCH_YeLsc6kvkM2Xb3rJXXjVp_CaMqKbpygIjpPO8tYinrqQ
    # Define the context: linking a user to a cluster
    contexts:
    - context:
        cluster: my-cluster
        namespace: mynamespace
        user: mynamespace-user
      name: mynamespace
    # Define current context
    current-context: mynamespace

转载自https://blog.csdn.net/cloudvtech

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Nsb3VkdnRlY2g_size_16_color_FFFFFF_t_70]: /images/20220114/3f20d18054194b448cac19f002535f45.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Nsb3VkdnRlY2g_size_16_color_FFFFFF_t_70 1]: /images/20220114/1dd2071112e14ed89d3a83e16212ea6d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Nsb3VkdnRlY2g_size_16_color_FFFFFF_t_70 2]: /images/20220114/23142c3821b74cf191d6ad732e26aa1a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Nsb3VkdnRlY2g_size_16_color_FFFFFF_t_70 3]: /images/20220114/5d651abc62be4387a7c56dce8c4ce219.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Nsb3VkdnRlY2g_size_16_color_FFFFFF_t_70 4]: /images/20220114/e498a99d22764e049710e716fbfa51eb.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Nsb3VkdnRlY2g_size_16_color_FFFFFF_t_70 5]: /images/20220114/5410b11a0dad46a88d7d197e177a75b7.png