经验首页 前端设计 程序设计 Java相关 移动开发 数据库/运维 软件/图像 大数据/云计算 其他经验
当前位置：技术经验 » 数据库/运维 » Kubernetes » 查看文章
普通程序员看k8s基于角色的访问控制（RBAC）
来源：cnblogs　　作者：wilson排球　　时间：2019/4/16 8:41:46　　对本文有异议

一、知识准备

● 上一节描述了k8s的账户管理，本文描述基于角色的访问控制
● 网上RBAC的文章非常多，具体概念大神们也解释得很详细，本文没有站在高屋建瓴的角度去描述RBAC，而是站在一个普通程序员的视角，去看待RBAC
● 我理解的基于角色的访问控制，如图：

  1.                                         +------------+
  2.                           +------------>|all:resource|-+
  3.                           |             +------------+ |       +----------------+
  4.                      +----+---+                        |       |                |
  5. +------+             |role:   |                        +------>+  namespaces    |
  6. |user1 |------------>|admin   |                                |                |
  7. +------+             +--------+         +------------+         |  pod           |
  8.                                   +---->|get:pod     |-------->+                |
  9.                                   |     +------------+         |  service       |
  10.                                   |                            |                |
  11. +------+             +--------+   |                            |  deployment    |
  12. |user2 |------------>|role:   |---+                            |                |
  13. +------+             |guest   |         ....                   |  daemonsets    |
  14.                      +--------+                                |                |
  15.                                                                |  ...           |
  16.                                         +------------+         |                |
  17.                                         |list:service|         +----------------+
  18.                                         +------------+

账户：请求kube-api必要的身份验证。身份验证之后只是被允许进入集群，但是不一定有访问资源的权限
角色：账户登录之后扮演的角色
规则：在k8s集群内允许的操作。比如get namespace、get pod等
资源：k8s各种各样的资源
角色绑定：资源与规则组成访问权限，将角色绑定在访问权限上，最后账户登录之后扮演不同的角色


二、环境准备

组件 版本
OS Ubuntu 18.04.1 LTS
docker 18.06.0-ce
k8s v1.10.1


三、创建角色

角色分为role与clusterrole，区别在于前者是namespace级别，后者是整个k8s cluster级别

（1）创建role

创建一个default namespace的普通角色，权限是对pod的get、list、watch

  1. apiVersion: rbac.authorization.k8s.io/v1
  2. kind: Role
  3. metadata:
  4.   name: po_r
  5.   namespace: default
  6. rules:
  7. - apiGroups:
  8.   - ""
  9.   resources:
  10.   - pods
  11.   verbs:
  12.   - get
  13.   - list
  14.   - watch

（2）创建clusterrole

创建一个具有pod的get、list、watch的clusterrole，这个角色是cluster级别的，也就是所有的namespace

  1. apiVersion: rbac.authorization.k8s.io/v1
  2. kind: ClusterRole
  3. metadata:
  4.   name: cluster_po_r
  5. rules:
  6. - apiGroups:
  7.   - ""
  8.   resources:
  9.   - pods
  10.   verbs:
  11.   - get
  12.   - list
  13.   - watch

四、userAccount角色绑定

（1）role绑定

先将上一节的mrvolleyball账号绑定一个namespace级别的role，使用rolebinding

  1. apiVersion: rbac.authorization.k8s.io/v1
  2. kind: RoleBinding
  3. metadata:
  4.   name: mrvolleyball
  5. roleRef:
  6.   apiGroup: rbac.authorization.k8s.io
  7.   kind: Role
  8.   name: po_r
  9. subjects:
  10. - apiGroup: rbac.authorization.k8s.io
  11.   kind: User
  12.   name: mrvolleyball

再看mrvolleyball的账户，已经拥有了对default namespace的get pod权限

  1. root@k8s-master:~# kubectl get pod
  2. NAME                                      READY     STATUS    RESTARTS   AGE
  3. busybox                                   1/1       Running   89         3d
  4. nginx-deployment-77d7f55978-lvfkf         1/1       Running   0          21h

不过他既没有service的访问权限，更没有别的namespace的访问权限

  1. root@k8s-master:~# kubectl get svc
  2. Error from server (Forbidden): services is forbidden: User "mrvolleyball" cannot list services in the namespace "default"
  3. root@k8s-master:~# kubectl get pod -n kube-system
  4. Error from server (Forbidden): pods is forbidden: User "mrvolleyball" cannot list pods in the namespace "kube-system"

（2）clusterrole绑定

绑定clusterrole，让mrvollerball能够读取所有namespace的pod

  1. apiVersion: rbac.authorization.k8s.io/v1
  2. kind: ClusterRoleBinding
  3. metadata:
  4.   name: mrvolleyball
  5. roleRef:
  6.   apiGroup: rbac.authorization.k8s.io
  7.   kind: ClusterRole
  8.   name: cluster_po_r
  9. subjects:
  10. - apiGroup: rbac.authorization.k8s.io
  11.   kind: User
  12.   name: mrvolleyball

这时候mrvolleyball也可以读取其他namespace的pod

  1. root@k8s-master:~# kubectl get pod -n kube-system
  2. NAME                                        READY     STATUS             RESTARTS   AGE
  3. calico-kube-controllers-55c94797d7-vr9k6    1/1       Running            0          15d
  4. calico-node-86xgg                           1/1       Running            0          7d
  5. calico-node-drsl2                           1/1       Running            0          7d
  6. calico-node-l67h4                           1/1       Running            0          7d
  7. coredns-794b5f8589-vgclz                    1/1       Running            4809       15d
  8. coredns-794b5f8589-xzpxd                    1/1       Running            0          130d
  9. default-http-backend-6cb5c56987-tcx92       1/1       Running            0          139d
  10. kubernetes-dashboard-77c46fc984-djdd4       1/1       Running            0          139d
  11. nginx-ingress-controller-6d95468cc8-ft6nn   1/1       Running            0          140d

这里需要注意几种资源的绑定：

rolebinding --> role
clusterrolebinding --> clusterrole
rolebinding --> clusterrole

● 第一种是namespace级别的绑定，只对role所在的namespace生效
● 第二种是cluster级别的绑定，对于集群所有的namespace都生效
● 第三种是namespace级别的绑定，只对role所在的namespace生效

有同学要问，第一种和第三种有什么区别：

  1. apiVersion: rbac.authorization.k8s.io/v1
  2. kind: RoleBinding
  3. metadata:
  4.   name: mrvolleyball
  5.   namespace: default
  6. roleRef:
  7.   apiGroup: rbac.authorization.k8s.io
  8.   kind: ClusterRole
  9.   name: cluster_po_r
  10. subjects:
  11. - apiGroup: rbac.authorization.k8s.io
  12.   kind: User
  13.   name: mrvolleyball

区别主要是为了方便管理：
● 比如有10个namespace，分配给了10个不同的团队，那每个团队都需要使用自己的userAccount操作自己所在的namespace
● 最简单的做法，就是在10个不同namespace创建10个role，然后通过rolebinding将role绑定userAccount。如果需要添加userAccount，那这个管理成本就会升高
● 这时候创建一个clusterrole，由于他们对各自的namespace的行为都是一样的，那就只需要通过rolebinding将clusterrole绑定在userAccount，只需要创建1次clusterrole

五、serviceAccount角色绑定

serviceAccount要提供给pod内访问，或者是外部服务的访问。为了验证serviceAccount，我们来模拟pod去访问api

首先先创建一个serviceAccount

  1. root@k8s-master:/etc/kubernetes/ssl# kubectl create serviceaccount helloworld
  2. serviceaccount "helloworld" created
  3. root@k8s-master:/etc/kubernetes/ssl# kubectl get sa helloworld -o yaml
  4. apiVersion: v1
  5. kind: ServiceAccount
  6. metadata:
  7.   creationTimestamp: 2019-03-12T06:36:00Z
  8.   name: helloworld
  9.   namespace: default
  10.   resourceVersion: "24381027"
  11.   selfLink: /api/v1/namespaces/default/serviceaccounts/helloworld
  12.   uid: 1987b4e6-4491-11e9-96bc-525400c34cf1
  13. secrets:
  14. - name: helloworld-token-sr9xb

serviceAccount获取默认生成一个token，该token是用于pod访问kube-api的身份验证（详情访问上一篇文章）

  1. root@k8s-master:/etc/kubernetes/ssl# kubectl get secret helloworld-token-sr9xb -o yaml
  2. apiVersion: v1
  3. data:
  4. ...
  5.   token: ZXlKaGJHY2lPaUpTVXpJMU5pSXNJbXRwWkNJNklpSjkuZXlKcGMzTWlPaUpyZFdKbGNtNWxkR1Z6TDNObGNuWnBZMlZoWTJOdmRXNTBJaXdpYTNWaVpYSnVaWFJsY3k1cGJ5OXpaWEoyYVdObFlXTmpiM1Z1ZEM5dVlXMWxjM0JoWTJVaU9pSmtaV1poZFd4MElpd2lhM1ZpWlhKdVpYUmxjeTVwYnk5elpYSjJhV05sWVdOamIzVnVkQzl6WldOeVpYUXVibUZ0WlNJNkltaGxiR3h2ZDI5eWJHUXRkRzlyWlc0dGMzSTVlR0lpTENKcmRXSmxjbTVsZEdWekxtbHZMM05sY25acFkyVmhZMk52ZFc1MEwzTmxjblpwWTJVdFlXTmpiM1Z1ZEM1dVlXMWxJam9pYUdWc2JHOTNiM0pzWkNJc0ltdDFZbVZ5Ym1WMFpYTXVhVzh2YzJWeWRtbGpaV0ZqWTI5MWJuUXZjMlZ5ZG1salpTMWhZMk52ZFc1MExuVnBaQ0k2SWpFNU9EZGlOR1UyTFRRME9URXRNVEZsT1MwNU5tSmpMVFV5TlRRd01HTXpOR05tTVNJc0luTjFZaUk2SW5ONWMzUmxiVHB6WlhKMmFXTmxZV05qYjNWdWREcGtaV1poZFd4ME9taGxiR3h2ZDI5eWJHUWlmUS5zTTQ3dnBMV25nVmZ1Q2c3RGRfNWlVSGFCa0loeHNvNXY1ZHotRzh3X3ctZUNaS05pZlRyUE9xd3R3QjR4MnZnS3dPaExXX2c0UWxtRDNXS3QyejhlNHVJeFV0cHZkc0lRYkdrYjVrUUdsV1p4cnZwTUZHbTF0eVRsU1lVc3gxa25GdnViWTV0bWU5Y2JkNExOc2RQQ1IxTXBBYnBkYjlqZFh6OWRxMVAyb1Z1LVVuYmVBTkFMcE5tSGJHZjFSdVRPUEJBcUNPNlI3Zm0zUUxpZFZOSDBjRUkwX1Joa0NKR2xPUi1rUlZ5bE5GYXJOVWhvQnJGSEJpTWJyOHd6UHpRNk42Z0hpblctWUc1ekFCY2JNaUR1QUZrRDBCXzBNbDlJandHaDgtbHlrSUZBTU1sbTktUS1hTjJTUjkwSnJyelRYcUtUV3NJU0ZQWHhCTUItX3BXTTlEMEhiZTU4TURCQ1VlSlp0SUcyNno4alBiU0Y1aHRuTy1YSFJRWm1CUzJoaXFLelE2aG9TMkxEa045WUdwcFRETkJUY0dySjg2U0ZQaDlkRWtaYWw0QU9XLWlfTHdEYnY0V2luQjBDOG1Pc3c1WkhDdEVxTVNUTE90aXFyOWZ3bEYzb2lldERqV3FSSXhKeG5rY1NRYTBOTHR4cENiQjFvOGRDTjlqaE1WLVRZMDdidUVNNUpJUGhzeERBMVpqTjNJenVpc3VTVWZMRjd5NkgwZ1JxaGdITzdyMVZvdU5ubGFybjNhSmxMYmF3NUk3RnIwM1ZrQ0pqSmotX0FFRmpSWGlNVmRtenM0el9nWVRfUGR0TXR4YnFfd1p5ZXJHWXpuUk9NQ3p0b2gtRlRCWktOT2dfZjBmTEN3c29rd2NJaEtWWFh2YXMtcjN0YXFBcXZEbWtOOA==
  6. kind: Secret
  7. metadata:
  8.   annotations:
  9.     kubernetes.io/service-account.name: helloworld
  10.     kubernetes.io/service-account.uid: 1987b4e6-4491-11e9-96bc-525400c34cf1
  11.   creationTimestamp: 2019-03-12T06:36:00Z
  12.   name: helloworld-token-sr9xb
  13.   namespace: default
  14.   resourceVersion: "24381026"
  15.   selfLink: /api/v1/namespaces/default/secrets/helloworld-token-sr9xb
  16.   uid: 198c824f-4491-11e9-96bc-525400c34cf1
  17. type: kubernetes.io/service-account-token

拿到该token，将其转码之后作为连接kube-api的身份验证

  1. root@k8s-master:/etc/kubernetes/ssl# token=`kubectl get secret helloworld-token-sr9xb -o yaml | grep "token:" | awk '{print $2}' | base64 -d`
  2. root@k8s-master:/etc/kubernetes/ssl# kubectl config set-credentials helloworld --token=$token
  3. User "helloworld" set.

配置rolebinding，po_r这个role只能对default namespace的pod有读权限

  1. apiVersion: rbac.authorization.k8s.io/v1
  2. kind: RoleBinding
  3. metadata:
  4.   name: helloworld-role-binding
  5.   namespace: default
  6. roleRef:
  7.   apiGroup: rbac.authorization.k8s.io
  8.   kind: Role
  9.   name: po_r
  10. subjects:
  11. - kind: ServiceAccount
  12.   name: helloworld
  13.   namespace: default

尝试访问一下：

  1. root@k8s-master:~# kubectl config use-context context@helloworld
  2. Switched to context "context@helloworld".
  3. root@k8s-master:~# kubectl get pod
  4. NAME                                      READY     STATUS    RESTARTS   AGE
  5. busybox                                   1/1       Running   187        7d

该serviceAccount也只有default namespace的访问权限

  1. root@k8s-master:~# kubectl get pod -n kube-system
  2. Error from server (Forbidden): pods is forbidden: User "system:serviceaccount:default:helloworld" cannot list pods in the namespace "kube-system"

六、小结

● 本文介绍了k8s基于权限的访问，详细k8s当中role、clusterrole与rolebinding、clusterrolebinding
● 并且模拟了不同类型的账户访问kube-api时不同的认证方式


至此，本文结束
在下才疏学浅，有撒汤漏水的，请各位不吝赐教...

原文链接：http://www.cnblogs.com/MrVolleyball/p/10709142.html

 友情链接：直通硅谷 　点职佳 　北美留学生论坛

Kubernetes热门文章

  • 【Azure K8S | AKS】在AKS集群中创建 PVC(PersistentVolumeClaim)和 PV(PersistentVolume) 示例
  • 无法访问k8s.gcr.io下载镜像问题解决办法
  • Kubernetes(k8s)访问控制：身份认证
  • Prometheus服务发现之kubernetes_sd_config
  • Arthas排查Kubernetes中应用频繁挂掉重启异常
  • Kubernetes客户端认证——基于CA证书的双向认证方式
  • k8s中kubeconfig的配置以及使用详解
  • Centos7 安装部署 Kubernetes(k8s) 高可用集群
  • Kubernetes 证书详解
  • 案例分享-full gc导致k8s pod重启

    • Kubernetes推荐文章

  • 修改kubeadm证书过期时间及更新k8s集群证书
  • 探究kubernetes 探针参数periodSeconds和timeoutSeconds
  • 从 Helm 到 Operator：Kubernetes应用管理的进化
  • 深入理解Prometheus: Kubernetes环境中的监控实践
  • k8s集群搭建及对一些组件的简单理解（二）
  • K8s高可用集群二进制部署-V1.20
  • Kubernetes容器生命周期 —— 钩子函数详解（postStart、preStop）
  • Kubernetes 审计（Auditing）
  • Thanos解码：打造企业级云原生监控解决方案
  • k8s使用rbd作为存储

    • 本站QQ群：前端 618073944 | Java 606181507 | Python 626812652 | C/C++ 612253063 | 微信 634508462 | 苹果 692586424 | C#/.net 182808419 | PHP 305140648 | 运维 608723728

    W3xue 的所有内容仅供测试，对任何法律问题及风险不承担任何责任。通过使用本站内容随之而来的风险与本站无关。
    关于我们  |  意见建议  |  捐助我们  |  报错有奖  |  广告合作、友情链接（目前9元/月）请联系QQ：27243702 沸活量
    皖ICP备17017327号-2　皖公网安备34020702000426号