Kubernetes Authorization (권한 검사 및 부여)

1. Kubernetes Authorization

Kubernetes 클러스터 안에서, 사용자는 curl 통신을 수행하거나 kubectl / kubeadm 등의 명령어를 이용하여 Kube-API Server 에 접근하고 이를 통해 클러스터 전체를 관리하게 된다. 클러스터의 관리자(Administrator of Cluster) 로서 사용자는 는 Deployment 를 생성하여 Pod를 관리하거나, Node 를 생성하거나 혹은 삭제하는 등의 리소스에 대한 모든 행동(action - verb)을 수행할 수 있다.

하지만 실제 클러스터를 관리함에 따라, 다양한 성격의 관리자나 개발자 혹은 테스터와 같은 사용자들이 클러스터에 접근하게 되는데, 이들에게는 각각 역할에 따라 크고 작은 다양한 권한이 필요하다.

예를 들어 어플리케이션 개발자의 경우 클러스터의 설정을 바꾸거나 노드를 삭제하거나 혹은 네트워크 설정이나 스토리지 설정을 변경하는 등의 권한은 필요하지 않지만, Pod / Deployment 등을 조회하거나 배포하는 권한은 필요하다. 또한 다른 팀과 클러스터를 공유하여 사용하는 경우에도 논리적으로 구분 지어진 네임스페이스 등을 사용하게 되는데, 이 때 특정 팀은 특정 네임스페이스에 대한 권한만 가질 수 있도록 해야 한다.

즉, 일단 임의의 사용자가 TLS 인증 등을 통하여 적법하게 Kube-API Server에 접근할 수 있게 되면, 그 다음으로는 그 사용자가 어떤 역할을 수행할 수 있는지가 중요해진다.

Kubernetes 에서는 이러한 사용자의 권한부여(Authorization)에 대하여 몇가지 매커니즘을 제공한다. 

• Node
• ABAC
• RBAC
• Webhook

---

1-1. Node Authorization

Node Authorization 는 클러스터 내부에서 kubelet 이 kube-api server 에 접근할 때를 위한 특수한 인증 처리이다.  kubelet 은 Service / Endpoint / Node / Pod 등의 정보를 얻기 위해 api server에 접근하게 되고 이 요청은 Node Authorizer 라는 특별한 Authorizer 에 의해 처리된다. Node Authorizer는, kubelet 이 속해 있는 그룹인, system:node 라는 이름으로 오는 요청에 대하여 내부적으로 인증하고 다음의 권한을 부여한다.

• 읽기 권한
  • Services / Endpoints
  • Nodes / Pods
  • Secrets / Configmaps
  • kubelet 의 해당 노드에 바운드 되어 있는, 파드가 사용하는 Persistent volume claims / Persistent Volume
• 쓰기 권한
  • Node / Node Status
  • Pods / Pods Status
  • Events
• 인증 관련 작업
  • TLS Bootstrap을 위한 CertificateSigningRequests API 에 대한 읽기/쓰기 권한
  • 위임된 인증/권한 부여 검사를 위해 TokenReviews 및 SubjectAccessReviews를 생성하는 기능

 

1-2. ABAC Authorization

ABAC은 '속성-기반 접근 제어(Attributed-Based Access Control)'의 약어로, 속성(Attribute)을 사용자나 그룹에게 결합하는 정책을 통하여 권한을 부여하는 방식이다. 사용자나 그룹에게 권한을 부여하기 위해 정책 파일을 사용하며 이 정책 파일은 하단과 같이 한 줄마다 json 파일로 사용자나 그룹에 대한 권한이 정의되어 있다.

{"kind":"Policy", "spec": {"user":"tester", "namespace": "default", "resource": "pods", "apiGroup": "*"}}
{"kind":"Policy", "spec": {"user":"devloper", "namespace": "kube-system", "resource": "pods", "apiGroup": "*"}}
{"kind":"Policy", "spec": {"user":"tester2", "namespace": "*", "resource": "pods", "apiGroup": "*"}}

이렇게 사용자 별로 '어떤 사용자가 어떤 역할을 할 수 있는지' 를 정의한 하나의 JSON line 이 할당되고 사용자가 수행할 수 있는 역할이 규정된다. 사용자의 권한이 변경될 경우 파일 자체가 수정되어야 하므로 관리하기가 어렵다는 단점이 있다.

 

1-3. RBAC Authorization

RBAC은 '역할-기반 접근제어(Role-Based Access Control)'의 약어이다. 먼저 특정 리소스에 대한 특정 행동(Verb)을 수행할 수 있는 규칙(rule)을 만들어 놓은 후에 그 롤을 사용자에게 매핑하여 사용자의 역할을 정해주는 방식이다. 

이렇게 '어떤 역할(Role)에 어떤 권한이 있고, 그 역할을 누가(User, ServiceAccount) 맡는지' 를 정의한다. 여러 사용자를 하나의 규칙에 대응시킬 수 있으며, 해당 역할의 권한 변경이 필요할 경우 역할 자체를 수정함으로써 그 역할과 대응되는 사용자의 권한 또한 일괄적으로 변경할 수 있다. 

 

1-4. Webhook Authorization

Webhook Authorization 은 인증에 관련된 매커니즘을 Kubernetes 에 내장(Built-in)된 매커니즘이 아니라, 외부에 맡길(Outsourcing) 때 사용한다. Admission Control 과 Authorization 등의 별도 인증 처리를 수행할 수 있는 3rd Party solution 을 추가로 사용하게 된다. 예를 들어 OPA(Open Policy Agent) 를 사용할 경우의 인증 과정은 아래와 같다.

1. 사용자가 Kube-API Server 에 인증을 요청
2. Kube-API Server 는 구동시 설정(하단 서술)된 인증 옵션에 따라 OPA 에 해당 요청을 위임
3. OPA 측에서 해당 요청을 처리하고 결과를 Kube-API Server 에 전달
4. Kube-API Server 에서 처리 결과에 따라 사용자에게 권한을 부여(Grant)

---

2. Authorization 적용 

이러한 Authorization 매커니즘의 적용은 kube api server 를 구동할 때 파라미터로 지정 가능하다.

apiVersion: v1
kind: Pod
metadata:
  name: kube-apiserver
  namespace: kube-system
spec:
  containers:
  - command:
    - kube-apiserver
    - --advertise-address=<ADVERTISE_ADDRESS>
    - --allow-privileged=true
    - --apiserver-count=1
	...
    - --authorization-mode=Node,RBAC #여기에 콤마로 구분하여 기술
	...
    - --default-not-ready-toleration-seconds=60
    - --default-unreachable-toleration-seconds=60
    - --encryption-provider-config=/etc/kubernetes/secrets/enc-config.yaml
    - --etcd-cafile=/etc/kubernetes/pki/etcd/ca.crt
    ...

위와 같이 kube-api server 구동 command 의 파라미터중 '--authorization-mode=' 항목에 값을 입력한다. 예시와 같이 콤마로 구분하여 하나 이상의 모드를 추가할 수 있다. 추가로 위 4개의 모드 외에 2개의 모드를 더 지원한다.

• Node
• ABAC
• RBAC
• Webhook
• AlwaysAllow : 어떠한 인증 검사 없이 모든 요청을 승인함
• AlwaysDeny : 모든 요청을 거부함

하나 이상의 Authorization mode 를 기술할 경우, 기술 순서대로 차례대로 인증을 수행한다.

만약 첫 번째 인증에서 실패할 경우, 2번째 인증으로 넘어가게 되며 이 중 하나라도 권한 획득에 성공할 경우 사용자는 해당 권한을 부여 받는다. 만약 모든  mode 에서 인증이 실패할 경우 그 인증은 최종적으로 실패하게 된다.

*참조 : https://kubernetes.io/docs/concepts/security/controlling-access/