Chinese - Ht Cloud
HackTricks TrainingTwitterLinkedinSponsor

Kubernetes Role-Based Access Control(RBAC)

Support HackTricks

Role-Based Access Control (RBAC)

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

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

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

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

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

“Roles” 和 “ClusterRoles” 之间的区别仅在于角色的应用范围 – “Role” 仅授予对 一个 特定 命名空间 的访问权限，而 “ClusterRole” 可以在集群中的 所有命名空间 中使用。此外，ClusterRoles 还可以授予对：

  • 集群范围 的资源（如节点）。

  • 非资源 端点（如 /healthz）。

  • 命名空间资源（如 Pods），跨所有命名空间。

从 Kubernetes 1.6 开始，RBAC 策略默认 启用。但要启用 RBAC，您可以使用类似以下的命令：

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

模板

在 Role 或 ClusterRole 的模板中，您需要指明 角色名称、命名空间（在角色中），然后是 apiGroups、资源 和 动词：

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

  • 资源 是一个数组，定义 此规则适用的资源。您可以通过以下命令找到所有资源：kubectl api-resources --namespaced=true

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

规则动词

(此信息来自 文档)

Kubernetes 有时会使用专门的动词检查额外的授权权限。例如：

  • PodSecurityPolicy

  • use 动词在 policy API 组中的 podsecuritypolicies 资源上。

  • RBAC

  • bind 和 escalate 动词在 rbac.authorization.k8s.io API 组中的 roles 和 clusterroles 资源上。

  • 身份验证

  • impersonate 动词在核心 API 组中的 users、groups 和 serviceaccounts 以及在 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"]
集群角色
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

来自文档： 角色绑定将角色中定义的权限授予用户或用户集。它包含一个主题列表（用户、组或服务账户），以及对被授予角色的引用。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

权限是累加的，因此如果您有一个 clusterRole，具有“列出”和“删除”秘密的权限，您可以将其与具有“获取”权限的 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

滥用角色/集群角色进行权限提升

支持 HackTricks
PreviousKubernetes EnumerationNextAbusing Roles/ClusterRoles in Kubernetes

Last updated