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

模板

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

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

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

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

规则动词

(此信息来自 文档)

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

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

  • bindescalate 动词在 rbac.authorization.k8s.io API 组中的 rolesclusterroles 资源上。

  • impersonate 动词在核心 API 组中的 usersgroupsserviceaccounts 以及在 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

Last updated