[CKA] 42. service account

개요

k8s에는 2개의 계정분류가 존재합니다. 

 

1. user account

- 사람이 k8s관리는 위해서 사는 계정

2. service account

- k8s service가 k8s에 무언가 요청을 하기 위해서 사용하는 게정

 

위 두 종류 계정 중. user account은 지난번 Post([CKA] 38. k8s에서 사용자 추가 및 권한 제어)를 참고하시면 되시고요. 

이번 Post에서는 service account가  무엇인지 살펴보겠습니다.

용도

K8s의 Service Account는 주로 Pods, system components 등이 Kubernetes API와 상호작용할 때 사용하는 계정입니다.

그러면 이제부터 Service Account에 대하여 상세하게 알아보겠습니다.

개념

Service Account는 API Server에서 Service Account Object로 존재합니다.

그리고 Service Account는 기본적으로 모든 namespace마다 1개씩 "default"라는 이름의 Service Account를 갖습니다.

 

k8s get sa -A 경과에서 default만 추출 현 결과입니다.

실제로 1개씩 존재하는 것을 확인할 수 있습니다.

이 "default" service account는 사용자가 pod를 생성할 때 service account를 명시해 주지 않았다면 pod에 기본적으로 할 당되는 service account 이기도 합니다. 어떻게 생겼는지 궁금함으로 한번 봐보겠습니다. 

 

kubectl describe sa default -n default

뭔가 들어있을 줄 알았는데 놀랍게도 아무런 정보도 없네요.

 

다음은 k8s에서 제공하는 Service account와 User Account에 대한 설명입니다. 계정이 두 종류가 있으니 헷갈리지 말라고 넣어놓은 것 같습니다. 

https://kubernetes.io/docs/concepts/security/service-accounts/

설명	Service Account	User of Group
위치	Kubernetes API(Service Account Object)	External User 같은경우 외부에 인증서 형태로 존재.
접근 제어	Kubernetes RBAC or other authorization mechanisms	Kubernetes RBAC or other identity and access management mechanisms
사용 목적	Workloads, automation	People
인증방법	Token	인증서

사용 방법

아래와 같은 순서로 사용하면 됩니다. 

 

1. Service Account 생성

2. Token 생성

3. RBAC와 같은 인증 메커니즘을 사용하여 ServiceAccount 개체에 권한을 부여

4. Pod 생성 시 ServiceAccount 객체를 할당

Service Account 생성

2가지 방법으로 생성이 가능합니다. 명령 또는 yaml

명령

kubectl create serviceaccount my-service-account --namespace default

yaml

my-service-account.yaml

apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-service-account
  namespace: default

 

kubectl apply -f  my-service-account.yaml

Token생성

service account는 token을 사용하여 인증처리를 진행합니다. 그래서 token을 만들고 service account에 연결해 주어야 합니다.

token관련 변경사항

Kubernetes 1.24부터 ServiceAccount를 생성할 때 자동으로 토큰이 생성되지 않으므로 수동으로 생성해야 한다.

https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.24.md#no-really-you-must-read-this-before-you-upgrade

token 생성의 2가지 방법

Secret Object

장기간 token을 사용하고 싶을 때 사용. 그러나 보안상 취약 함으로 추천하지 않습니다.
https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#manually-create-a-long-lived-api-token-for-a-serviceaccount

apiVersion: v1
kind: Secret
metadata:
  name: build-robot-secret
  annotations:
    kubernetes.io/service-account.name: my-service-account
type: kubernetes.io/service-account-token

TokenRequest API

TokenRequest API를 사용하여 수명을 가진 token을 생성하는 방법입니다. 그리고 token은 수명이 다하면 자동으로 회전을 합니다.  TokenRequest API는 다음 명령으로 생성이 가능합니다

 

kubectl create token [serviceaccountname] --namespace [namespace]

kubectl create token my-servcei-account --namespace default

 

참고 : kubectl create token에 대한 --duration 명령줄 인수를 사용하여 특정 토큰 기간을 요청할 수 있습니다(발행된 토큰의 실제 기간은 더 짧을 수도 있고 더 길 수도 있습니다).

 

제약 사항 : 이 API를 사용하려면 쿠버네티스 클러스터가 Service Account Token Volume Projection 기능을 지원해야 합니다. (k8s v1.12 부터 지원)

Service Account Pod에 적용

nginx에 yaml에 serviceAccountName를 사용하여 service account를 추가하는 yaml입니다.

nginx.yaml

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
spec:
  containers:
  - name: nginx
    image: nginx:1.14.2
  serviceAccountName: my-service-account

 

아래는 kubectl get pod nginx-pod -o yaml로 보았을 때 spec에 적힌 부분입니다. 

Service Account와 RBAC 

service account를 RBAC과 연결하여 user처럼사용 하는 방법입니다.

sa 생성

apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-service-account
  namespace: default

token 생성 

# TokenRequest API를 사용하여 토큰 생성
SECRET_NAME=$(kubectl create token my-service-account)

 

참고 ; kubectl create token에 대한 --duration 명령줄 인수를 사용하여 특정 토큰 기간을 요청할 수 있습니다(발행된 토큰의 실제 기간은 더 짧을 수도 있고 더 길 수도 있습니다).

kubeconfig에 user 추가

kubectl config set-credentials myserviceaccount --token=$SECRET_NAME

role 생성

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader-for-service-account
rules:
- apiGroups: [""] # "" indicates the core API group
  resources: ["pods"]
  verbs: ["*"]

role binding 생성

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods-for-service-account
  namespace: default
subjects:
- kind: ServiceAccount 
  name: my-service-account # "name" is case sensitive
  namespace: default 
roleRef:
  kind: Role
  name: pod-reader-for-service-account
  apiGroup: rbac.authorization.k8s.io

테스트

kubectl get pod --user my-service-account

 

참고 

kubectl 명령어에서 --as와 --user 옵션은 다음과 같은 차이점이 있습니다:

--as 옵션

• 가장(Impersonation)을 위한 옵션입니다. 이 옵션을 사용할 때, 현재 인증된 사용자(또는 ServiceAccount)는 지정된 다른 사용자나 ServiceAccount를 가장합니다.
• 이는 현재의 인증 정보를 유지하면서 다른 사용자의 권한으로 쿠버네티스 API를 호출할 수 있게 합니다.
• 사용자 가장은 쿠버네티스 RBAC에서 특정 사용자에게 다른 사용자를 가장할 수 있는 권한이 있어야 사용할 수 있습니다

--user 옵션:

• kubeconfig 파일에서 사용자를 지정하기 위한 옵션입니다. 여기서 사용자는 일반적으로 인증서, 토큰, 사용자 이름/비밀번호 등을 포함한 인증 정보를 가지고 있습니다.
• 이 옵션을 사용하여 특정 사용자(또는 ServiceAccount)로 kubectl 명령을 실행하고자 할 때 사용합니다.
• --user 옵션으로 지정된 사용자는 kubeconfig 파일에 정의되어 있어야 하며, 해당 사용자에게 적절한 권한이 부여되어 있어야 합니다.

간단히 말해서, --as는 현재 사용자가 다른 사용자의 권한을 가지고 작업을 수행하려고 할 때 사용되고, --user는 kubeconfig에서 정의된 다른 사용자의 인증 정보로 명령을 실행할 때 사용됩니다. --as 옵션은 주로 관리자나 개발자가 다른 사용자의 권한을 테스트하거나 확인할 때 사용되며, --user 옵션은 일반적으로 다른 인증 컨텍스트를 사용할 때 사용됩니다.

정리

k8s 2계의 계정 분류가 존재합니다. 

1. user account

- 사람이 k8s관리는 위해서 사는 계정

2. service account

- k8s service가 k8s에 무언가 요청을 하기 위해서 사용하는 게정

 

각 계정 별 차이점

설명	Service Account	User of Group
위치	Kubernetes API(Service Account Object)	External User 같은경우 외부에 인증서 형태로 존재.
접근 제어	Kubernetes RBAC or other authorization mechanisms	Kubernetes RBAC or other identity and access management mechanisms
사용 목적	Workloads, automation	Peop
인증방법	Token	인증서

Next Post

[CKA] 43. k8s 각종 보안 (image, securityContext)