k8s-RBAC与SA
文章目录RBACRole和RoleBindingRoleRoleBinding验证ClusterRole和ClusterRoleBindingClusterRoleClusterRoleBinding验证定义ServiceAccount参考RBAC基于角色的访问控制(Role-Based Access Control, 即”RBAC”)使用”rbac.authorization.k8s.io” A
文章目录
RBAC
- 基于角色的访问控制(Role-Based Access Control, 即”RBAC”)使用”rbac.authorization.k8s.io” API Group实现授权决策,允许管理员通过Kubernetes API动态配置策略。
- 基于RBAC配置User权限,包括操作(get、create、list、delete、update、patch、edit、watch、exec)资源:
Pods
PV
ConfigMaps
Deployments
Nodes
Secrets
Namespaces
Role和RoleBinding
Role
下面是一个位于 “default” 名字空间的 Role 的示例,可用来授予对 pods 的读访问权限:
role.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: default
name: pod-reader
rules:
- apiGroups: [""] # "" indicates the core API group
resources: ["pods"]
verbs: ["get", "watch", "list"]
RoleBinding
roleBinding.yaml
apiVersion: rbac.authorization.k8s.io/v1
# 此角色绑定允许 "system:serviceaccount:default" 读取 "default" 名字空间中的 Pods
# You need to already have a Role named "pod-reader" in that namespace.
kind: RoleBinding
metadata:
name: read-pods
namespace: default
subjects:
# 你可以指定不止一个“subject(主体)”
- kind: ServiceAccount
name: default # "name" is case sensitive
namespace: default
roleRef:
# "roleRef" 指定与某 Role 或 ClusterRole 的绑定关系
kind: Role # 此字段必须是 Role 或 ClusterRole
name: pod-reader # 此字段必须与你要绑定的 Role 或 ClusterRole 的名称匹配
apiGroup: rbac.authorization.k8s.io
验证
$ kubectl apply -f role.yaml
role.rbac.authorization.k8s.io/pod-reader created
$ kubectl apply -f roleBinding.yaml
rolebinding.rbac.authorization.k8s.io/read-pods created
$ kubectl get role,rolebinding
NAME CREATED AT
role.rbac.authorization.k8s.io/pod-reader 2022-04-13T13:34:47Z
NAME ROLE AGE
rolebinding.rbac.authorization.k8s.io/read-pods Role/pod-reader 15s
$ kubectl auth can-i list pods --as=system:serviceaccount:default:default -n default
yes
ClusterRole和ClusterRoleBinding
ClusterRole
clusterRole.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
# "namespace" 被忽略,因为 ClusterRoles 不受名字空间限制
name: node-reader
rules:
- apiGroups: [""]
# 在 HTTP 层面,用来访问 Node 对象的资源的名称为 "nodes"
resources: ["nodes"]
verbs: ["get", "watch", "list"]
ClusterRoleBinding
clusterRoleBinding.yaml
apiVersion: rbac.authorization.k8s.io/v1
# 此集群角色绑定允许 “system:serviceaccount:default” 组中的任何人访问任何名字空间中的 nodes
kind: ClusterRoleBinding
metadata:
name: read-nodes
subjects:
- kind: ServiceAccount
name: default
namespace: default
roleRef:
kind: ClusterRole
name: node-reader
apiGroup: rbac.authorization.k8s.io
验证
$ kubectl apply -f clusterRole.yaml
clusterrole.rbac.authorization.k8s.io/node-reader created
$ kubectl apply -f clusterRoleBinding.yaml
clusterrolebinding.rbac.authorization.k8s.io/read-nodes created
$ kubectl get clusterrole,clusterrolebinding
NAME CREATED AT
clusterrole.rbac.authorization.k8s.io/node-reader 2022-04-13T13:37:08Z
NAME ROLE AGE
clusterrolebinding.rbac.authorization.k8s.io/read-nodes ClusterRole/node-reader 104s
$ kubectl auth can-i list nodes --as=system:serviceaccount:default:default
Warning: resource 'nodes' is not namespace scoped
yes
定义ServiceAccount
客户端访问k8s API服务的途径通常有三种:kubectl、客户端库或者直接使用 REST接口进行请求。
而可以执行此类请求的主体也被 Kubernetes 分为两类:现实中的“人”和 Pod 对象,
它们的用户身份分别对应于常规用户 (User Account )和服务账号 ( Service Account) 。
-
Use Account(用户账号):一般是指由独立于Kubernetes之外的其他服务管理的用 户账号,例如由管理员分发的密钥、Keystone一类的用户存储(账号库)、甚至是包 含有用户名和密码列表的文件等。Kubernetes中不存在表示此类用户账号的对象, 因此不能被直接添加进 Kubernetes 系统中 。
-
Service Account(服务账号):是指由Kubernetes API 管理的账号,用于为Pod 之中的服务进程在访问Kubernetes API时提供身份标识( identity ) 。Service Account通常要绑定于特定的命名空间,它们由 API Server 创建,或者通过 API 调用于动创建 ,附带着一组存储为Secret的用于访问API Server的凭据。
apiVersion: v1
kind: ServiceAccount
metadata:
name: ts
namespace: test
labels:
test: ts
参考
更多推荐
所有评论(0)