Kubernetes Role-Based Access Control(RBAC)

Reading time: 6 minutes

tip

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

HackTricks 지원하기

Role-Based Access Control (RBAC)

Kubernetes에는 API 서버에 대한 사용 권한을 설정하는 데 도움이 되는 Role-Based Access Control (RBAC)라는 권한 모듈이 있습니다.

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

  1. Role\ClusterRole ­– 실제 권한. 권한 집합을 나타내는 _규칙_을 포함합니다. 각 규칙은 리소스동사를 포함합니다. 동사는 리소스에 적용될 작업입니다.
  2. 주체 (User, Group 또는 ServiceAccount) – 권한을 받을 객체입니다.
  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"은 단일 리소스에 대해 사용됩니다.

규칙 동사

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

HTTP 동사요청 동사
POSTcreate
GET, HEADget (개별 리소스에 대해), list (컬렉션에 대해, 전체 객체 내용 포함), watch (개별 리소스 또는 리소스 컬렉션을 감시하기 위해)
PUTupdate
PATCHpatch
DELETEdelete (개별 리소스에 대해), deletecollection (컬렉션에 대해)

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

  • PodSecurityPolicy
  • policy API 그룹의 podsecuritypolicies 리소스에 대한 use 동사.
  • RBAC
  • rbac.authorization.k8s.io API 그룹의 rolesclusterroles 리소스에 대한 bindescalate 동사.
  • 인증
  • 코어 API 그룹의 users, groups, 및 serviceaccounts에 대한 impersonate 동사, 그리고 authentication.k8s.io API 그룹의 userextras.

warning

각 리소스가 지원하는 모든 동사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은 특정 네임스페이스 내에서 권한을 부여하는 반면, ClusterRoleBinding은 해당 접근을 클러스터 전체에 부여합니다.

RoleBinding
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 열거하기

bash
# 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

tip

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

HackTricks 지원하기