서비스 계정

서비스 계정 (service-accounts)

Kubernetes의 ServiceAccount 객체에 대해 알아볼게요. 이 페이지는 Kubernetes의 ServiceAccount 객체를 소개하고, 서비스 계정이 어떻게 동작하는지, 사용 사례, 제한 사항, 대안, 그리고 추가 지침을 위한 리소스 링크를 제공해요.

서비스 계정이란?

서비스 계정은 Kubernetes에서 **클러스터 안의 구별된 정체성(identity)**을 제공하는 일종의 비인간(non-human) 계정이에요. 애플리케이션 파드, 시스템 컴포넌트, 그리고 클러스터 안팎의 엔티티는 특정 ServiceAccount의 자격 증명을 사용해서 그 ServiceAccount로 식별할 수 있어요. 이 정체성은...

핵심 특성은 이래요.

  • 네임스페이스 바운드: 각 서비스 계정은 Kubernetes 네임스페이스에 바인딩돼요. 모든 네임스페이스는 생성 시 default ServiceAccount를 받아요.
  • 경량: 서비스 계정은 클러스터에 존재하며 Kubernetes API에 정의돼요. 특정 작업을 활성화하기 위해 서비스 계정을 빠르게 만들 수 있어요.

| 설명 | ServiceAccount | 사용자 또는 그룹 | | 위치 | Kubernetes API (ServiceAccount 객체) | 외부 | | 접근 제어 | Kubernetes RBAC 또는 기타 권한 부여 메커니즘 | Kubernetes RBAC 또는 기타 식별·접근 관리 메커니즘 | | 의도된 용도 | 워크로드, 자동화 | 사람 |

기본 서비스 계정

네임스페이스에 파드를 배포하면서 파드에 ServiceAccount를 수동으로 할당하지 않으면, Kubernetes는 그 네임스페이스의 default ServiceAccount를 파드에 할당해요.

Kubernetes 서비스 계정의 사용 사례

  • example 네임스페이스의 파드가 kube-node-lease 네임스페이스의 Lease 객체를 읽고, 나열하고, 감시(watch)해야 하는 경우.
  • 파드가 외부 서비스와 통신해야 하는 경우. 예를 들어 워크로드 파드가 상업적으로 제공되는 클라우드 API에 대한 정체성을 요구하는 경우.

서비스 계정 사용 방법

  1. kubectl 같은 Kubernetes 클라이언트나 객체를 정의하는 매니페스트로 ServiceAccount 객체를 만들어요.
  2. RBAC 같은 권한 부여 메커니즘을 사용해 ServiceAccount 객체에 권한을 부여해요.
  3. 파드 생성 중에 ServiceAccount 객체를 파드에 할당해요.

파드에 ServiceAccount 할당하기

파드에 ServiceAccount를 할당하려면 Pod 사양의 spec.serviceAccountName 필드를 설정해요. 그러면 Kubernetes가 자동으로 그 ServiceAccount의 자격 증명을 파드에 제공해요. v1.22부터 Kubernetes는...

기본적으로 Kubernetes는 할당된 ServiceAccount의 자격 증명을 파드에 제공해요. default ServiceAccount든 내가 지정한 사용자 정의 ServiceAccount든 말이죠. 지정된 ServiceAccount 또는 default ServiceAccount의 자격 증명이 자동 주입되는 것을 막으려면 Pod 사양의 automountServiceAccountToken 필드를 false로 설정해요.

1.22 이전 버전에서 Kubernetes는 장수(long-lived) 정적 토큰을 Secret으로 파드에 제공해요.

ServiceAccount 자격 증명을 수동으로 검색하기

  • kubelet이 서비스 계정 토큰을 **프로젝티드 볼륨(projected volume)**으로 파드에 추가하도록 지시할 수 있어요. 프로젝티드 토큰은 자동으로 만료되고, kubelet은 만료 전에 토큰을 회전시켜요.
  • 서비스 계정 토큰 Secret(권장하지 않음): 서비스 계정 토큰을 Kubernetes Secret으로 파드에 마운트할 수 있어요. 이 토큰은 만료되지도 회전하지도 않아요. v1.24 이전 버전에서는 각 서비스 계정에 대해 영구 토큰이 자동 생성됐어요. 이 방식은 정적이고 장수하는 자격 증명과 관련된 위험 때문에, 특히 규모가 커질 때 더 이상 권장되지 않아요.

서비스 계정 토큰의 노드 audience 제한

ServiceAccountNodeAudienceRestriction 기능 게이트가 활성화되면 NodeRestriction 어드미션 플러그인은 kubelet이 TokenRequest API를 통해 서비스 계정 토큰을 만들 때 요청할 수 있는 audience를 제한해요. 기본적으로 kubelet은 요청할 수 있는 audience가 제한돼요.

Secrets 접근 제한 (더 이상 사용되지 않음)

참고:

  1. 파드에 볼륨으로 마운트되는 각 Secret의 이름은 파드 ServiceAccount의 secrets 필드에 나타나야 해요.
  2. 파드에서 envFrom으로 참조되는 각 Secret의 이름도 파드 ServiceAccount의 secrets 필드에 나타나야 해요.
  3. 파드에서 imagePullSecrets로 참조되는 각 Secret의 이름도 파드 ServiceAccount의 secrets 필드에 나타나야 해요.

서비스 계정 자격 증명 인증하기

ServiceAccount는 서명된 JSON Web Tokens(JWT)을 사용해서 Kubernetes API 서버와, 신뢰 관계가 존재하는 다른 시스템에 인증해요.

TokenRequest API는 ServiceAccount에 대한 **바운드 토큰(bound token)**을 생성해요. 이 바인딩은 해당 ServiceAccount로 동작하는 클라이언트(예: 파드)의 수명과 연결돼요. 바운드 파드 서비스 계정 토큰의 JWT 스키마와 페이로드 예시는 Token Volume Projection을 참고하세요.

자신의 코드에서 서비스 계정 자격 증명 인증하기

Kubernetes 프로젝트는 TokenReview API 사용을 권장해요. 이 방식은 Secret, ServiceAccount, Pod, Node 같은 API 객체에 바인딩된 토큰이 해당 객체가 삭제될 때 무효화되기 때문이에요. 예를 들어...

대안