쿠버네티스 커뮤니티는 장기 유지 자격 증명(long-lived credentials)에 대한 의존도를 줄임으로써 보안 모범 사례를 지속적으로 발전시키고 있습니다. Kubernetes v1.33에서 알파 버전이 성공적으로 출시된 데 이어, Kubelet 자격 증명 공급자를 위한 서비스 어카운트 토큰 통합 기능이 이제 Kubernetes v1.34에서 베타로 승격되었습니다. 이를 통해 쿠버네티스 클러스터에서 장기 유지되는 이미지 풀 시크릿(image pull secrets)을 제거하는 데 한 걸음 더 다가서게 되었습니다.
이 개선 사항은 자격 증명 공급자가 워크로드별 서비스 어카운트 토큰을 사용하여 레지스트리 자격 증명을 획득하도록 허용함으로써, 기존 이미지 풀 시크릿에 대한 안전하고 일시적인 대안을 제공합니다.
베타 버전의 새로운 기능
베타 버전 출시에는 이 기능을 더욱 견고하고 프로덕션 환경에 적합하게 만드는 몇 가지 중요한 변경 사항이 포함되어 있습니다.
필수 cacheType 필드
알파 버전과의 호환성 변경: 서비스 어카운트 토큰을 사용할 때 자격 증명 공급자 설정에서 cacheType 필드가 필수입니다. 이 필드는 베타 버전에서 새로 추가되었으며 적절한 캐싱 동작을 보장하기 위해 지정해야 합니다.
# 주의: 이 예시는 완전한 설정 예시가 아니며, 'tokenAttributes.cacheType' 필드에 대한 참조용입니다.
tokenAttributes:
serviceAccountTokenAudience: "my-registry-audience"
cacheType: "ServiceAccount" # 베타 버전에서 필수 필드
requireServiceAccount: true
두 가지 캐싱 전략 중 선택할 수 있습니다:
Token: 서비스 어카운트 토큰별로 자격 증명을 캐시합니다 (자격 증명 수명이 토큰에 연결된 경우 사용). 이는 자격 증명 공급자가 서비스 어카운트 토큰을 토큰과 동일한 수명을 가진 레지스트리 자격 증명으로 변환하거나, 레지스트리가 쿠버네티스 서비스 어카운트 토큰을 직접 지원하는 경우에 유용합니다. 참고: Kubelet은 서비스 어카운트 토큰을 레지스트리에 직접 보낼 수 없습니다. 토큰을 레지스트리에서 예상하는 사용자 이름/비밀번호 형식으로 변환하려면 자격 증명 공급자 플러그인이 필요합니다.ServiceAccount: 서비스 어카운트 ID별로 자격 증명을 캐시합니다 (동일한 서비스 어카운트를 사용하는 모든 파드에 대해 자격 증명이 유효한 경우 사용).
격리된 이미지 풀 자격 증명
베타 버전은 이미지 풀에 서비스 어카운트 토큰을 사용할 때 컨테이너 이미지에 대한 더 강력한 보안 격리를 제공합니다. 이를 통해 파드는 자신이 사용하도록 승인된 서비스 어카운트를 사용하여 풀링된 이미지에만 접근할 수 있습니다. 이는 민감한 컨테이너 이미지에 대한 무단 접근을 방지하고, 서로 다른 워크로드가 해당 서비스 어카운트에 따라 다른 레지스트리 권한을 가질 수 있도록 세분화된 접근 제어를 가능하게 합니다.
자격 증명 공급자가 서비스 어카운트 토큰을 사용할 때, 시스템은 풀링된 각 이미지에 대해 서비스 어카운트 ID(네임스페이스, 이름 및 UID)를 추적합니다. 파드가 캐시된 이미지를 사용하려고 할 때, 시스템은 파드의 서비스 어카운트가 이미지를 원래 풀링하는 데 사용된 서비스 어카운트와 정확히 일치하는지 확인합니다.
관리자는 서비스 어카운트를 삭제하고 다시 생성함으로써 이전에 풀링된 이미지에 대한 접근을 취소할 수 있으며, 이는 UID를 변경하고 캐시된 이미지 접근을 무효화합니다.
이 기능에 대한 자세한 내용은 이미지 풀 자격 증명 확인 문서를 참조하십시오.
작동 방식
설정
자격 증명 공급자는 tokenAttributes 필드를 설정하여 서비스 어카운트 토큰 사용을 선택합니다:
#
# 주의: 이 예시는 설정 예시입니다.
# 자신의 클러스터에 사용하지 마십시오!
#
apiVersion: kubelet.config.k8s.io/v1
kind: CredentialProviderConfig
providers:
- name: my-credential-provider
matchImages:
- "*.myregistry.io/*"
defaultCacheDuration: "10m"
apiVersion: credentialprovider.kubelet.k8s.io/v1
tokenAttributes:
serviceAccountTokenAudience: "my-registry-audience"
cacheType: "ServiceAccount" # 베타 버전에서 새로 추가됨
requireServiceAccount: true
requiredServiceAccountAnnotationKeys:
- "myregistry.io/identity-id"
optionalServiceAccountAnnotationKeys:
- "myregistry.io/optional-annotation"
이미지 풀 흐름
개략적으로 kubelet은 자격 증명 공급자 및 컨테이너 런타임과 다음과 같이 협력합니다:
- 이미지가 로컬에 없을 때:
kubelet은 설정된cacheType(Token또는ServiceAccount)을 사용하여 자격 증명 캐시를 확인합니다.- 필요한 경우,
kubelet은 파드의 서비스 어카운트에 대한 서비스 어카운트 토큰을 요청하고, 필요한 모든 어노테이션과 함께 자격 증명 공급자에게 전달합니다. - 공급자는 해당 토큰을 레지스트리 자격 증명으로 교환하고
kubelet에 반환합니다. kubelet은cacheType전략에 따라 자격 증명을 캐시하고 해당 자격 증명으로 이미지를 풀링합니다.kubelet은 나중에 권한 확인을 위해 풀링된 이미지와 관련된 서비스 어카운트 좌표(네임스페이스, 이름, UID)를 기록합니다.
- 이미지가 이미 로컬에 있을 때:
kubelet은 파드의 서비스 어카운트 좌표가 캐시된 이미지에 대해 기록된 좌표와 일치하는지 확인합니다.- 정확히 일치하면 레지스트리에서 풀링할 필요 없이 캐시된 이미지를 사용할 수 있습니다.
- 다른 경우,
kubelet은 새 서비스 어카운트에 대한 자격 증명을 사용하여 새로 풀링을 수행합니다.
- 이미지 풀 자격 증명 확인이 활성화된 경우:
- 기록된 서비스 어카운트 좌표를 사용하여 권한이 강제 적용되어, 파드가 자신이 사용하도록 승인된 서비스 어카운트가 풀링한 이미지만 사용하도록 보장합니다.
- 관리자는 서비스 어카운트를 삭제하고 다시 생성함으로써 접근을 취소할 수 있습니다. UID가 변경되고 이전에 기록된 권한은 더 이상 일치하지 않습니다.
대상 제한
베타 버전은 kubelet이 승인된 대상을 위한 토큰만 요청할 수 있도록 서비스 어카운트 노드 대상 제한(v1.33부터 베타)을 기반으로 구축되었습니다. 관리자는 RBAC를 사용하여 허용된 대상을 구성함으로써 kubelet이 이미지 풀을 위한 서비스 어카운트 토큰을 요청할 수 있도록 합니다:
#
# 주의: 이 예시는 설정 예시입니다.
# 자신의 클러스터에 사용하지 마십시오!
#
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: kubelet-credential-provider-audiences
rules:
- verbs: ["request-serviceaccounts-token-audience"]
apiGroups: [""]
resources: ["my-registry-audience"]
resourceNames: ["registry-access-sa"] # 선택 사항: 특정 서비스 어카운트
베타 버전 시작하기
사전 요구 사항
- Kubernetes v1.34 이상
- 기능 게이트 활성화:
KubeletServiceAccountTokenForCredentialProviders=true(베타, 기본적으로 활성화됨) - 자격 증명 공급자 지원: 서비스 어카운트 토큰을 처리하도록 자격 증명 공급자를 업데이트하십시오.
알파 버전에서 마이그레이션
알파 버전을 이미 사용 중인 경우, 베타 버전으로의 마이그레이션에는 최소한의 변경이 필요합니다:
cacheType필드 추가: 자격 증명 공급자 설정을 업데이트하여 필수cacheType필드를 포함하십시오.- 캐싱 전략 검토: 공급자의 동작에 따라
Token과ServiceAccount캐시 유형 중 선택하십시오. - 대상 제한 테스트: RBAC 설정 또는 다른 클러스터 권한 부여 규칙이 토큰 대상을 올바르게 제한하는지 확인하십시오.
설정 예시
다음은 서비스 어카운트 토큰을 사용하는 자격 증명 공급자 설정에 대한 완전한 예시입니다 (이 예시는 클러스터가 RBAC 권한 부여를 사용한다고 가정합니다):
#
# 주의: 이 예시는 설정 예시입니다.
# 자신의 클러스터에 사용하지 마십시오!
#
# 레지스트리 어노테이션이 있는 서비스 어카운트
apiVersion: v1
kind: ServiceAccount
metadata:
name: registry-access-sa
namespace: default
annotations:
myregistry.io/identity-id: "user123"
---
# 대상 제한을 위한 RBAC
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: registry-audience-access
rules:
- verbs: ["request-serviceaccounts-token-audience"]
apiGroups: [""]
resources: ["my-registry-audience"]
resourceNames: ["registry-access-sa"] # 선택 사항: 특정 서비스 어카운트
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: kubelet-registry-audience
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: registry-audience-access
subjects:
- kind: Group
name: system:nodes
apiGroup: rbac.authorization.k8s.io
---
# 서비스 어카운트를 사용하는 파드
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
serviceAccountName: registry-access-sa
containers:
- name: my-app
image: myregistry.example/my-app:latest
다음 단계
Kubernetes v1.35에서는 Kubernetes SIG Auth가 이 기능이 베타 상태를 유지할 것으로 예상하며, 계속해서 피드백을 수렴할 예정입니다.
이 기능에 대한 자세한 내용은 쿠버네티스 문서의 이미지 풀을 위한 서비스 어카운트 토큰 페이지에서 확인할 수 있습니다.
KEP-4412를 통해 향후 쿠버네티스 릴리스의 진행 상황을 추적할 수도 있습니다.
참여 요청
이 블로그 게시물에서는 Kubernetes v1.34에서 Kubelet 자격 증명 공급자를 위한 서비스 어카운트 토큰 통합 기능이 베타로 승격된 내용을 다루었습니다. 필수 cacheType 필드 및 이미지 풀 자격 증명 확인 기능과의 강화된 통합을 포함한 주요 개선 사항에 대해 설명했습니다.
알파 단계 동안 커뮤니티로부터 긍정적인 피드백을 받아왔으며, 이 기능을 GA(General Availability) 버전으로 안정화하는 과정에서 더 많은 의견을 듣고 싶습니다. 특히, 새로운 베타 API 및 캐싱 메커니즘과 통합하는 자격 증명 공급자 구현자들의 피드백을 환영합니다. Kubernetes Slack의 #sig-auth-authenticators-dev 채널로 연락 주십시오.
참여 방법
이 기능 개발에 참여하거나, 피드백을 공유하거나, 다른 SIG Auth 프로젝트에 참여하는 데 관심이 있다면 Kubernetes Slack의 #sig-auth 채널로 연락 주십시오.
격주 수요일마다 열리는 SIG Auth 회의에도 참여를 환영합니다.