Kubernetes Role-Based Access Control(RBAC)

AWS 해킹 학습 및 실습:HackTricks Training AWS Red Team Expert (ARTE) GCP 해킹 학습 및 실습: HackTricks Training GCP Red Team Expert (GRTE)

HackTricks 지원

• 구독 요금제를 확인하세요!

• 💬 디스코드 그룹에 가입하거나 텔레그램 그룹에 참여하거나 트위터 🐦 @hacktricks_live를 팔로우하세요.

• HackTricks 및 HackTricks Cloud 깃헙 레포지토리에 PR을 제출하여 해킹 요령을 공유하세요.

역할 기반 액세스 제어 (RBAC)

쿠버네티스에는 **Role-Based Access Control(RBAC)**이라는 인가 모듈이 있어 API 서버에 대한 이용 권한을 설정하는 데 도움이 됩니다.

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

1. Role\ClusterRole ­– 실제 권한을 포함합니다. 일련의 권한을 나타내는 _rules_이 포함되어 있습니다. 각 rule에는 리소스 및 동사가 포함됩니다. 동사는 리소스에 적용될 작업입니다.

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

3. RoleBinding\ClusterRoleBinding – Role\ClusterRole과 subject 간의 연결입니다.

“Roles”과 “ClusterRoles”의 차이점은 역할이 적용되는 위치뿐입니다 – “Role”은 특정 네임스페이스에만 액세스 권한을 부여하고, “ClusterRole”은 클러스터의 모든 네임스페이스에서 사용할 수 있습니다. 또한 ClusterRoles은 다음에도 액세스 권한을 부여할 수 있습니다:

• 클러스터 범위 리소스(노드와 같은).

• 비 리소스 엔드포인트(/healthz와 같은).

• 네임스페이스 리소스(팟과 같은), 모든 네임스페이스에서.

쿠버네티스 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에서의 동사는 리소스에 적용해야 하는 작업 유형을 정의합니다. 예를 들어 목록 동사는 컬렉션에 대해 사용되며 "get"은 단일 리소스에 대해 사용됩니다.

규칙 동사

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

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

• authentication.k8s.io API 그룹의 users, groups, serviceaccounts에서 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

문서에서: RoleBinding은 역할에 정의된 권한을 사용자 또는 일련의 사용자에게 부여합니다. 사용자, 그룹 또는 서비스 계정 목록을 보유하고 부여된 역할에 대한 참조를 보유합니다. 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 그룹 또는 텔레그램 그룹에 참여하거나 트위터 🐦 @hacktricks_live를 팔로우하세요.

• 해킹 팁을 공유하려면 HackTricks 및 HackTricks Cloud 깃허브 저장소에 PR을 제출하세요.