[CKA] 47. RBAC

Date

2025/01/15

Create Role

RBAC에서의 Role은 Object를 생성하여 사용할 수 있다. 일반 객체들처럼 정의 파일을 생성해 정의할 수 있다.

Developer라는 역할에 Pod에 대한 조회, 생성, 삭제와 ConfigMap에 대한 생성 권한을 부여한다고 한다면 아래와 같이 역할을 정의할 수 있다.

# developer-role.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
	name: developer
rules:
- apiGroups: [""]
	resources: ["pods"]
	verbs: ["list", "get", "create", "update", "delete"]
- apiGroups: [""]
	resources: ["ConfigMap"]
	verbs: ["create"]
YAML
복사

역할의 각 규칙은 apiGroups, resources, verbs 세 가지 섹션으로 나뉜다. Core Group이라면 apiGroups 섹션을 비워둘 수 있지만, 아니라면 apiGroups 섹션에 명시해야 한다. 위 코드에서 Pod와 ConfigMap은 core group이기 때문에 apiGroups를 비울 수 있다.

Link User to Role

사용자를 역할에 연결하기 위해서는 RoleBinding이라는 객체를 사용한다.

# devuser-developer-binding.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
	name: devuser-developer-binding
subjects:
- kind: User
	name: dev-user
	apiGroup: rbac.authorization.k8s.io
roleRef:
	kind: Role
	name: developer
	apiGroup: rbac.authorization.k8s.io
YAML
복사

subjects는 사용자의 세부 정보를 지정하는 곳이며, roleRef에서는 역할에 대한 정보를 제공하는 곳이다. 코드를 보면 알겠지만 subjects는 리스트로서 여러 사용자 및 그룹을 가지지만 roleRef는 단일 역할만 가질 수 있다.

View RBAC

•

kubectl get roles

•

kubectl get rolebingings

•

kubectl describe role <role>

◦

해당 role에 대한 정책들 확인 가능

▪

Resources, Permissions of Resources

•

kubectl describe rolebinding <rolebinding>

◦

연결된 역할과 Subject 목록 확인 가능

Check Access

사용자가 클러스터의 특정 리소스에 대한 접근 권한이 있는지 확인할 수 있는 방법이 있다. kubectl auth can-i 명령을 사용하며, 해당 명령을 통해 yes/no로 권한을 확인할 수 있다.

# kubectl auth can-i <verb> <resouce>
kubectl auth can-i create deployments
kubectl auth can-i delete nodes
Bash
복사

다른 사용자에 대한 권한을 테스트하기 위해 클러스터로 해당 사용자의 인증을 받아 접속해야 할까? 그렇지 않아도 된다. --as 옵션을 통해 특정 사용자에 대한 권한을 확인할 수 있다. 이를 활용해서 특정 네임스페이스에서 작동이 가능한지도 확인할 수 있다.

# kubectl auth can-i <verb> <resouce> --as <user>
kubectl auth can-i create deployments --as dev-user
kubectl auth can-i create deployments --as dev-user --namespace test
kubectl auth can-i delete nodes --as dev-user
Bash
복사

Restrict Access

Namespace

생성한 Role과 RoleBinding은 네임스페이스 범위 내에 있다는 것을 주목해야 한다. Role의 metadata.namespace에 지정된 네임스페이스의 리소스에만 접근이 가능하며, 기본값은 default 네임스페이스다.

예시로 위에서 생성한 developer라는 Role은 default 네임스페이스에서 Pod와 ConfigMap에 대한 접근이 가능한 것이다. 따라서 다른 네임스페이스에서 역할의 접근을 제한하고 싶다면 정의 파일에 네임스페이스를 지정해야 한다.

Resource Name

네임스페이스로 클러스터내의 리소스에 대한 접근을 제한할 수 있지만, 더 좁은 제한도 가능하다. Role에서 rules.resourceNames를 통해 가능한데, 이는 접근 가능한 Namespace 내에서 해당 이름을 가지는 리소스에만 접근을 가능하게 하는 것이다.

# developer-role.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
	name: developer
rules:
- apiGroups: [""]
	resources: ["pods"]
	verbs: ["get", "create", "update"]
	resourceNames: ["blue", "orange"]
YAML
복사

위 역할은 default 네임스페이스 내에서 blue, orange 이름을 가진 Pod에 대하여 조회, 생성, 수정이 가능하다.