[Kubernetes] Security - RBAC, ABAC

ABAC

Attribute-Based Access Control, User나 Group에 Permission Attribute를 지정해 접근을 제어하는 방식

이 방법은 개별 User나 Group에 대해 각각 권한 설정을 해줌에 따라 복잡하고 세밀한 권한제어가 가능하다. 허나 User나 Group의 수가 증가하게되는 경우, 이들을 일일히 ABAC로 권한 설정을 해주기는 어려울 것이다. 

 

 

ABAC policy 파일의 구성은 다음과 같다. 아래 Policy는 user 'jane'이 default namespace의 pod를 읽을 수 있도록 하는 내용이다. 

# abac_policy.json
{
  "apiVersion": "abac.authorization.kubernetes.io/v1beta1",
  "kind": "Policy",
  "spec": {
    "user": "jane",
    "namespace": "default",
    "resource": "pods",
    "apiGroup": "",
    "readonly": true
  }
}

 

 

policy 파일을 생성 후, Kube-API server가 이를 적용할 수 있도록 옵션을 설정 후 재시작해준다.

kube-apiserver --authorization-mode=ABAC \
	--authorization-policy-file=/path/to/abac_policy.json

 

 

Authorization Mode

Kube-API server에 인증을 하는 방법에는 크게 Node / ABAC / RBAC / Webhook, 4가지가 존재한다. 

Kube-API server의 configuration에서 Authorization Mode를 선택할 수 있다.

 

설정가능한 Authorization Mode는 Node / RBAC / ABAC / Webhook / AlwaysDeny / AlwaysAllow 가 있으며, 2개 이상을 설정한 경우에는 작성한 순서대로 우선순위를 갖고 동작한다.

자세한 내용은 Kubernetes Docs를 참조한다.

Authorization

 

 

RBAC

Role-Based Access Control, User나 Group에 직접 Permission을 매핑하는 것이 아닌 Role을 지정해주는 것

Role의 수정만으로, 해당 Role이 연결되어있는 모든 User나 Group에 대해 Permission을 한번에 관리할 수 있다.

이러한 점은 ABAC보다 상대적으로 설정과 관리가 간단하고 클러스터 내의 Role과 User간의 관계를 쉽게 이해할 수 있다.

 

쿠버네티스는 Role, RoleBinding, ClusterRole, ClusterRoleBinding 객체를 통해 RBAC를 구현한다.

이러한 RBAC는 AWS IAM에서 User나 Group에 Policy를 연결할 때에도 찾아볼 수 있다.

 

 

Role

특정 namespace 안에서 리소스에 대한 접근을 제어하기 위해 Permission들을 묶어서 만든 객체

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "watch", "list"]
    resourceNames: []
  - apiGroups: [""]
...

 

 

rules는 Role이 어떤 Resource에 대해, 어떤 Actions를 할 수 있는지를 정의하는 부분이다.

AWS IAM의 Policy와 유사한 요소들로 구성되어있는 것을 알 수 있다.

요소	설명
apiGroups	접근을 허용할 apiGroup, Kubernetes API 리소스의 그룹으로 core API 그룹의 경우 공백("")으로 넣어준다.
resources	접근을 허용할 리소스 타입 'pod', 'services', 'secrets' 등과 같은 객체가 대상이 될 수 있다.
resourceNames	특정한 리소스 이름을 지정해 그 자원에 대한 접근을 허용
verb	리소스에 대해 수행할 수 있는 동작 'get' / 'list' / 'watch' / 'create' / 'update' / 'delete'가 존재한다.

 

 

아래는 kubectl을 통해 Role을 제어하는 커맨드 목록이다.

# Role의 목록
kubectl get roles

# Role의 생성
kubectl create role [role명] --verb=[verb 목록] --resource=[resource 타입]

# Role check (이 user가 이 동작을 할 수 있나요?)
kubectl auth can-i [동작 (create pods, delete deployment, ...)] --as [user명]

 

RoleBinding

생성한 Role을 User나 Group에 묶어주기 위한 객체, Terraform에서 IAM 리소스를 연결하는 Attachment와 유사하다.

RoleBinding을 통해 비로소 User나 Group에 Role에 명시된 Permission을 갖게된다. 

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: default
subjects:
  - kind: User
    name: jane
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

 

RoleBinding에서는 2가지 요소가 선택되어야한다.

• subjects : Role을 연결할 대상을 지정, 위 예시에서는 jane User가 선택되었다.
• roleRef : 대상에 연결할 Role을 지정, 앞서 생성해주었던 'pod-reader' Role이 선택되었다.

 

ClusterRole

Node나 PV와 같은 Cluster 범위의 리소스들에 대한 Role, Namespace에 속하지 않는 리소스가 대상이다.

 

ClusterRole을 연결하기 위한 ClusterRoleBinding도 마찬가지로 존재한다. 

이들의 definition file 구조는 Role과 RoleBinding과 동일하다. (kind만 ClusterRole, ClusterRoleBinding)

 

 

 

이렇게 RBAC와 ABAC를 비교하며 알아보았다. RBAC와 ABAC 모두 일장일단이 존재하기에 둘 중 하나만 반드시 적합하다는 정답은 없다. 관리할 Cluster의 성격에 맞는 적절한 Access Control Type을 선택하는 것이 중요할 것이다.