万字长文 | 使用 RBAC 限制对 Kubernetes 资源的访问
新钛云服已累计为您分享652篇技术干货
通过本文,我们将学习如何从头开始重新创建 Kubernetes RBAC 授权模型,并了解Roles、ClusterRoles、ServiceAccounts、RoleBindings 和 ClusterRoleBindings 之间的关系。
随着集群中应用程序和资源数量的增加,我们可能需要查看并限制他们相关的权限,从而避免一些危险操作。这些危险操作往往会严重影响生产环境,有时候,甚至会引起长时间的停机,比如过大的权限导致正常运行的服务被删除。
正常情况下,我们可能希望限制生产系统仅仅允许少部分人管理以及访问。
或者,我们可能希望向部署在集群中的维护人员授予一组有限的权限。
我们可以通过Kubernetes 中的基于角色的访问控制 (RBAC) 来实现上述的需求。
Kubernetes API
在讨论RBAC之前,让我们看看授权模型在图中的位置。
假设我们希望将以下 Pod 部署到 Kubernetes 集群:
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
containers:
- name: sise
image: learnk8s/app:1.0.0
ports:
- containerPort: 8080
我们可以使用以下命令将 Pod 部署到集群:
$ kubectl apply -f pod.yaml
当我们输入时kubectl apply
,会触发以下的操作。
kubectl
会:
1、从KUBECONFIG读取配置
2、从 API 中发现 API 和对象
3、验证资源客户端(是否有明显的错误?)
4、将带有有效负载的请求发送到kube-apiserver
当kube-apiserver
收到请求时,它不会立即将其存储在 etcd 中。
首先,它必须验证请求者是否合法。
换句话说,它必须对请求进行身份验证。(https://kubernetes.io/docs/reference/access-authn-authz/authentication/)
一旦通过身份验证,请求者是否有权创建资源?
身份和权限不是一回事。
仅仅因为我们可以访问集群并不意味着我们可以创建或读取所有资源。
授权通常使用基于角色的访问控制 (RBAC)(https://kubernetes.io/docs/reference/access-authn-authz/rbac/)来完成。
借助基于角色的访问控制 (RBAC),我们可以分配精细的权限并限制用户或应用程序可以执行的操作。
在更实际的情况下,API 服务器按顺序执行以下操作:
1、收到请求后,对用户进行身份验证。
将用户和权限与 RBAC 角色解耦
| User | Permission | Resource |
| ----- | ---------- | -------- |
| Bob | read+write | app1 |
| Alice | read | app2 |
| Mo | read | app2 |
| User | Permission | Resource |
| --------- | ---------- | -------- |
| Bob | read+write | app1 |
| Alice | read | app2 |
| Mo | read | app2 |
| Alice | read | app1 |
| Mo | read | app1 |
在典型的授权系统中我们有用户访问资源
我们可以直接向用户分配权限,并定义他们可以使用的资源
这些权限直接映射资源。注意它们是如何作用于用户的
如果我们决定让第二个用户具有相同的权限,则必须关联相同的权限
| Role | Permission | Resource |
| -------- | ---------- | -------- |
| admin1 | read+write | app1 |
| reviewer | read | app2 |
| User | Roles |
| ----- | -------- |
| Bob | admin1 |
| Alice | reviewer |
| Mo | reviewer |
| User | Roles |
| ----- | ------------------- |
| Bob | admin1 |
| Alice | reviewer |
| M
使用 RBAC 时,我们拥有用户、资源和角色
权限不会直接分配给用户。相反,他们被包括在这个角色中
用户通过绑定关联到角色
由于角色是通用的,当新用户需要访问相同资源时,您可以使用现有角色并将其新绑定关联
Kubernetes 中的 RBAC
rbac.authorization.k8s.io
API 组 来驱动鉴权决定,允许你通过 Kubernetes API 动态配置策略。--authorization-mode
参数设置为一个逗号分隔的列表并确保其中包含 RBAC
。kube-apiserver --authorization-mode=Example,RBAC --<其他选项> --<其他选项>
apiVersion: v1
kind: ServiceAccount
metadata:
name: serviceaccount:app1
namespace: demo-namespace
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: role:viewer
namespace: demo-namespace
rules: # Authorization rules for this role
- apiGroups: # 1st API group
- '' # An empty string designates the core API group.
resources:
- services
- pods
verbs:
- get
- list
- apiGroups: # 2nd API group
- apiextensions.k8s.io
resources:
- customresourcedefinitions
verbs:
- list
- apiGroups: # 3rd API group
- cilium.io
resources:
- ciliumnetworkpolicies
- ciliumnetworkpolicies/status
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: rolebinding:app1-viewer
namespace: demo-namespace
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: role:viewer
subjects:
- kind: ServiceAccount
name: serviceaccount:app1
namespace: demo-namespace
# 1. Kubernetes builtin resources
/api/v1/namespaces/{namespace}/services
/api/v1/namespaces/{namespace}/pods
# 2. A specific API extention provided by cilium.io
/apis/cilium.io/v2/namespaces/{namespace}/ciliumnetworkpolicies
/apis/cilium.io/v2/namespaces/{namespace}/ciliumnetworkpolicies/status
分配身份:用户,组,robot账户
在这种情况下,Kubernetes 从证书的“subject”中的通用名称字段中分配用户名(例如,“/CN=bob”)。
type User struct {
name string // unique for each user
... // other fields
}
User
用于集群外的人员或应用。apiVersion: v1
kind: ServiceAccount
metadata:
name: sa:app1 # arbitrary but unique string
namespace: demo-namespace
User
或ServiceAccount
。对资源的访问进行建模
/api/v1/namespaces/{namespace}/pods/{name}
/api/v1/namespaces/{namespace}/pods/{name}/log
/api/v1/namespaces/{namespace}/serviceaccounts/{name}
verbs
,例如get
, list
, create
, patch
, delete
等。get
, list
以及 watch
Pods、logs和Services等资源。resources:
- /api/v1/namespaces/{namespace}/pods/{name}
- /api/v1/namespaces/{namespace}/pods/{name}/log
- /api/v1/namespaces/{namespace}/serviceaccounts/{name}
verbs:
- get
- list
- watch
· 基本 URL/api/v1/namespaces/对所有人都是通用的。也许我们可以省略它
· 我们可以假设所有资源都在当前namespace中并删除{namespace}路径
resources:
- pods
- pods/logs
- serviceaccounts
verbs:
- get
- list
- watch
CiliumEndpoint
自定义资源 (CR):apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
name: ciliumendpoints.cilium.io
spec:
group: cilium.io
names:
kind: CiliumEndpoint
scope: Namespaced
# truncated...
$ kubectl get ciliumendpoints.cilium.io -n demo-namespace
NAME ENDPOINT ID IDENTITY ENDPOINT STATE IPV4
IPV6
app1 2773 1628124 ready 10.6.7.54
app2 3568 1624494 ready 10.6.7.94
app3 3934 1575701 ready 10.6.4.24
$
/apis/cilium.io/v2/namespaces/{namespace}/ciliumendpoints
/apis/cilium.io/v2/namespaces/{namespace}/ciliumendpoints/{name}
resources:
- ciliumnetworkpolicies
- ciliumnetworkpolicies/status
verbs:
- get
apiGroups:
- cilium.io # APIGroup name
resources:
- ciliumnetworkpolicies
- ciliumnetworkpolicies/status
verbs:
- get
“”
空API组是一个特殊的组,它引用内置对象。因此,前面的定义应该扩展到:apiGroups:
- '' # Built-in objects
resources:
- pods
- pods/logs
- serviceaccounts
verbs:
- get
- list
- watch
resources
和verbs
的集合称为rules
,您可以将规则分组到列表中:rules:
- rule 1
- rule 2
apiGroups
,resources
和verbs
:rules: # Authorization rules
- apiGroups: # 1st API group
- '' # An empty string designates the core API group.
resources:
- pods
- pods/logs
- serviceaccounts
verbs:
- get
- list
- watch
- apiGroups: # another API group
- cilium.io # Custom APIGroup
resources:
- ciliumnetworkpolicies
- ciliumnetworkpolicies/status
verbs:
- get
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: viewer
rules: # Authorization rules
- apiGroups: # 1st API group
- '' # An empty string designates the core API group.
resources:
- pods
- pods/logs
- serviceaccounts
verbs:
- get
- list
- watch
- apiGroups: # another API group
- cilium.io # Custom APIGroup
resources:
- ciliumnetworkpolicies
- ciliumnetworkpolicies/status
verbs:
- get
· 具有用户、服务帐户和组的身份。
· 对具有角色的资源的权限。
向用户授予权限
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: role-binding-for-app1
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: viewer
subjects:
- kind: ServiceAccount
name: sa-for-app1
namespace: kube-system
· 引用viewer角色的roleRef
· 关联到sa-for-app1服务帐户的subjects
subjects
字段是一个包含kind
,namespace
和name
的列表。kind
属性是从服务帐户和组中识别用户所必需的。namespace
了?namespace
,并将对namespace
资源的访问限制为特定帐户,这通常很有帮助。subjects
的几个例子:subjects:
- kind: Group
name: system:serviceaccounts
apiGroup: rbac.authorization.k8s.io
# when the namespace field is not specified, this targets all service accounts in all namespace
subjects
:subjects:
- kind: Group
name: system:authenticated # for all authenticated users
apiGroup: rbac.authorization.k8s.io
- kind: Group
name: system:unauthenticated # for all unauthenticated users
apiGroup: rbac.authorization.k8s.io
想象一下,在集群中部署了一个需要通过 API 访问自定义资源的应用程序
如果不授予对这些API的访问权限,请求将失败,并显示403禁止的错误消息
首先,我们应该为我们的工作负载创建一个身份。在 Kubernetes 中,这意味着创建一个服务帐户。
然后,我们需要定义权限并将其包含到角色中
最后,我们希望通过RoleBinding将身份(服务帐户)关联到权限(角色)
下次应用程序向Kubernetes API发出请求时,它将被授予访问Cilium资源的权限
Namespaces和cluster-wide的资源
/api/v1/namespaces/{namespace}/pods/{name}
/api/v1/namespaces/{namespace}/pods/{name}/log
/api/v1/namespaces/{namespace}/serviceaccounts/{name}
/api/v1/nodes/{name}
/api/v1/persistentvolume/{name}
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: viewer
rules: # Authorization rules
- apiGroups: # 1st API group
- '' # An empty string designates the core API group.
resources:
- persistentvolumes
- nodes
verbs:
- get
- list
- watch
ClusterRole
(以及相应 ClusterRoleBinding
的为它分配subject
)。apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: viewer
rules: # Authorization rules
- apiGroups: # 1st API group
- '' # An empty string designates the core API group.
resources:
- persistentvolumes
- nodes
verbs:
- get
- list
- watch
kind
属性,而其他一切都保持不变。$ kubectl get roles -n kube-system | grep "^system:"
NAME
system::leader-locking-kube-controller-manager
system::leader-locking-kube-scheduler
system:controller:bootstrap-signer
system:controller:cloud-provider
system:controller:token-cleaner
# truncated output...
system:
前缀表示资源由集群控制平面直接管理。kubernetes.io/bootstrapping=rbac-defaults
。$ kubectl get clusterroles -n kube-system | grep "^system:"
NAME
system:aggregate-to-admin
system:aggregate-to-edit
system:aggregate-to-view
system:discovery
system:kube-apiserver
system:kube-controller-manager
system:kube-dns
system:kube-scheduler
# truncated output...
$ kubectl get role <role> -n kube-system -o yaml
# or
$ kubectl get clusterrole <clusterrole> -n kube-system -o yaml
1、如何使用用户、服务帐户和组创建身份
2、如何为具有角色的namespace中的资源分配权限
3、如何使用 ClusterRole 为集群资源分配权限
4、如何将 Roles 和 ClusterRoles 关联到subject
理解 Roles、RoleBindings、ClusterRoles 和 ClusterBindings
$ minikube start
😄 minikube v1.24.0
✨ Automatically selected the docker driver
👍 Starting control plane node in cluster
🚜 Pulling base image ...
🔥 Creating docker container (CPUs=2, Memory=4096MB) ...
🐳 Preparing Kubernetes v1.22.3 on Docker 20.10.8 ...
▪ Generating certificates and keys ...
▪ Booting up control plane ...
▪ Configuring RBAC rules ...
🔎 Verifying Kubernetes components...
▪ Using image gcr.io/k8s-minikube/storage-provisioner:v5
🌟 Enabled addons: storage-provisioner, default-storageclass
🏄 Done! kubectl is now configured to use the cluster and "default" namespace by default
$ kubectl create namespace test
namespace/test created
$ kubectl create namespace test2
namespace/test2 created
$ kubectl create namespace test3
namespace/test3 created
$ kubectl create namespace test4
namespace/test4 created
test
:apiVersion: v1
kind: ServiceAccount
metadata:
name: myaccount
namespace: test
$ kubectl apply -f service-account.yaml
serviceaccount/myaccount created
场景 1:Role和RoleBinding在同一个namespace
test
namespace的访问权限开始:kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: testadmin
namespace: test
rules:
- apiGroups: ['*']
resources: ['*']
verbs: ['*']
---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: testadminbinding
namespace: test
subjects:
- kind: ServiceAccount
name: myaccount
namespace: test
roleRef:
kind: Role
name: testadmin
apiGroup: rbac.authorization.k8s.io
$ kubectl apply -f scenario1.yaml
role.rbac.authorization.k8s.io/testadmin createdrolebinding.rbac.authorization.k8s.io/testadminbinding created
namespace
中。1、使用kubectl--as=jenkins进行用户模拟访问(https://kubernetes.io/docs/reference/access-authn-authz/authentication/#user-impersonation)
2、使用kubectl auth can-i验证API访问(https://kubernetes.io/docs/reference/access-authn-authz/authorization/#checking-api-access)
请注意,我们的用户应该拥有 impersonate
verb作为允许此操作的权限。
$ kubectl auth can-i get pods -n test --as=system:serviceaccount:test:myaccount
yes
· auth can-i需要查询授权模型(RBAC)
· get pods是verb和resource
· -n test是我们要发出命令的namespace
· --as=system:serviceaccount:test:myaccount用于模拟myaccount服务帐户
--as=
标志需要一些额外的提示来识别服务帐户。--as=system:serviceaccount:{namespace}:{service-account-name}
^^^^^^^^^^^^^^^^^^^^^
This should always be included for Service Accounts.
Role+ServiceAccount+RoleBindings
组合,我们可以访问test
namespace中的所有资源。场景 2:不同namespace中的 Role 和 RoleBinding
test2
。kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
namespace: test2
name: testadmin
rules:
- apiGroups: ['*']
resources: ['*']
verbs: ['*']
---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: testadminbinding
namespace: test2
subjects:
- kind: ServiceAccount
name: myaccount
namespace: test
roleRef:
kind: Role
name: testadmin
apiGroup: rbac.authorization.k8s.io
$ kubectl apply -f scenario2.yaml
role.rbac.authorization.k8s.io/testadmin created
rolebinding.rbac.authorization.k8s.io/testadminbinding created
$ kubectl auth can-i get pods -n test2 --as=system:serviceaccount:test:myaccount
yes
roleRef
(https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.18/#roleref-v1-rbac-authorization-k8s-io) 属性没有namespace字段。kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: testadminbinding
namespace: test2
subjects:
- kind: ServiceAccount
name: myaccount
namespace: test
roleRef:
kind: Role
name: testadmin
apiGroup: rbac.authorization.k8s.io
场景 3:使用有 RoleBinding 的 ClusterRole
test3
并将服务帐户关联到 ClusterRole cluster-admin
:cluster-admin
是 Kubernetes 中内置的 ClusterRoles 之一。
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: testadminbinding
namespace: test3
subjects:
- kind: ServiceAccount
name: myaccount
namespace: test
roleRef:
kind: ClusterRole
name: cluster-admin
apiGroup: rbac.authorization.k8s.io
$ kubectl apply -f scenario3.yaml
rolebinding.rbac.authorization.k8s.io/testadminbinding created
test
中的服务帐户是否可以访问test3
中的资源:$ kubectl auth can-i get pods -n test3 --as=system:serviceaccount:test:myaccount
yes
namespace
:$ kubectl auth can-i get pods -n test4 --as=system:serviceaccount:test:myaccount
no
$ kubectl auth can-i get pods --as=system:serviceaccount:test:myaccount
no
场景 4:使用 ClusterRole 和 ClusterRoleBinding 授予集群范围的访问权限
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: testadminclusterbinding
subjects:
- kind: ServiceAccount
name: myaccount
namespace: test
roleRef:
kind: ClusterRole
name: cluster-admin
apiGroup: rbac.authorization.k8s.io
roleRef
缺少namespace
字段。$ kubectl apply -f scenario3.yaml
rolebinding.rbac.authorization.k8s.io/testadminbinding created
$ kubectl auth can-i get pods -n test4 --as=system:serviceaccount:test:myaccount
yes
$ kubectl auth can-i get namespaces --as=system:serviceaccount:test:myaccount
Warning: resource 'namespaces' is not namespace scoped
yes
· Roles 和 RoleBindings 必须存在于同一个namespace中
· RoleBindings 可以存在于服务帐户的单独namespace中
· RoleBindings 可以关联 ClusterRoles,但它们只授予对 RoleBinding 所在 namespace的访问权限
· ClusterRoleBindings 将帐户关联到 ClusterRoles 并授予对所有资源的访问权限
· ClusterRoleBindings 不能引用角色
附加 #1:使 RBAC 策略更简洁
rules
部分如下所示:rules:
- apiGroups:
-"
resources:
- pods
- endpoints
- namespaces
verbs:
- get
- watch
- list
- create
- delete
- apiGroups: ['']
resources: ['services', 'endpoints', 'namespaces']
verbs: ['get', 'list', 'watch', 'create', 'delete']
$ kubectl get role pod-reader -o yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
rules:
- apiGroups:
-""
resources:
- pods
# truncated output...
附加 #2:使用服务帐户创建 Kubernetes 帐户
1、在 Pod 定义中注入 Service Account 属性的ServiceAccount准入控制器
2、一个创建伴随 Secret 对象的Token 控制器
3、ServiceAccount 控制器在每个namespace中创建默认服务帐户
$ kubectl create serviceaccount demo-sa
serviceaccount/demo-sa created
$ kubectl get serviceaccounts demo-sa -o yaml
apiVersion: v1
kind: ServiceAccount
metadata:
name: demo-sa
namespace: default
resourceVersion: "1985126654"
selfLink: /api/v1/namespaces/default/serviceaccounts/demo-sa
uid: 01b2a3f9-a373-6e74-b3ae-d89f6c0e321f
secrets:
- name: demo-sa-token-hrfq2
secrets
服务帐户 YAML 定义末尾的一个字段。$ kubectl get secret demo-sa-token-hrfq2 -o yaml
apiVersion: v1
data:
ca.crt: (APISERVER'S CA BASE64 ENCODED)
namespace: ZGVmYXVsdA==
token: (BEARER TOKEN BASE64 ENCODED)
kind: Secret
metadata:
# truncated output ...
type: kubernetes.io/service-account-token
secret
被挂载到POD中,用于访问API服务,但可以从集群外部使用。附加 #3:Kubernetes 默认的角色
默认 ClusterRole | 默认 ClusterRoleBinding | 描述 |
---|---|---|
cluster-admin | system:masters 组 | 允许超级用户在平台上的任何资源上执行所有操作。当在 ClusterRoleBinding 中使用时,可以授权对集群中以及所有名字空间中的全部资源进行完全控制。当在 RoleBinding 中使用时,可以授权控制 RoleBinding 所在名字空间中的所有资源,包括名字空间本身。 |
admin | 无 | 允许管理员访问权限,旨在使用 RoleBinding 在名字空间内执行授权。如果在 RoleBinding 中使用,则可授予对名字空间中的大多数资源的读/写权限, 包括创建角色和角色绑定的能力。此角色不允许对资源配额或者名字空间本身进行写操作。此角色也不允许对 Kubernetes v1.22+ 创建的 Endpoints 进行写操作。更多信息参阅“Endpoints 写权限”小节。 |
edit | 无 | 允许对名字空间的大多数对象进行读/写操作。它不允许查看或者修改角色或者角色绑定。不过,此角色可以访问 Secret,以名字空间中任何 ServiceAccount 的身份运行 Pods, 所以可以用来了解名字空间内所有服务账户的 API 访问级别。此角色也不允许对 Kubernetes v1.22+ 创建的 Endpoints 进行写操作。更多信息参阅“Endpoints 写操作”小节。 |
view | 无 | 允许对名字空间的大多数对象有只读权限。它不允许查看角色或角色绑定。此角色不允许查看 Secrets,因为读取 Secret 的内容意味着可以访问名字空间中 ServiceAccount 的凭据信息,进而允许利用名字空间中任何 ServiceAccount 的 身份访问 API(这是一种特权提升)。 |
默认 ClusterRole | 默认 ClusterRoleBinding | 描述 |
---|---|---|
system:kube-scheduler | system:kube-scheduler 用户 | 允许访问 scheduler 组件所需要的资源。 |
system:volume-scheduler | system:kube-scheduler 用户 | 允许访问 kube-scheduler 组件所需要的卷资源。 |
system:kube-controller-manager | system:kube-controller-manager 用户 | 允许访问控制器管理器 组件所需要的资源。各个控制回路所需要的权限在控制器角色 详述。 |
system:node | 无 | 允许访问 kubelet 所需要的资源,包括对所有 Secret 的读操作和对所有 Pod 状态对象的写操作。你应该使用 Node 鉴权组件 和 NodeRestriction 准入插件 而不是 system:node 角色。同时基于 kubelet 上调度执行的 Pod 来授权 kubelet 对 API 的访问。system:node 角色的意义仅是为了与从 v1.8 之前版本升级而来的集群兼容。 |
system:node-proxier | system:kube-proxy 用户 | 允许访问 kube-proxy 组件所需要的资源。 |
默认 ClusterRole | 默认 ClusterRoleBinding | 描述 |
---|---|---|
system:auth-delegator | 无 | 允许将身份认证和鉴权检查操作外包出去。这种角色通常用在插件式 API 服务器上,以实现统一的身份认证和鉴权。 |
system:heapster | 无 | 为 Heapster 组件(已弃用)定义的角色。 |
system:kube-aggregator | 无 | 为 kube-aggregator 组件定义的角色。 |
system:kube-dns | 在 kube-system 名字空间中的 kube-dns 服务账户 | 为 kube-dns 组件定义的角色。 |
system:kubelet-api-admin | 无 | 允许 kubelet API 的完全访问权限。 |
system:node-bootstrapper | 无 | 允许访问执行 kubelet TLS 启动引导 所需要的资源。 |
system:node-problem-detector | 无 | 为 node-problem-detector 组件定义的角色。 |
system:persistent-volume-provisioner | 无 | 允许访问大部分 动态卷驱动 所需要的资源。 |
system:monitoring | system:monitoring 组 | 允许对控制平面监控端点的读取访问(例如:kube-apiserver 存活和就绪端点(/healthz、/livez、/readyz), 各个健康检查端点(/healthz/、/livez/、/readyz/*)和 /metrics)。请注意,各个运行状况检查端点和度量标准端点可能会公开敏感信息。 |
内置控制器的角色
--use-service-account-credentials
参数启动时, kube-controller-manager 使用单独的服务账户来启动每个控制器。每个内置控制器都有相应的、前缀为 system:controller:
的角色。如果控制管理器启动时未设置 --use-service-account-credentials
, 它使用自己的身份凭据来运行所有的控制器,该身份必须被授予所有相关的角色。这些角色包括:· system:controller:attachdetach-controller
· system:controller:certificate-controller
· system:controller:clusterrole-aggregation-controller
· system:controller:cronjob-controller
· system:controller:daemon-set-controller
· system:controller:deployment-controller
· system:controller:disruption-controller
· system:controller:endpoint-controller
· system:controller:expand-controller
· system:controller:generic-garbage-collector
· system:controller:horizontal-pod-autoscaler
· system:controller:job-controller
· system:controller:namespace-controller
· system:controller:node-controller
· system:controller:persistent-volume-binder
· system:controller:pod-garbage-collector
· system:controller:pv-protection-controller
· system:controller:pvc-protection-controller
· system:controller:replicaset-controller
· system:controller:replication-controller
· system:controller:resourcequota-controller
· system:controller:root-ca-cert-publisher
· system:controller:route-controller
· system:controller:service-account-controller
· system:controller:service-controller
· system:controller:statefulset-controller
· system:controller:ttl-controller
附加 #4:初始化与预防权限升级
对角色创建或更新的限制
user-1
没有列举集群范围所有 Secret 的权限,他将不能创建包含该权限的 ClusterRole。若要允许用户创建/更新角色:· 隐式地为他们授权(如果它们试图创建或者更改 Role 或 ClusterRole 的权限, 但自身没有被授予相应权限,API 请求将被禁止)。
· 通过允许他们在 Role 或 ClusterRole 资源上执行 escalate 动作显式完成授权。这里的 roles 和 clusterroles 资源包含在 rbac.authorization.k8s.io API 组中。
对角色绑定创建或更新的限制
bind
动词时,你才可以创建或更新角色绑定。这里的权限与角色绑定的作用域相同。例如,如果用户 user-1
没有列举集群范围所有 Secret 的能力,则他不可以创建 ClusterRoleBinding 引用授予该许可权限的角色。如要允许用户创建或更新角色绑定:· 隐式授权下,可以将角色中包含的许可权限授予他们;
· 显式授权下,可以授权他们在特定 Role (或 ClusterRole)上执行 bind 动词的权限。
user-1
把名字空间 user-1-namespace
中的 admin
、edit
和 view
角色赋予其他用户:apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: role-grantor
rules:
- apiGroups: ["rbac.authorization.k8s.io"]
resources: ["rolebindings"]
verbs: ["create"]
- apiGroups: ["rbac.authorization.k8s.io"]
resources: ["clusterroles"]
verbs: ["bind"]
# 忽略 resourceNames 意味着允许绑定任何 ClusterRole
resourceNames: ["admin","edit","view"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: role-grantor-binding
namespace: user-1-namespace
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: role-grantor
subjects:
- apiGroup: rbac.authorization.k8s.io
kind: User
name: user-1
概括
https://cloud.google.com/kubernetes-engine/docs/how-to/role-based-access-control?hl=zh-cn https://zh.m.wikipedia.org/zh/%E4%BB%A5%E8%A7%92%E8%89%B2%E7%82%BA%E5%9F%BA%E7%A4%8E%E7%9A%84%E5%AD%98%E5%8F%96%E6%8E%A7%E5%88%B6
了解新钛云服
新钛云服荣膺第四届FMCG零售消费品行业CIO年会「年度数字化服务最值得信赖品牌奖」
新钛云服三周岁,公司月营收超600万元,定下百年新钛的发展目标
当IPFS遇见云服务|新钛云服与冰河分布式实验室达成战略协议
新钛云服正式获批工信部ISP/IDC(含互联网资源协作)牌照
新钛云服,打造最专业的Cloud MSP+,做企业业务和云之间的桥梁
往期技术干货
刚刚,OpenStack 第 19 个版本来了,附28项特性详细解读!
OpenStack与ZStack深度对比:架构、部署、计算存储与网络、运维监控等
点👇分享
戳👇在看
微信扫码关注该文公众号作者