Kubernetes Role-Based Access Control(RBAC)

支持HackTricks

基于角色的访问控制(RBAC)

Kubernetes有一个名为基于角色的访问控制(RBAC)的授权模块,可帮助设置对API服务器的使用权限。

RBAC的权限模型由三个独立部分构成:

  1. Role\ClusterRole – 实际权限。它包含代表一组权限的规则。每个规则包含资源动词。动词是将应用于资源的操作。

  2. Subject(用户、组或ServiceAccount) – 将接收权限的对象。

  3. RoleBinding\ClusterRoleBinding – Role\ClusterRole和Subject之间的连接。

Roles”和“ClusterRoles”之间的区别仅在于角色将应用的位置 – “Role”将仅授予对一个特定命名空间的访问权限,而“ClusterRole”可用于集群中的所有命名空间。此外,ClusterRoles还可以授予对以下内容的访问权限:

  • 集群范围资源(如节点)。

  • 非资源端点(如/healthz)。

  • 命名空间资源(如Pods),跨所有命名空间

Kubernetes 1.6开始,RBAC策略默认启用。但要启用RBAC,您可以使用类似以下内容:

kube-apiserver --authorization-mode=Example,RBAC --other-options --more-options

模板

RoleClusterRole的模板中,您需要指定角色的名称命名空间(在角色中),然后是角色的apiGroups资源动词

  • apiGroups是一个包含此规则适用于的不同API命名空间的数组。例如,Pod定义使用apiVersion:v1。它可以具有值,如rbac.authorization.k8s.io或[*]

  • 资源是一个定义此规则适用于哪些资源的数组。您可以使用以下命令找到所有资源:kubectl api-resources --namespaced=true

  • 动词是一个包含允许的动词的数组。Kubernetes中的动词定义了您需要对资源应用的操作类型。例如,list动词用于集合,而"get"用于单个资源。

规则动词

此信息摘自 文档

HTTP动词请求动词

POST

create

GET, HEAD

get(用于单个资源),list(用于集合,包括完整对象内容),watch(用于监视单个资源或资源集合)

PUT

update

PATCH

patch

DELETE

delete(用于单个资源),deletecollection(用于集合)

有时Kubernetes使用专门的动词检查附加权限的授权。例如:

  • policy API组中对podsecuritypolicies资源使用use动词。

  • rbac.authorization.k8s.io API组中对rolesclusterroles资源使用bindescalate动词。

  • 在核心API组中对usersgroupsserviceaccounts使用impersonate动词,并在authentication.k8s.io API组中对userextras使用。

您可以通过执行kubectl api-resources --sort-by name -o wide找到每个资源支持的所有动词

示例

Role
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: defaultGreen
name: pod-and-pod-logs-reader
rules:
- apiGroups: [""]
resources: ["pods", "pods/log"]
verbs: ["get", "list", "watch"]
ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
# "namespace" omitted since ClusterRoles are not namespaced
name: secret-reader
rules:
- apiGroups: [""]
resources: ["secrets"]
verbs: ["get", "watch", "list"]

例如,您可以使用ClusterRole来允许特定用户运行:

kubectl get pods --all-namespaces

RoleBinding和ClusterRoleBinding

来自文档: 一个role binding授予了在一个角色中定义的权限给一个用户或一组用户。它包含了一组主体(用户、组或服务账户)以及被授予的角色的引用。RoleBinding在特定的命名空间内授予权限,而ClusterRoleBinding则在整个集群范围内授予权限。

piVersion: rbac.authorization.k8s.io/v1
# This role binding allows "jane" to read pods in the "default" namespace.
# You need to already have a Role named "pod-reader" in that namespace.
kind: RoleBinding
metadata:
name: read-pods
namespace: default
subjects:
# You can specify more than one "subject"
- kind: User
name: jane # "name" is case sensitive
apiGroup: rbac.authorization.k8s.io
roleRef:
# "roleRef" specifies the binding to a Role / ClusterRole
kind: Role #this must be Role or ClusterRole
name: pod-reader # this must match the name of the Role or ClusterRole you wish to bind to
apiGroup: rbac.authorization.k8s.io
ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
# This cluster role binding allows anyone in the "manager" group to read secrets in any namespace.
kind: ClusterRoleBinding
metadata:
name: read-secrets-global
subjects:
- kind: Group
name: manager # Name is case sensitive
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: secret-reader
apiGroup: rbac.authorization.k8s.io

权限是可累加的,因此如果您有一个具有“list”和“delete” secrets 的 clusterRole,您可以将其与一个具有“get”的 Role 结合使用。因此,请注意并始终测试您的角色和权限,并指定允许的操作,因为默认情况下一切都被拒绝。

枚举 RBAC

# Get current privileges
kubectl auth can-i --list
# use `--as=system:serviceaccount:<namespace>:<sa_name>` to impersonate a service account

# List Cluster Roles
kubectl get clusterroles
kubectl describe clusterroles

# List Cluster Roles Bindings
kubectl get clusterrolebindings
kubectl describe clusterrolebindings

# List Roles
kubectl get roles
kubectl describe roles

# List Roles Bindings
kubectl get rolebindings
kubectl describe rolebindings

滥用角色/ClusterRoles 进行特权升级

Abusing Roles/ClusterRoles in Kubernetes
支持 HackTricks

Last updated