Kubernetes Role-Based Access Control(RBAC)

Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

• Check the subscription plans!

• Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.

• Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.

Role-Based Access Control (RBAC)

Kubernetes에는 API 서버에 대한 사용 권한을 설정하는 데 도움이 되는 역할 기반 액세스 제어(RBAC)라는 권한 모듈이 있습니다.

RBAC의 권한 모델은 세 가지 개별 부분으로 구성됩니다:

1. Role\ClusterRole ­– 실제 권한. 권한 집합을 나타내는 _규칙_을 포함합니다. 각 규칙은 리소스와 동사를 포함합니다. 동사는 리소스에 적용될 작업입니다.

2. 주체 (사용자, 그룹 또는 서비스 계정) – 권한을 받을 객체입니다.

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

Templates

Role 또는 ClusterRole의 템플릿에서는 역할의 이름, 네임스페이스(역할의 경우) 및 apiGroups, resources 및 verbs를 지정해야 합니다:

• apiGroups는 이 규칙이 적용되는 다양한 API 네임스페이스를 포함하는 배열입니다. 예를 들어, Pod 정의는 apiVersion: v1을 사용합니다. rbac.authorization.k8s.io 또는 [*]와 같은 값을 가질 수 있습니다.

• resources는 이 규칙이 적용되는 리소스를 정의하는 배열입니다. 모든 리소스는 다음 명령어로 찾을 수 있습니다: kubectl api-resources --namespaced=true

• verbs는 허용된 동사를 포함하는 배열입니다. Kubernetes의 동사는 리소스에 적용해야 하는 작업의 유형을 정의합니다. 예를 들어, list 동사는 컬렉션에 대해 사용되며 "get"은 단일 리소스에 대해 사용됩니다.

Rules Verbs

(이 정보는 문서 에서 가져왔습니다)

HTTP 동사	요청 동사
POST	create
GET, HEAD	get (개별 리소스에 대해), list (컬렉션에 대해, 전체 객체 내용 포함), watch (개별 리소스 또는 리소스 컬렉션을 감시하기 위해)
PUT	update
PATCH	patch
DELETE	delete (개별 리소스에 대해), deletecollection (컬렉션에 대해)

Kubernetes는 때때로 전문 동사를 사용하여 추가 권한에 대한 승인을 확인합니다. 예를 들어:

• PodSecurityPolicy

• policy API 그룹의 podsecuritypolicies 리소스에 대한 use 동사.

• RBAC

• rbac.authorization.k8s.io API 그룹의 roles 및 clusterroles 리소스에 대한 bind 및 escalate 동사.

• Authentication

• 코어 API 그룹의 users, groups, 및 serviceaccounts에 대한 impersonate 동사, 그리고 authentication.k8s.io API 그룹의 userextras.

각 리소스가 지원하는 모든 동사를 찾으려면 kubectl api-resources --sort-by name -o wide를 실행하세요.

Examples

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

문서에서: 역할 바인딩은 역할에 정의된 권한을 사용자 또는 사용자 집합에 부여합니다. 이는 주체(사용자, 그룹 또는 서비스 계정)의 목록과 부여되는 역할에 대한 참조를 포함합니다. 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" 비밀이 있는 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

권한 상승을 위한 역할/클러스터 역할 남용

Abusing Roles/ClusterRoles in Kubernetes

AWS 해킹 배우기 및 연습하기:HackTricks Training AWS Red Team Expert (ARTE) GCP 해킹 배우기 및 연습하기: HackTricks Training GCP Red Team Expert (GRTE)

HackTricks 지원하기

• 구독 계획 확인하기!

• **💬 Discord 그룹 또는 텔레그램 그룹에 참여하거나 Twitter 🐦 @hacktricks_live를 팔로우하세요.

• HackTricks 및 HackTricks Cloud 깃허브 리포지토리에 PR을 제출하여 해킹 팁을 공유하세요.