귀찮게하기/DevOps-SRE

Pod와 ServiceAccount의 관계

게임이 더 좋아 2025. 5. 14. 22:39
반응형
728x170

 

Pod는 우리가 생각한 대로 동작함

예를 들면 Pod 는 image tag, image repo를 입력하면 image를 pulling 함

하지만 정확하게 구체적인 동작을 알지 못함

어떻게 그렇게 할 수 있는 것인지?

알아보자

 

 

Pod란

Pod는 Kubernetes에서 가장 작은 배포 단위로, 하나 이상의 컨테이너를 그룹화하여 네트워크와 스토리지를 공유하는 구조 모든 컨테이너는 공통 IP, 볼륨, 네임스페이스를 공유

  • 각 Pod는 단일 네임스페이스에 속함
  • 기본적으로 하나의 컨테이너를 포함하되, sidecar 패턴 등으로 복수의 컨테이너를 구성 가능
  • Pod가 생성될 때 자동으로 ServiceAccount와 연결됨

 

Pod를 만들 때, token을 집어넣으면 되지 않았을까?, 왜 ServiceAccount, Secret을 통해  pod에게 token을 간접적으로 전달해야 했을까?

 

Kubernetes의 설계 철학과 보안에 그 이유가 있음

 

  • 직접 토큰을 Pod에 삽입하면 사용자가 토큰의 생성, 갱신, 폐기를 직접 관리해야 함
  • Pod가 실행될 때 필요한 권한은 사람이 아닌 실행 주체에 의해 결정
  • Secret 객체는 Kubernetes의 RBAC로 접근이 제어되며, etcd에 저장될 때 암호화되어 보안이 강화
  • ServiceAccount는 Pod와 Kubernetes API 간의 인증을 추상화하여, 여러 Pod가 동일한 ServiceAccount를 공유
    • 신뢰 모델과 제어 모델을 분리
    • Token 발급과 주입이 컨트롤 플레인 레벨에서 제어

 

 

 

ServiceAccount란 무엇인가

ServiceAccount는 Pod가 Kubernetes API 서버 및 클러스터 내 리소스와 상호작용할 수 있도록 인증과 권한을 제공하는 객체

ServiceAccount는 Kubernetes의 RBAC와 연계되어 권한을 제어

Pod 연결은 spec.serviceAccountName 필드를 통해 ServiceAccount를 지정

  • 인증 토큰 제공: ServiceAccount는 API 서버와 통신하기 위한 JWT 토큰을 제공
  • Pod와 자동으로 연결됨 (default SA가 기본 설정)
  • SA마다 고유한 Secret이 자동 생성
  • SA는 Role 또는 ClusterRole과 RoleBinding, ClusterRoleBinding을 통해 RBAC 정책으로 권한이 부여됨
  • 자동 생성 Secret: ServiceAccount 생성 시 kubernetes.io/service-account-token 타입의 Secret이 자동 생성

 

spec.sesrviceAccountName을 지정하지 않으면 default SA와 연결되는가?

맞음, 명시적으로 지정하지 않으면, Kubernetes는 자동으로 해당 네임스페이스의 default ServiceAccount를 Pod에 할당

 

Secret와 ServiceAccount의 관계

ServiceAccount가 생성되면, Kubernetes는 자동으로 kubernetes.io/service-account-token 타입의 Secret을 생성하여 해당 SA에 연결

 

Secret정보

  • ca.crt: 클러스터 CA 인증서 
  • namespace: 토큰이 속한 네임스페이스
  • token: JWT 형식의 인증 토큰

 

자동 마운트

Pod가 특정 ServiceAccount로 생성되면, 해당 Secret은 Pod의 /var/run/secrets/kubernetes.io/serviceaccount 경로에 자동 마운트

 

 

kubernetes.io 타입의 Secret 종류


kubernetes.io/service-account-token ServiceAccount용 자동 토큰
kubernetes.io/dockerconfigjson 프라이빗 레지스트리 인증 정보 저장용 
kubernetes.io/basic-auth username/password 형식의 인증
kubernetes.io/ssh-auth SSH 키 기반 인증
kubernetes.io/tls TLS 인증서 및 키 쌍
Opaque 사용자가 임의로 정의하는 일반 Secret
 
 

 

Pod의 권한 획득 및 동작 방식

Pod는 ServiceAccount와 Secret을 통해 Kubernetes 클러스터 내에서 권한을 획득하고 동작

 

  1. Pod 생성: Pod가 생성되면 spec.serviceAccountName에 지정된 ServiceAccount가 할당
  2. 토큰 마운트: 해당 ServiceAccount의 Secret이 Pod의 /var/run/secrets/kubernetes.io/serviceaccount에 마운트
  3. API 호출: Pod 내 애플리케이션은 마운트된  token을 사용하여 Kubernetes API 서버에 요청
  4. RBAC: API 서버는 RBAC 정책을 통해 ServiceAccount의 권한을 확인하고 요청을 승인 또는 거부
  5. 이미지 Pulling: Pod는 imagePullSecrets를 통해 kubernetes.io/dockerconfigjson 타입의 Secret을 참조하여 프라이빗 레지스트리에서 이미지를 풀링

 

 

보안 고려 사항

  • default SA에 과도한 권한 부여 금지
  • 사용하지 않는 SA 제거
  • 토큰 마운트 여부 수동 설정
  • BoundServiceAccountToken 사용으로 단기 토큰 활성화 권장
  • Secret은 암호화된 etcd에 저장되며, 필요 시 KMS 기반의 암호화 정책 구성

 

 

 

참고 자료

 

728x90
반응형
그리드형

'귀찮게하기 > DevOps-SRE' 카테고리의 다른 글

Kubernetes Pod 스케줄링 정복  (0) 2025.05.28
클러스터 외부에서 Istio Service Mesh 파드 접근 흐름  (0) 2025.05.16
Redis에 대한 오해  (0) 2025.04.23
DevOps - istio(2)  (1) 2025.04.12
[Kubernetes] RBAC  (0) 2025.04.05