小编给大家分享一下kubernetes中如何实现RBAC 角色访问控制，希望大家阅读完这篇文章之后都有所收获，下面让我们一起去探讨吧！
一：RBAC体系结构
二：RBAC角色绑定流程
三：说明
1.RBAC的优势
a.对集群中的资源和非资源权限均有完整覆盖
b.RBAC由API对象完成，可以用Kubectl或API进行操作
c.可以在允许时进行调整，无须重新启动API Server
2.Role
一个角色就是一组权限的集合，在一个命名空间中，可以使用Role定义一个角色，如果是集群级别的可以使用ClusterRole.
3.ClusterRole
除了和Role一样具有命名空间内资源的管理能力，还可以用于特殊元素的授权。如：
a.集群范围的资源，node等
b.非资源型的路径，如“/healthz”
c.涵盖全部命名空间的资源
4.RoleBinding和ClusterRoleBinding
两者用于把一个角色绑定到一个目标上，如User,Group或Service Account. RoleBinding可以引用Role和ClusterRole, ClusterRoleBinding仅可以引用ClusterRole.
5.对资源的引用方式
a.使用“/”来分隔资源和下级资源 如：resources: ["pods", "pods/log"]
b.通过名字进行引用 如：resourceNames: ["my-configmap"]
6.常用角色示例
a.运行读取核心API组中的POD资源
点击(此处)折叠或打开
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "list", "watch"]
b.运行读写“extensions”和"apps"两个API组中的deployment资源
点击(此处)折叠或打开
rules:
- apiGroups: ["extensions", "apps"]
resources: ["deployments"]
verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
7.常用角色绑定示例
a.绑定Kube-system命名空间中默认的service-account
点击(此处)折叠或打开
subjects:
- kind: ServiceAccount
name: default
namespace: kube-system
b.qa命名空间中的所有service account
点击(此处)折叠或打开
subjects:
- kind: Group
name: system:serviceaccounts:qa
apiGroup: rbac.authorization.k8s.io
c.所有认证用户
点击(此处)折叠或打开
subjects:
- kind: Group
name: system:authenticated
apiGroup: rbac.authorization.k8s.io
8.对Service Account的授权管理
kube-system之外的service account 是没有任何权限的，这就需要用户为service account赋予所需的权限。如：
点击(此处)折叠或打开
kubectl create rolebinding default-view \
--clusterrole=view \
--serviceaccount=my-namespace:default \
--namespace=my-namespace
看完了这篇文章，相信你对“kubernetes中如何实现RBAC 角色访问控制”有了一定的了解，如果想了解更多相关知识，欢迎关注编程网行业资讯频道，感谢各位的阅读！
