使用 RBAC 鉴权实战
官方文档
创建名称
deployment-clusterrole的 ClusterRole，该⻆⾊具备创建 Deployment、Statefulset、Daemonset 的权限，在命名空间rbac-test中创建名称为cicd-token的 ServiceAccount，绑定ClusterRole 到 ServiceAccount，且限定命名空间为
rbac-test。
本人k8s集群信息：
root@k8s-master:~# kubectl get node -o wide
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
k8s-master Ready control-plane,master 692d v1.22.0 192.168.123.150 <none> Ubuntu 18.04.5 LTS 4.15.0-213-generic docker://20.10.0
k8s-node1 Ready <none> 692d v1.22.0 192.168.123.151 <none> Ubuntu 18.04.5 LTS 4.15.0-213-generic docker://20.10.0
k8s-node2 Ready <none> 692d v1.22.0 192.168.123.152 <none> Ubuntu 18.04.5 LTS 4.15.0-213-generic docker://20.10.0
🎥创建命名空间dev
root@k8s-master:~# kubectl get ns rbac-test --show-labels
NAME STATUS AGE LABELS
rbac-test Active 17s kubernetes.io/metadata.name=rbac-test
🎞️创建 ClusterRole
📽️ ClusterRole
ClusterRole 中包含一组代表相关权限的规则。
ClusterRole 是一个集群作用域的资源。这两种资源的名字不同（Role 和 ClusterRole） 是因为 Kubernetes 对象要么是名字空间作用域的，要么是集群作用域的，不可两者兼具。
ClusterRole 有若干用法。你可以用它来：
- 定义对某名字空间域对象的访问权限，并将在个别名字空间内被授予访问权限；
- 为名字空间作用域的对象设置访问权限，并被授予跨所有名字空间的访问权限；
- 为集群作用域的资源定义访问权限。
如果你希望在名字空间内定义角色，应该使用 Role； 如果你希望定义集群范围的角色，应该使用 ClusterRole。
clusterrole.yml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
# "namespace" 被忽略，因为 ClusterRoles 不受名字空间限制
name: deployment-clusterrole
rules:
- apiGroups: [""]
resources: ["deployments","statefulsets","daemonsets"]
verbs: ["create"]
查看clusterrole信息：
root@k8s-master:~# kubectl apply -f clusterrole.yml
clusterrole.rbac.authorization.k8s.io/deployment-clusterrole created
root@k8s-master:~# kubectl describe clusterrole deployment-clusterrole
Name: deployment-clusterrole
Labels: <none>
Annotations: <none>
PolicyRule:
Resources Non-Resource URLs Resource Names Verbs
--------- ----------------- -------------- -----
daemonsets [] [] [create]
deployments [] [] [create]
statefulsets [] [] [create]
🎬创建ServiceAccount
Kubernetes中的Service Account（服务账户）是一种资源，用于为Pod提供身份标识和访问控制。Service Accounts允许在Kubernetes集群中的工作负载（如Pod）和其他资源之间建立信任关系，以便这些工作负载能够与API服务器进行安全通信并访问集群中的其他资源。
以下是Service Accounts的关键特点和作用：
- 身份标识： 每个Pod都可以关联一个Service Account。当Pod内的应用程序需要与Kubernetes API服务器或其他受RBAC控制的资源进行交互时，它可以使用其Service Account来获得身份标识。这有助于确保在群集中运行的工作负载具有可控的身份。
- 访问控制： Service Accounts与Kubernetes的RBAC（基于角色的访问控制）一起使用，以控制哪些操作和资源可以由Pod执行。通过将Service Account与特定的角色（Role）或角色绑定（RoleBinding）关联，可以定义哪些权限分配给Pod。
- 凭证： 每个Service Account与一个Secret对象相关联，该Secret包含一个令牌（token）和其他凭证信息，用于身份验证。Pod中的应用程序可以使用这些凭证与Kubernetes API服务器进行通信，以获取必要的信息或执行操作。
- 默认Service Account： 每个命名空间（Namespace）都有一个名为"default"的默认Service Account。如果在创建Pod时未显式指定Service Account，则Pod将自动使用该默认Service Account。默认Service Account通常具有较低的权限，因此通常不推荐在生产环境中使用。
Service Accounts非常有用，因为它们允许您以安全和可控的方式为不同的工作负载提供身份标识和权限，同时确保资源访问受到严格的访问控制。当您需要在Kubernetes集群中实现细粒度的权限控制和身份管理时，Service Accounts是非常重要的工具。
root@k8s-master:~# kubectl create serviceaccount cicd-token -n rbac-test
serviceaccount/cicd-token created
root@k8s-master:~# kubectl describe serviceaccount cicd-token -n rbac-test
Name: cicd-token
Namespace: rbac-test
Labels: <none>
Annotations: <none>
Image pull secrets: <none>
Mountable secrets: cicd-token-token-t74pm
Tokens: cicd-token-token-t74pm
Events: <none>
📺绑定角色
角色绑定（Role Binding）是将角色中定义的权限赋予一个或者一组用户。 它包含若干主体（Subject）（用户、组或服务账户）的列表和对这些主体所获得的角色的引用。 RoleBinding 在指定的名字空间中执行授权，而 ClusterRoleBinding 在集群范围执行授权。
一个 RoleBinding 可以引用同一的名字空间中的任何 Role。 或者，一个 RoleBinding 可以引用某 ClusterRole 并将该 ClusterRole 绑定到 RoleBinding 所在的名字空间。 如果你希望将某 ClusterRole 绑定到集群中所有名字空间，你要使用 ClusterRoleBinding。
kubectl -n rbac-test create rolebinding cicd-clusterrole --clusterrole=deployment-clusterrole --serviceaccount=rbac-test:cicd-token
root@k8s-master:~# kubectl describe rolebinding -n rbac-test
Name: cicd-clusterrole
Labels: <none>
Annotations: <none>
Role:
Kind: ClusterRole
Name: deployment-clusterrole
Subjects:
Kind Name Namespace
---- ---- ---------
ServiceAccount cicd-token rbac-test
![[ZenTao]禅道邮件通知设置](https://img-blog.csdnimg.cn/47869da27aea46bfb000c65ab6b9fab3.png)
