[Kubernetes] k8s에서의 접근 권한 제어하기: SA와 RBAC

🔊 해당 포스팅은 시작하세요! 도커/쿠버네티스 서적을 읽고 개인적인 목적 하에 작성되는 글입니다. 포스팅에 사용되는 모든 자료는 제가 직접 재구성하였음을 알립니다.
 

Kubernetes

---

일반적으로 쿠버네티스를 사용하는 환경은 한 명의 개발자가 운영하고 사용하는 경우는 거의 없다. 대부분 여러 명의 DevOps 개발자 또는 여러 명의 백엔드 개발자, MLOps 개발자 등 인프라를 들여다보는 개발자들이 함께 사용한다. 하지만 이 모든 개발자들이 동일한 범위의 권한으로 k8s 클러스터를 제어하지는 않는다. 운영체제가 유저 별로 디렉토리 또는 파일에 접근 권한을 다르게 부여하여 관리하는 것처럼 쿠버네티스에서도 유저 또는 애플리케이션 별로 쿠버네티스에 접근 권한을 제어할 수가 있다.

 

이번 포스팅에서는 쿠버네티스에서 RBAC(Role Based Access Control)을 기반으로 하는 서비스 어카운트(Service Account)라는 리소스 오브젝트, 그리고 RBAC을 가능하게 하는 롤, 클러스터 롤 이라는 리소스 오브젝트에 대해서도 배워보도록 하자.

1. 쿠버네티스에서는 권한 인증을 어떻게 할까?

이전 목차에서 ResourceQuota 라는 리소스 오브젝트를 배움으로써 간단하게나마 사용자가 쿠버네티스로 요청을 보냈을 때, 내부적으로 어떤 과정이 수행되는지 살펴보았었다. 그때 살펴본 그림을 다시 가져와보자. 당시에는 아래 그림에서 Mutating Admission Controller, Validating Adminssion Controller 단계에 대해 설명했었다.

 

사용자가 쿠버네티스로 요청을 보낸다면?

 

이번에 우리가 살펴볼 부분은 Authentication(인증)과 Authorization(인가)이다. Authentication은 요청을 보낸 클라이언트가 쿠버네티스의 사용자가 맞는지 검사하는 부분이다. 반면에 Authorization 부분은 클라이언트가 보낸 요청한 어떤 기능을 실행할 권한이 그 클라이언트가 갖고 있는지 확인하는 부분이다.

 

일례로, 어떤 클라이언트가 kube-system 이라는 네임스페이스의 파드를 출력하는 요청을 보냈다고 해보자. 이 클라이언트는 쿠버네티스 사용자임은 맞아서 Authentication 단계가 통과가 되었지만 파드 목록을 출력하는 기능을 실행하는 권한이 없다면 해당 클라이언트는 403 에러를 반환받을 것이다.

 

이러한 인증과 인가에서 쿠버네티스는 서비스 어카운트를 사용할 수도 있고, 서드파티 인증(OIDC, Open ID Connect: OAuth), 인증서 등을 사용할 수 있다. 

2. 기본적인 인증, 인가 방법: kubeconfig 활용하기!

쿠버네티스를 설치하거나 새로운 쿠버네티스 클러스터에 접근하기 위해서 가장 처음 시도하는 방식은 kubectl CLI를 수행해서 접근할 것이다. kubectl 명령어를 사용할 때는 기본적으로 .kube 라는 디렉토리의 config 파일(.kube/config)에 저장된 설정을 읽어들여 쿠버네티스 클러스터에 접근을 수행한다. 해당 파일은 보통 로컬 호스트의 홈 디렉토리에 위치하기 때문에 대부분 ~/.kube/config 경로에 존재할 것이다. 그리고 이러한 config 파일을 바로 kubeconfig 라고 부른다.

 

해당 파일을 열어보면 크게 clusters, contexts, users 항목이 들어있고, 각 항목들은 여러 가지 값들을 포함하고 있을 수 있다.(YAML의 array) 예시 내용은 다음과 같다.

 

출처: https://www.nathannellans.com/post/kubernetes-using-kubectl-with-kubeconfig-files

 

위 config 파일 내용을 보면 users 라는 항목에는 인증을 위한 데이터가 저장되어 있다. 보면 client-certificate 와 client-key에 설정된 경로에 파일은 bsas64로 인코딩된 인증서(공개키와 비밀키)이며, 이 키 쌍은 쿠버네티스에서 최고 권한(cluster-admin) 권한을 갖게된다. 그리고 clusters 항목에는 접근하기 위한 쿠버네티스 클러스터들에 대한 정보를 갖고 있다.

 

하지만 이러한 config 파일과 인증서를 활용해서 쿠버네티스 클러스터로부터 인증을 받는 방법은 절차가 복잡하고 관리하기가 어렵기 때문에 자주 사용되지는 않는다. 다른 방법 중 대표적인 방식은 바로 서비스 어카운트를 활용하는 것이다.

3. 또 다른 인증, 인가 방법 : ServiceAccount 활용하기

이번엔 쿠버네티스 클러스터, 엄밀히 말하면 kube-apiserver로부터 클라이언트를 인증, 인가하는 또 다른 방법인 ServiceAccount(이하 SA)를 이용하는 방법에 대해 배워보자. SA는 한 명의 사용자 또는 애플리케이션에 해당한다고 생각하면 된다. SA는 네임스페이스에 종속적인 오브젝트이며 serviceaccount 또는 sa 이름으로 사용이 가능하다. 참고로 kubectl 명령어를 사용할 때, 특정 SA를 사용해서 kube-apiserver로 요청을 보낼 수도 있는데(이를 Impersonate 라고 부름), 사용 명령어 예시는 다음과 같다.

 

kubectl get pods --as system:serviceaccount:$NAMESPACE:$SA_NAME

 

그런데 SA 리소스 오브젝트를 새로 생성하거나 또는 기존에 이용하고 있던 SA를 이용한다고 가정해보자. 이게 끝일까? 아니다. 우리는 SA를 사용해서 원하는 기능을 클러스터에서 수행하기 위해 kube-apiserver로부터 인증, 인가를 받아야 한다. 그러면 우리가 사용할 SA에 어떤 권한을 부여할지를 명시해주어야 한다. 

 

이를 살펴보기 위해 먼저 큰 그림부터 살펴보자. 결론부터 말하면 SA에 권한을 부여하려면 SA 말고도 롤(Role)과 롤바인딩(RoleBinding)이라는 리소스 오브젝트를 추가로 생성해주어야 한다. SA, 롤, 롤바인딩 간의 관계를 나타내면 아래와 같다.

 

SA, Role, RoleBinding 간의 관계

 

생각보다 간단하다. 정리하면 SA에는 계정에 대한 정보를 명시, (SA가 사용할)권한들은 Role에 명시, 그 Role을 어떤 SA에다가 연결(바인딩)해줄지는 RoleBinding에 명시한다. 그런데 왜 이렇게 3가지로 각각 분리를 수행했을까? 그냥 SA에 하나에 Role, RoleBinding을 다 명시하면 되는거 아닌가? 싶기도 하다. 사견이지만, 하나의 리소스 오브젝트에는 최소의 기능만 포함시켜 SA, Role, RoleBinind들이 서로 간에 1:1 관계 뿐만 아니라, 1:N, N:N 관계도 맺을 수 있도록 하려고 한 것이 목적이지 않을까 싶다.

 

참고로 Role과 RoleBinding의 파생품으로 ClusterRole과 ClusterRoleBinding이 존재한다. 이름에서도 유추할 수 있다시피 ClusterRole과 ClusterRoleBinding는 '클러스터'라는 키워드가 들어가는 것처럼 클러스터 단위의 권한을 정의할 때 사용한다. 일례로, PV(Persistent Volume)의 경우 네임스페이스에 종속적인 리소스 오브젝트가 아니기 때문에 만약 PV 관련 권한을 설정해주려고 한다면 ClusterRole과 ClusterRoleBinding을 이용해야 한다. 하지만 그렇다고 해서 ClusterRole과 ClusterRoleBinding이 네임스페이스에 종속적인 파드나 디플로이먼트와 같은 것들에 대한 권한을 설정할 수 없는 것은 아니다. 보통 여러 네임스페이스에서 반복적으로 사용되는 권한을 클러스터 롤로 만들어 재사용하기도 한다.

3-1. SA에 부여할 권한을 정의하자: Role, ClusterRole

그러면 이제 SA에 부여할 권한을 정의하는 Role과 ClusterRole 리소스 오브젝트를 생성하는 예시 매니페스트를 살펴보자. 먼저 Role이다.

 

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: zedd-default
  name: service-reader-role
rules:
  - apiGroups: [""]
    resources: ["services"]
    verbs: ["get", "list"]

 

직전에 언급했다시피 Role은 네임스페이스에 종속적인 리소스 오브젝트이기 때문에 metadata.namespace 항목에 해당 Role이 속할 네임스페이스를 명시해준다. 그리고 rules 항목에 3가지 항목을 정의해주면 된다.

 

• apiGroups: 어떠한 API 그룹에 속하는 리소스 오브젝트에 대해 권한을 지정할지를 설정함. 이 API 그룹이라는 것에 대해서는 이전 CRD 포스팅에서 살펴본 것과 같은 개념임. 위 예시에서 services 리소스 오브젝트의 경우, 코어 API 그룹에 속하기 때문에 "" 로 명시했음. 어떤 리소스 오브젝트들이 어떤 API 그룹에 속하는지 보고 싶다면 kubectl api-resources 명령어로 볼 수 있음
• resources: 어떠한 쿠버네티스 오브젝트에 대한 권한을 정의할 것인지를 명시. 이 또한 kubectl api-resources 명령어로 볼 수 있음
• verbs: 이 롤을 부여받은 SA가 명시한 resources에 대해서 어떤 동작을 수행할 수 있을지 명시. 위 예시에서는 get, list를 명시. 참고로 이 항목에는 와일드카드(*)를 사용할 수 도 있고 특정 리소스에 한정된 기능을 사용할 때 서브 리소스(ex. pods/exec)를 명시할 수도 있음

다음은 ClusterRole 매니페스트이다.

 

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: nodes-reader-cluster-role
rules:
  - apiGroups: [""]
    resources: ["nodes"]
    verbs: ["get", "list"]

 

매니페스트 내용은 Role과 거의 비슷하다. 다만, ClusterRole은 네임스페이스에 종속적이지 않기 때문에 metadata.namespace 항목이 없는 것이 차이점이다.

 

클러스터 롤의 추가적인 내용에 대해서 하나만 더 살펴보자. 클러스터 롤은 여러 개를 조합해서 사용할 수도 있다. 즉, 자주 사용되는 클러스터 롤이 있다면 다른 클러스터 롤에 포함시켜서 재사용할 수도 있다. 이러한 기능을 '클러스터 롤 aggregation'이라고 한다. 이를 위한 매니페스트를 하나 살펴보자.

 

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: parent-cluster-role
  labels:
    rbac.authorization.k8s.io/aggregate-to-child-clusterrole: "true"
rules:
  - verbs: ["get", "list"]
    resources: ["nodes"]
    apiGroups: [""]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: child-cluster-role
aggregationRule:
  clusterRoleSelectors:
    - matchLabels:
        rbac.authorization.k8s.io/aggregate-to-child-clusterrole: "true"
rules: []

 

먼저 parent-cluster-role 이라는 이름의 클러스터 롤을 정의했는데, metadata에 labels 항목을 설정했다. 이제 쿠버네티스에 많이 익숙해지신 분들이면 저 'labels' 항목만 보더라도 "아 이 labels로 또 어딘가에서 라벨 셀렉터를 쓰겠구만" 이라고 예상할 수도 있을 것이다. 그 예상이 맞다. 

 

해당 labels는 아래의 child-cluster-role 이름의 클러스터 롤을 정의할 때 사용되며, aggregationRule.clusterRoleSelectors.matchLabels 항목에서 사용된다. 그래서 위 매니페스트에서 child-cluster-role 이라는 클러스터 롤은 rules 항목에 아무것도 명시하지 않았지만 aggregationRule로 인해 parent-cluster-role 이라는 클러스터 롤의 권한들을 상속받을 수 있게 된다.

3-2. SA와 권한을 연결하자: RoleBinding, ClusterRoleBinding

SA도 정의했고, SA에 부여할 권한인 롤도 정의했다. 그러면 이제 이 두 개를 연결시켜주기만 하면 된다. 이를 위해 RoleBinding과 ClusterRoleBinding 매니페스트 예시를 살펴보자. 먼저 RoleBinding이다.

 

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: zedd-default
  name: service-reader-role-binding
subjects:
  - kind: ServiceAccount
    name: zedd-default-sa
    namespace: zedd-default
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: service-reader-role

 

우리가 주목할 부분은 subjects와 roleRef이다. 

 

• subjects : 권한을 부여할 대상이 어떤 SA인지를 명시
• roleRef: subjects에 명시한 SA에 어떤 권한 즉, 어떤 Role을 부여할 것인지 명시. 이 때의 Role은 [목차 3-1]에서 생성한 Role임

다음은 ClusterRoleBinding 매니페스트이다. 내용은 RoleBinding 매니페스트 형식과 동일하다.

 

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: nodes-reader-cluster-role-binding
subjects:
  - kind: ServiceAccount
    name: zedd-default-sa
    namespace: zedd-default
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: nodes-reader-cluster-role

4. 쿠버네티스 API 서버에 접근하기

이번 목차에서는 쿠버네티스의 컨트롤 플레인 중 kube-apiserver로 접근하는 여러가지 방법에 대해 알아보자. kube-apiserver는 쿠버네티스의 핵심 컴포넌트 중 하나로, 사용자가 kubectl 명령어를 요청하거나 쿠버네티스 클러스터 내부에서 운영 중인 파드와 같은 다양한 리소스 오브젝트들이 Watch API를 이용한다거나 etcd에서 메타 정보를 가져오거나 하기 위해서 API 요청을 전송하는 곳이다. 

 

이런 kube-apiserver에 접근하기 위해서 kubectl 명령어를 사용할 때는 직전 목차에서 알아본 .kube/config 파일의 내용을 이용하거나 사전에 생성해둔 SA 리소스 오브젝트를 --as 옵션과 함께 이용했었다. 하지만 만약 쿠버네티스 클러스터 내부 또는 외부의 애플리케이션이 kube-apiserver에 접근을 수행하는 상황이라면 이러한 접근 방식이 적절하지 않을 수 있다.

 

따라서 이번 목차에서는 애플리케이션에서 kube-apiserver로 접근하는 대표적인 3가지 방법에 대해 알아보려고 한다.

4-1. SA의 Secret 리소스 오브젝트를 이용해 접근하자!

먼저 kube-apiserver도 HTTP 요청을 통해서 쿠버네티스의 기능을 사용할 수 있도록 REST API를 제공하고 있다. 이 엔드포인트는 만약 kubeadm인 경우 쿠버네티스 마스터 노드의 IP와 6443 포트로, GKE나 kops의 경우라면 443 포트로 접근할 수 있다. 참고로 해당 엔드포인트는 반드시 HTTPS 요청만 처리할 수 있으며, 스스로 사인한 self-signed 인증서를 사용한다는 점에 유의해야 한다. 

 

이러한 엔드포인트에 접근하기 위해서 SA의 secret을 이용할 수 있다. SA를 생성하면 기본적으로 secret 리소스 오브젝트가 같이 생성된다. 이 secret은 해당 SA를 증명하기 위한 수단으로 사용된다. 어떤 애플리케이션이 해당 SA의 secret을 사용해서 kube-apiserver에 접근한다라고 한다면 구조도는 다음과 같아진다.

 

애플리케이션이 k8s 클러스터 내부/외부에 있을 경우

 

위 구조에서 애플리케이션 서버가 kube-apiserver에 접근을 수행할 때는 구체적으로 JWT(Json Web Token) 인증을 사용하게 된다. 그래서 애플리케이션 서버는 kube-apiserver로 REST API 요청을 보낼 때, Secret에 저장된 token의 데이터를 함께 담아서 보내면 "해당 애플리케이션은 "zedd" 라는 SA를 사용해서 자격을 증명했습니다" 라고 전달하는 셈이다. REST API를 요청하는 curl 명령어 예시는 다음과 같다. 만약 default 네임스페이스에 존재하는 서비스 리소스 오브젝트들 목록을 보려면 아래처럼 수행하면 된다. 이 때 헤더에 담는 토큰은 base64로 인코딩된 상태에서 디코딩한 값으로 설정해주어야 한다.

 

# kubeadm으로 설치한 경우
curl https://$MASTER_NODE_IP:6443/api/v1/namespaces/default/services \
-k \
-H "Authorization: Bearer $DECODED_TOKEN"

 

하지만 이러한 방법은 secret의 토큰을 수동으로 디코딩해주고, REST API 요청 시 페이로드 부분에 토큰 값을 직접 담아줘야하는 등 여러가지 불편한 점이 존재한다.

4-2. 클러스터 내부에서 kubernetes 서비스 이용해 접근하기!

이번엔 쿠버네티스 클러스터 내부의 애플리케이션이라고 한정했을 때, [목차 4-1] 방법처럼 토큰 값을 수동으로 설정해주지 않고 자동으로 애플리케이션이 kube-apiserver에 접근할 수 있는 방법에 대해 알아보도록 하자. 

 

이를 위해서 쿠버네티스에서 기본적으로 생성해둔 default 네임스페이스의 kubernetes 라는 이름의 ClusterIP 타입의 서비스 리소스 오브젝트를 이용하는 것이다. 즉, 파드들은 이 kubernetes 라는 이름의 서비스를 이용해서 kube-apiserver로 접근을 수행한다는 것이다. 이 때, 파드가 kubernetes 서비스로 통신할 때 명시하는 도메인은 이전 포스팅에서 배웠던 클러스터 통신 도메인인 FQDN을 이용하면 된다.

 

 

그런데 이 때, 파드는 단순히 kubernetes 라는 서비스로 접근하는 것으로만 kube-apiserver로 요청한 모든 기능들을 사용할 수 있을까? 아니다. 이 때도 [목차 4-1]때 처럼 파드에 "어떤 SA"의 시크릿 값을 HTTP 요청에 담아 보내주어야 한다. 그래야 "어떤 SA"에 바인딩된 Role에 정의된 권한들에 한하여 kube-apiserver로 요청한 뒤 정상 응답을 받아낼 수 있다. 

 

그렇다면 여기서 "어떤 SA"라는 것은 무엇일까? 파드가 생성될 때 매니페스트에 특별한 SA를 명시해주지 않았다면 기본적으로 "어떤 SA"의 시크릿을 파드 내부에 마운트하게 된다. 이 "어떤 SA"는 바로 default 라는 네임스페이스의 'default' 라는 이름을 가진 SA를 뜻한다. 실제로 파드를 생성한 뒤, describe를 해보면 Containers.Mounts 항목에 아래와 같은 경로의 디렉토리가 마운트되어 있음을 볼 수 있다.

 

/var/run/secrets/kubernetes.io/serviceaccount

 

해당 디렉토리에 가면 아래와 같은 파일들이 심볼릭 링크 형태로 존재하는 것을 볼 수 있다.

 

/var/run/secrets/kubernetes.io/serviceaccount 경로 내에 존재하는 파일들

 

그래서 만약 파드에서 kube-apiserver로 접근하려면 해당 경로에 있는 token 이라는 이름의 파일에 저장된 내용을 읽어와서 kubernetes 이름의 서비스로 요청하면 된다. 

 

파드에 마운트되는 Secret의 토큰을 이용해 kubernetes 서비스에 접근

 

참고로 파드가 기본적으로 사용하는 default 라는 이름의 SA 말고 내가 사전에 별도로 생성한 SA를 사용하게끔 하고 싶다면 파드 매니페스트에서 spec.serviceAccountName 항목에 SA 이름을 작성해주면 된다.

4-3. 쿠버네티스 SDK를 이용해 접근하기!

쿠버네티스 클러스터 내부 애플리케이션에서 접근한다고 한정했을 때, 이번에는 특정 프로그래밍 언어로 바인딩된 쿠버네티스 SDK(ex. pypi kubernetes)를 이용해서 kubernetes 서비스에 접근하는 것이다. 이는 [목차 4-2]와 동일한 구조이되, kubernetes 서비스로 접근할 때 특정 언어로 바인딩된 SDK를 사용하는 것만이 차이점이다. 

 

 

Python 언어로 바인딩된 SDK를 사용할 때 아래의 소스코드를 항상 볼 수 있다.

 

from kubernetes import config

config.load_incluster_config()

 

위 load_incluster_config() 메소드를 호출하게 되면 아까 [목차 4-2]에서 보았던 파드 내부에 마운트된 "/var/run/secrets/kubernetes.io/serviceaccount" 라는 경로에 존재하는 파일들을 읽어들여 kube-apiserver로의 인증, 인가 작업을 수행하고 SDK가 내부적으로 kubernetes 이름의 서비스로 요청을 수행한다. [목차 4-2]때와 다른 점이라고 한다면 소스코드 레벨에서 FQDN을 명시적으로 정의해서 요청하지 않는다는 점이 다르다.

5. SA로 사설(Private) 이미지 레지스트리 접근하기

이번 목차에서는 SA를 활용해서 사설 이미지 레지스트리에 접근하는 방법에 대해 알아보자. 이전 포스팅에서 docker-registry 라는 유형의 시크릿을 생성하고, 해당 시크릿을 디플로이먼트나 파드 매니페스트의 imagePullSecrets 항목에 명시하면 해당 디플로이먼트 또는 파드가 해당 시크릿을 이용해서 사설 이미지 레지스트리에 접근할 수 있다는 것을 살펴보았다. 하지만 이 방법은 사설 이미지 레지스트리에 접근하려는 모든 디플로이먼트 또는 파드의 매니페스트 마다 매번 imagePullSecrets 항목에 시크릿을 정의해야 했었다.

 

이런 번거로움을 SA를 사용하면 해결할 수 있다. SA에 docker-registry 타입의 시크릿을 한 번 설정해놓은 뒤, 사설 이미지 레지스트리에 접근하려는 모든 디플로이먼트와 파드들은 단지 해당 SA만 사용하도록 설정해주면 된다. SA에 docker-registry 타입의 시크릿을 설정하는 방법은 다음과 같다.

 

apiVersion: v1
kind: ServiceAccount
metadata:
  name: private-registry-sa
  namespace: zedd-ns
imagePullSecrets:
  - name: registry-auth

 

위 매니페스트에서 registry-auth 라는 시크릿은 docker-registry 타입으로, 미리 생성해놓은 시크릿의 이름이다. 참고로 [목차 4-2]에서 배운 것처럼, 별다른 설정을 하지 않았을 때 파드가 기본적으로 사용하는 default 라는 이름의 SA에 시크릿을 사용하도록 설정할 수도 있다.

6. kubeconfig 파일에 SA 인증 정보를 설정해서 k8s 클러스터에 접근하기

이번에 배울 내용은 [목차 2번]에서 살펴본 kubeconfig 파일 즉, (별도 설정하지 않았다면) ~/.kube/config 경로의 파일에다가 쿠버네티스 SA 인증 정보를 설정한 뒤, 해당 SA 인증 정보를 가지고 k8s 클러스터에 접근하는 방법이다.

(참고로 kubeconfig 파일은 별도로 설정하지 않으면 ~/.kube/config 경로에 기본적으로 존재하지만, 환경변수인 KUBECONFIG 라는 값에 다른 경로를 설정해서 kubeconfig 파일이 해당 경로에 저장되게 할 수도 있다)

 

그런데 원론적으로 돌아가서 왜 kubeconfig 파일에 굳이 SA 인증 정보를 설정하는 걸까? 그냥 기본적으로 설정되어 있는 관리자 권한을 갖는 인증서 정보로 하면 안될까? 물론 안되는 것은 아니지만, 보통 k8s 클러스터에는 다양한 직무의 개발자가 접근하며, 각 개발자의 역할이 각기 서로 다르다. 이렇게 됨에 따라 자연스레 개발자의 직무나 역할에 따라 k8s 클러스터에 접근해서 할 수 있는 권한들을 제한할 필요가 있다. 이렇게 개발자 즉, 일종의 쿠버네티스를 사용하는 클라이언트 마다 권한을 다르게 주기 위해서 권한이 제한된 SA를 kubeconfig에 설정하게 된다.

 

kubeconfig 파일에 SA를 설정하기 전에 kubeconfig 파일에 작성되어 있는 내용에 대해서 좀 더 디테일하게 이해할 필요가 있다. [목차 2번]에서는 잠깐 소개하는 정도로만 했기 때문에 이번 목차에선 좀 더 디테일하게 알아보자. 우선 kubeconfig 예시 파일을 하나 살펴보자.

 

kubeconfig 파일 내용 예시

 

kubeconfig 파일은 크게 3가지 부분으로 구성되어 있다. 

 

• clusters: 접속할 쿠버네티스 API 서버의 목록. 위에는 1개의 API 서버만 존재하지만, 원한다면 더 추가할 수도 있음
• users: 쿠버네티스 API 서버로 접속하기 위한 사용자 인증 정보 목록. 해당 항목에 SA의 토큰을 입력할 수도 있고, 쿠버네티스에서 사용되는 루트 인증서로부터 발급받은 하위 인증서의 데이터를 입력할 수도 있음
• contexts: clusters 항목에 있는 하나의 cluster 와 users 항목에 있는 하나의 user를 조합해서 최종적으로 쿠버네티스 클러스터의 정보를 설정. 즉, 실질적으로 쿠버네티스 클러스터로 접근할 때는 이 컨텍스트라는 것 1개를 선택해서 접근함. '조합'이라는 단어에서 유추할 수 있듯이 M개의 cluster 항목과 N개의 user 항목이 있다면 이를 서로 모두 조합해서 컨텍스트를 만들 수 있음

만약 여러 개의 컨텍스트를 사용하게 되면 언제는 내가 로컬에서 구축한 쿠버네티스 클러스터로 접근하고, 또 언제는 회사의 원격 쿠버네티스 클러스터에 접근할 수도 있다.

 

이제 kubeconfig 파일의 내용을 수정해서 특정 SA를 설정한 뒤, 쿠버네티스 클러스터에 해당 SA의 권한으로 접근해보도록 하자. kubeconfig 파일도 어쨌건 텍스트 형태의 파일이기 때문에 vim이나 nano, IDE와 같은 에디터로 직접 수정할 수도 있긴 하지만 kubectl config 계열의 명령어로도 수정할 수 있다. 만약 유저를 하나 추가하는 명령어를 수행한다고 하면 예시는 아래와 같다.

 

kubectl config set-credentials $USER_NAME --token=$DECODED_TOKEN

 

$DECODED_TOKEN 이라는 변수 값에는 추가하려는 SA에 설정된 시크릿의 Token의 base64 디코딩한 값을 명시하면 된다. 그런데 이렇게 하고 끝일까? 아니다. 위에서 설명했지만 실질적으로 쿠버네티스 클러스터에 접근할 때 사용하는 항목은 'context' 라고 했다. 이제 우리는 새로운 유저를 추가해주었으니, 이 추가한 유저가 어떤 쿠버네티스 클러스터에 접근할 것인지 명시하는 컨텍스트를 만들어 줄 차례다. 이 또한 kubectl config 명령어로 생성이 가능하다. 예시는 아래와 같다.

 

kubectl config set-context $NEW_CONTEXT_NAME --cluster=$CLUSTER_NAME --user=$USER_NAME

7. k8에서의 User 와 Group

쿠버네티스에서는 SA 외에도 User와 Group 이라는 개념이 존재한다. User는 말 그대로 쿠버네티스를 사용하는 실제 사용자를 뜻하며 User 1개 당 사용자 1명 정도로(물론 실제 사람 1명을 의미하는 것은 아님)생각하면 쉽다. 그리고 Group은 이 User 여러 개를 모아 놓은 집합을 의미한다. 실제로 이 User, Group도 롤 바인딩 또는 클러스터 롤 바인딩 매니페스트의 subjects 항목에 SA 처럼 명시할 수 있다. 아래 매니페스트는 실제 쿠버네티스 공식 문서에서 RoleBinding 내용을 설명할 때 사용하는 예시 중 하나이다.

 

apiVersion: 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

 

그런데 여기서 헷갈리는 점이 있다. SA는 그럼 User와 Group 개념과 어떤 차이가 있는 걸까? 사실상 SA도 최종적으로는 User 개념에 속한다. 이에 대한 근거로, 특정 리소스 및 액션에 대한 권한이 없는 SA인데, 그 권한을 취하려고 한다면 kube-apiserver는 다음과 같은 에러 응답을 내뱉게 된다.

 

Error from server (Forbidden): pods is forbidden: User "system:serviceaccount:default:zedd-sa" cannot list resource "pods" in API group "" in the namespace "default"

 

위 메세지는 zedd-sa 라는 이름의 SA가 default 라는 네임스페이스의 파드에 대해서 목록을 출력하는 list 권한이 없다는 의미이다. 이 때 주목할 부분은 에러 메세지 속 'User' 라고 되어 있는 부분이다. 분명 우리는 SA를 이용해 권한을 취하려고 했는데 kube-apiserver는 이 SA를 보고 'User'라고 표현하고 있다. 즉, 이 SA도 일종의 User인 셈이고, 그 User 이름이 'system:serviceaccount:default:zedd-sa' 가 되는 것이다. 실제로 롤 바인딩에 해당 User 이름을 "kind: User" 라는 것을 이용해 명시할 수 있다.

 

...(RoleBinding 매니페스트 생략)...
subjects:
- kind: User
  name: system:serviceaccount:default:zedd-sa
  namespace: default
roleRef:
(... 생략 ...)

 

그러면 Group은 저 User 이름에서 어떤 부분을 지칭할까? 그림으로 표현하면 아래와 같다.

 

 

이 예시에서는 Group은 총 2개를 지칭할 수 있는데, 첫 번째는 system:serviceaccount 이다. 이 Group은 모든 네임스페이스에 속하는 모든 서비스 어카운트가 속해 있는 그룹을 의미한다. 두 번째인 system:serviceaccount:default 라는 Group은 default 라는 네임스페이스에 속하는 모든 서비스 어카운트가 속해 있는 그룹을 의미한다. 

 

이러한 Group들은 클러스터 롤 바인딩에 아래와 같이 명시될 수 있다.

 

# docs: https://kubernetes.io/docs/reference/access-authn-authz/rbac/#clusterrolebinding-example
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

 

system 이라는 접두어로 시작하는 것들은 쿠버네티스가 기본적으로 미리 정의해 둔 유저나 그룹들이다. 이러한 대표적인 예시들로는, API 서버의 인증에 성공한 그룹을 의미한 system:authenticated, 인증에 실패한 그룹인 system:unauthenticated, 인증에 실패한 유저를 의미하는 system:anonymous 등이 있다. 참고해서 알아두도록 하자.

 

이렇게 쿠버네티스가 기본적으로 정의해둔 유저와 그룹을 사용하면 되긴 하지만, 오로지 이것만 사용해야 하는 것은 아니다. 각자의 조직에 맞게 커스텀하게 유저와 그룹을 구성할 수 있다. 예를 들어, kubeconfig 파일에 기본적으로 설정되어 있는 인증 방법인 x509 인증서를 사용하거나 별도의 인증 서버인 깃허브 계정, 구글 계정, LDAP 데이터 등을 쿠버네티스 사용자 인증에 사용할 수도 있다.

 

참고로 별도의 인증서버라 함은 보통 OAuth의 OIDC를 이용한 Dex나 단순 토큰을 이용해 웹훅 인증 시스템을 구현하는 Guard 등이 있다.