[Kubernetes] 쿠버네티스 오브젝트 [ServiceAccount]

ServiceAccount

ServiceAccount

 

ServiceAccount는 RBAC(Role Base Acccess Control)을 기반으로 사용자 또는 애플리케이션에게

 

특정 명령을 실행할 수 있는 권한을 부여해주는 오브젝트이다.

 

ServiceAccount는 무엇을 해주나

위에 써놓았듯이 ServiceAccount는 RBAC이므로, AWS의 IAM 방식과 상당히 비슷하다.

 

https://imsongkk.tistory.com/73

[AWS] IAM과 Role, Policy

 

해당 포스트에서 들었던 예시처럼, 쿠버네티스 클러스터도 여러명의 사용자와 사용자 그룹이 사용할 수 있다.

 

이때 사용자와 그룹마다 권한을 다르게 두어 클러스터 리소스를 안전하게 제어할 수 있어야 한다.

 

보통 쿠버네티스 클러스터를 제어할 때 kubectl 명령어를 사용하는데,

 

해당 명령어는 알맞게 파싱된 이후 kube-apiserver로 전달된다.

 

kube-apiserver는 해당 요청을 보낸 사람이 누구인지(인증), 어떤 권한을 가진지(인가) 과정을 거쳐 

 

해당 요청을 처리한다. 이때 사람이라고 해놓은 부분이 ServiceAccount에 해당된다.

 

그런데 우리는 지금껏 ServiceAccount에 대해 하나도 몰랐음에도 불구하고 kubectl 명령어를 잘만 사용해 왔다.

 

이는 kubectl이 참조하는 config 파일에 Admin 권한을 가지는 인증서가 기본적으로 매핑되어있기 때문이다.

 

Role과 ClusterRole

Admin 권한은 다시 말해 Admin Role이다.  Admin Role에는 어떤 권한들이 있을까?

 

 

를 살펴보기전에, 명령어를 잘 보면 role이 아닌 clusterrole임을 볼 수 있다.

 

role은 네임스페이스에 종속된 오브젝트로, 네임스페이스안에 속한 오브젝트들을 관리할 권한을 정의한다.

 

clusterrole은 네임스페이스에 종속되지 않는 오브젝트로, 

 

네임스페이스안에 종속되지않는 오브젝트들 뿐만 아니라 클러스터 전체에 유효한 오브젝트들을 관리한다.

 

클러스터를 관리하는 Admin 권한은 네임스페이스가 아니라 클러스터 전체에 유효해야 하므로 clusterrole로 정의됐다.

 

다시 돌아와서,

 

rules 하위에 apiGroups와 resources, verbs가 보인다.

 

apiGroups는 API 그룹에 속하는 어떤 오브젝트에 대해 권한을 지정할지를 설정한다.

 

apiGroup에 대해서는 Pod를 알아보면서 정리했었다.

 

 

https://imsongkk.tistory.com/63

[Kubernetes] 쿠버네티스 오브젝트 [Pod]

 

" " 으로 설정된 apiGroup은 core 그룹에 속한 APIVERSION이 v1인 기본 api resource들을 의미한다.

 

resources는 해당 apiGroup에 속하는 리소스를 뜻하며

 

verbs는 해당 Role을 가진 대상이 해당 리소스에 대해 수행할 수 있는 동작을 명시한다.

 

Role Binding

Role은 역할을 정의만 해놓은 오브젝트일뿐, 특정 대상에게 명시적으로 부여해야 한다.

 

Role Binding 오브젝트는 이를 도와주는 쿠버네티스 오브젝트이다.

 

Role Binding을 사용해서 Role을 ServiceAccount에 부여해보자.

 

apiVersion: rbac.authorization.k8s.io/v1
kind: Rolebinding
metadata:
  name: test-rolebinding
  namespace: default
subjects:
- kind: ServiceAccount
  name: imsongkk
  namespace: default
roleRef:
  kind: Role
  name: my-role
  apiGroup: rbac.authorization.k8s.io

 

미리 만들어둔 my-role이라는 role을 imsongkk라는 ServiceAccount에 binding 해주었다.

 

AWS IAM처럼 Role과 ServiceAccount는 1:1이 아닌 N:M 관계를 가진다.

 

ServiceAccount를 정의하는 YAML

apiVersion: v1
kind: ServiceAccount
metadata:
  name: imsongkk
  namespace: default
imagePullSecrets:
- name: my-registry-secret

imsongkk라는 이름을 가지는 ServiceAccount를 정의한다.

 

imagePullSecrets는 아래에서 다시 다루겠다.

 

클러스터 내부에서는 api-server에 어떻게 접근할까?

우리가 입력했던 kubectl 명령어는 사실 default라는 ServiceAccount의 자격증명으로 실행됐다.

kubectl get pods
kubectl --as system:serviceaccount:default:default get pods

둘은 동일한 결과를 출력한다.

 

kube-apiserver는 인증과 인가 로직을 가지고 있다고 앞에서 말했었다.

 

따라서 default ServiceAccount는 따로 인증 정보(token)를 가지고 있어야 kube-apiserver와 통신할 수 있을것이다.

 

이 인증정보는 어디에 있을까?

 

쿠버네티스는 ServiceAcocunt를 위한 인증 정보를 Secret에 저장한다.

 

ServiceAccount를 생성하면 쿠버네티스는 자동으로 Secret을 생성해준다!

 

였으나 1.25 버전 이후로는 보안을 위해 자동으로 만들어주지 않고 수동으로 Secret을 생성해줘야 한다.

 

default ServiceAccount에는 Token 정보가 없다. 하지만 kubeconfig에 있는 인증서 파일로 api-server와 통신이 가능하다.

 

다시다시, Token 정보가 있다고 가정해보자.

 

api-server도 마스터 노드에 Pod형태로 존재하므로 IP가 있을것이다.

 

ServiceAccount나 다른 Pod들은 api-server에 어떻게 접근할 수 있을까?

 

쿠버네티스는 api-server에 접근할 수 있는 kubernetes라는 ClusterIP 타입의 서비스를 미리 생성해둔다.

 

또한, Pod나 Deployment같은 리소스를 생성할 때 해당 ServiceAccount의 Secret을 자동으로 마운트해준다.

 

따라서 Pod는 IP가 아닌 DNS로 api-server에 접근하며, ServiceAccount의 Token을 담아 자격증명을 할 수 있다.

 

ImagePullSecrets

ServiceAccount를 정의하는 YAML을 소개하면서 등장했다.

 

Pod를 생성할때 보통은 로컬에 있는 이미지를 사용하지 않고 외부로부터 이미지를 받아온다.

 

이때 공개 저장소가 아닌 프라이빗한 저장소라면 적절한 자격증명이 필요할것이다.

 

이는 spec에 imagePullSecrets를 추가함으로써 해결할 수 있다.

 

apiVersion: v1
kind: Pod
metadata:
  name: my-nginx-pod
spec:
  containers:
  - name: my-nginx-container
    image: nginx
    ports:
    - containerPort: 80
      protocol: TCP
  imagePullSecrets:
  - name: my-registry-secret

 

위의 Pod는 secret을 통해 나만의 사설 레지스트리에 접근해서 nginx 이미지를 가져오게 된다.

 

하지만 이런 설정 정보를 Pod나 Deployment 단이 아닌 ServiceAccount단으로 올릴 수 있다.

 

즉, imsongkk 라는 ServiceAccount가 다음과 같다면,

 

apiVersion: v1
kind: ServiceAccount
metadata:
  name: imsongkk
  namespace: default
imagePullSecrets:
- name: my-registry-secret

더 이상 Pod에 명시하지 않고도 자동으로 Pod에서 사설 레지스트리에서 접근할 수 있다.