在这篇文章中，我将解释如何在kubernetes中配置RBAC。我们将使用kubectl和yaml定义来配置RBAC。
什么是RBAC
在kubernetes中，有几种授权机制，例如RBAC，ABAC。
使用RBAC，我们可以添加限制来访问kubernetes资源。例如，我们可以为ServiceAccount授予列出特定名称空间的Pod的权限，并阻止它删除任何资源。我们也可以针对特定的名称空间或整个集群进行此操作。
RBAC的重点
RBAC中有3个重要概念。
主题：用户，组或服务帐户。
资源：我们将在其上运行的Kubernetes API对象。
动词：我们要使用资源进行的操作。
角色和集群角色
Role和ClusterRole包含一组访问和修改kubernetes资源的规则。它们之间的区别是，角色在特定的名称空间中起作用，而ClusterRole在整个群集范围内，这从名称上可以明显看出。
如果需要在名称空间内定义权限，请使用“角色”，如果需要在整个集群范围内，请使用ClusterRole。
通过kubectl创建角色很简单，就像我在下面显示的那样：
|
1 |
kubectl create role my-custom-role --verb=list --resource=pods --namespace k8boss |
我们也可以指定多个动作和资源：
|
1 |
kubectl create role my-custom-role --verb=list --verb=get --resource=pods --resource=services --namespace k8boss |
通过yaml文件也可以：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: my-custom-role namespace: k8boss rules: - apiGroups: - "*" resources: - services - pods verbs: - get - list |
|
1 |
kubectl apply -f role.yaml |
如果我们未在role.yaml中指定名称空间，它将被视为默认名称空间。
ClusterRole没有太大区别：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: my-custom-cluster-role rules: - apiGroups: - "*" resources: - services - pods verbs: - get - list |
仅在没有名称空间的情况下，角色定义几乎与之相同。
服务帐号
Pod内部的进程使用服务帐户与Kubernetes API进行交互。 如果您编写自定义应用程序以使用kubernetes，则可能需要创建一个为其分配了一些特殊角色的自定义ServiceAccount。 例如，当您部署kubernetes仪表板时，您可以为kubernetes-dashboard服务帐户分配其他角色，或者使用集群管理员角色绑定创建自定义ServiceAccount。
使用kubectl创建ServiceAccount非常简单：
|
1 |
kubectl create serviceaccount custom-sa -n k8boss |
yaml:
|
1 2 3 4 5 |
apiVersion: v1 kind: ServiceAccount metadata: name: custom-sa namespace: k8boss |
创建ServiceAccount后，请显示其Yaml内容：
|
1 2 3 4 5 6 7 8 9 10 11 12 |
kubectl get sa custom-sa -n k8boss -o yam apiVersion: v1 kind: ServiceAccount metadata: creationTimestamp: "2020-04-13T22:11:49Z" name: custom-sa namespace: k8boss resourceVersion: "1653" selfLink: /api/v1/namespaces/test/serviceaccounts/test-sa uid: 8fb1df02-6bab-43f1-afe8-3ede5f4a1710 secrets: - name: custom-sa-token-jcq7h |
如您所见，还有一个额外的字段“ secrets”，我们在创建ServiceAccount时未指定。 kubernetes创建了一个与我们的ServiceAccount相关的秘密。
让我们来看看我们的secret：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
kubectl get secret custom-sa-token-jcq7h -n k8boss -o yaml apiVersion: v1 data: ca.crt: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUN5RENDQWJDZ0F3SUJBZ0lCQURBTkJna3Foa2lHOXcwQkFRc0ZBREFWTVJNd0VRWURWUVFERXdwcmRXSmwKY201bGRHVnpNQjRYRFRJd01EUXhNekl5TURNMU1sb1hEVE13TURReE1USXlNRE0xTWxvd0ZURVRNQkVHQTFVRQpBeE1LYTNWaVpYSnVaWFJsY3pDQ0FTSXdEUVlKS29aSWh2Y05BUUVCQlFBRGdnRVBBRENDQVFvQ2dnRUJBTTBVCkgvMnFZSGpicVI5bXlka3ZUc0lsZnFRVlAvdzVvNXZhaUF5UkVVbkNXdWt0bFBJK3FSTnRvZmVTS3pSd003bnAKR1haek5vR3JlWEtNbEVhaktrMTRBdjRwN2F4OGlRUkJ5OGZWejU5TXd5NmVoRXR6NFpDN1dvSTBTNndxSVRENgo4cktLdmtCVmVRaG9RenFXMjRZclpDZ3VTTmkxNm90bUZ6SWh6dENmUkJWVUZLRjF5SEREdXQxUk9LYVl6U3h5Ckw5RFRXVlUxY3Q2L0t3N0NabGdkSDh0STJqc3NSWE5MdURHVmJkQ1RMelg5eTk0Y25nY0tTeVNiZ2F3dXQ2ZnoKWkZmVld2UzJBait1WjR5cUV1citNZ3dZdW9YQjlLSHhxcFp5YXVQaEJiSVR4T2pXM0RMWkZjTGoxY0xBNUVKdApZWmZ0eVZkVjNCSVFGNm5ZTi9jQ0F3RUFBYU1qTUNFd0RnWURWUjBQQVFIL0JBUURBZ0trTUE4R0ExVWRFd0VCCi93UUZNQU1CQWY4d0RRWUpLb1pJaHZjTkFRRUxCUUFEZ2dFQkFHaG5VUlVSTFBMVk9FS1I2c0h0VXZhWkVFSisKdGdPT3JTZnpZTVBqWXZTdURJYjgvR0o1ZWswL21uMzFwdlZVRktRYis5aHdwOFViYWZOeXR2dEhaZ0pjZGNnbQpSQlVob3Yzc043WEVvY1hiK3VpSHAwNmt3TlVnOTRETXNVRmRZcExwUGYydm9HcjBycXFDeVNHUFFCYkFCd0hCCktpLzZxaUFBM0VVVTAvZUJLOVVDdmVFNVhxcXl1LytJbG1hODFyQTZMQVYyYkE0Z2I1L0MvRmg0c0VJaUphd2oKQnI1TkEvVWhmWUhyaXNhVGRoLzlxWE5memMwcFUzejFqbGdxZnNGZURxWjNzSisrTWNJQk1PWWFaTVA1U1Z3UwpJbC9aQ056bHArTjdTTERqZTRDOWg0SXRXMWRGdGNQdnNNcXBtTmtQelVZN0pNcTQxNGlTUkUzeXYxbz0KLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo= namespace: dGVzdA== token: ZXlKaGJHY2lPaUpTVXpJMU5pSXNJbXRwWkNJNklsWkdSMGR2TTBJdGFXc3pOMFZuYWpKSWIwMXpTR2hrTmtvemJsSjZOVmM1TTNacWVsTkJkazk2VWpRaWZRLmV5SnBjM01pT2lKcmRXSmxjbTVsZEdWekwzTmxjblpwWTJWaFkyTnZkVzUwSWl3aWEzVmlaWEp1WlhSbGN5NXBieTl6WlhKMmFXTmxZV05qYjNWdWRDOXVZVzFsYzNCaFkyVWlPaUowWlhOMElpd2lhM1ZpWlhKdVpYUmxjeTVwYnk5elpYSjJhV05sWVdOamIzVnVkQzl6WldOeVpYUXVibUZ0WlNJNkluUmxjM1F0YzJFdGRHOXJaVzR0YW1OeE4yZ2lMQ0pyZFdKbGNtNWxkR1Z6TG1sdkwzTmxjblpwWTJWaFkyTnZkVzUwTDNObGNuWnBZMlV0WVdOamIzVnVkQzV1WVcxbElqb2lkR1Z6ZEMxellTSXNJbXQxWW1WeWJtVjBaWE11YVc4dmMyVnlkbWxqWldGalkyOTFiblF2YzJWeWRtbGpaUzFoWTJOdmRXNTBMblZwWkNJNklqaG1ZakZrWmpBeUxUWmlZV0l0TkRObU1TMWhabVU0TFRObFpHVTFaalJoTVRjeE1DSXNJbk4xWWlJNkluTjVjM1JsYlRwelpYSjJhV05sWVdOamIzVnVkRHAwWlhOME9uUmxjM1F0YzJFaWZRLlJxeXFaQUx2M19qeUNhZnMtbF9pa0ctQXA4RFNPZjRoT2psaXRkODYxRzBDcXpmY0VYLW1GbkxlbFNHSDg1Z1MyeHR2SmxBci0zcG9sZjdnMEJCNlRKRHl0Ny1rN2V2a2dyTzVGbG85b2R3NVVqeWpLdFd6czdLbjBsci1DUDU4OXV1ekFPRTlIdHpnZTMwYlYxQWVmdEtZUmNsdUlxb1hVRk1ZWko5a3hXZk1hZkh4UlVOX2M1TkppRVNibktCeXhyelFqNV9xUVNoMFFKbkdxVjdCTWJJcksyZW02ME5hLWFJNWpCMDNxYnJsM2ZBUk91ZEphTW5BWEwwZDQxSkZJU0o2TW5qSlpKZlFXUWpTOEFNWlNMVXF4TlpXZlcwc2N0OGdhX3dLT0c4cUVMd2YxLWVJdFlZa1pRckRONVk5SEllc2U5QjZvRjFWZUtlcVdKdlY2QQ== kind: Secret metadata: annotations: kubernetes.io/service-account.name: custom-sa kubernetes.io/service-account.uid: 8fb1df02-6bab-43f1-afe8-3ede5f4a1710 creationTimestamp: "2020-04-13T22:11:49Z" name: custom-sa-token-jcq7h namespace: k8boss resourceVersion: "1652" selfLink: /api/v1/namespaces/k8boss/secrets/custom-sa-token-jcq7h uid: 45956fb0-2449-48c8-a0d3-d1a088a1f4ea type: kubernetes.io/service-account-token |
我们可以在此处看到令牌键值。 我们可以使用这些秘密来访问kubernetes-dashboard。 但是我们需要对其进行解码，因为kubernetes以base64编码格式存储秘密值。 简单地说，我们可以描述秘密并采用令牌值：
|
1 |
kubectl describe secret custom-sa -n k8boss |
角色绑定和集群角色绑定
如名称所示，角色绑定使我们可以将角色绑定到主题（用户或一组用户或服务帐户）。 同样，唯一的区别是用法上，我们使用RoleBinding绑定角色，而使用ClusterRoleBinding绑定ClusterRoles。 但除此之外，我们可以使用RoleBinding将ClusterRole绑定到名称空间中的Role。
在创建角色绑定之前，我们可以询问我们的服务帐户的功能：
|
1 |
kubectl auth can-i list pods --as=system:serviceaccount:k8boss:custom-sa -n k8boss |
您将看到“ no”作为该命令的输出。
让我们创建一个与kubectl绑定的角色：
|
1 |
kubectl create rolebinding my-custom-role-binding --role=my-custom-role --serviceaccount=k8boss:custom-sa --namespace k8boss |
yaml格式：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
apiVersion: v1 items: - apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: my-custom-role-binding namespace: k8boss roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: my-custom-role subjects: - kind: ServiceAccount name: custom-sa namespace: k8boss |
ClusterRoleBinding 没有太多不同：
|
1 |
kubectl create clusterrolebinding my-custom-clusterrole-binding --clusterrole=my-custom-cluster-role --serviceaccount=k8boss:custom-sa |
再试试：
|
1 |
kubectl auth can-i list pods --as=system:serviceaccount:k8boss:custom-sa -n k8boss |
回复是yes:
聚集的ClusterRoles
我们要提到的最后一件事是Aggregated ClusterRoles。 有时我们可能想将多个群集角色组合为一个。
为此，我们可以使用ClusterRole的aggregationRule字段。 我们可以使用标签选择器选择角色。 例如，假设我们有两个ClusterRole，一个用于列出pod，一个用于列出服务。 因此，我们需要另一个ClusterRole来列出Pod和服务。 现在，我们可以使用aggregationRule组合两个ClusterRoles。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 |
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: my-custom-cluster-role labels: rbac.example.com/aggregate-to-pod-list: "true" rules: - apiGroups: - "*" resources: - pods verbs: - list apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: my-custom-cluster-role-2 labels: rbac.example.com/aggregate-to-service-list: "true" rules: - apiGroups: - "*" resources: - service verbs: - list |
|
1 2 3 4 5 6 7 8 9 10 |
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: custom-aggregated-role aggregationRule: clusterRoleSelectors: - matchLabels: rbac.example.com/aggregate-to-pod-list: "true" rbac.example.com/aggregate-to-service-list: "true" rules: [] # The control plane automatically fills in the rules |
原文：https://medium.com/trendyol-tech/configure-rbac-in-kubernetes-like-a-boss-665e2a8665dd