TIL

Secret

• 공식 문서 - Secret
• 비밀번호·토큰·키 같은 소량의 민감 데이터를 담는 API 객체
• [[configmap]]과 비슷하지만 — 민감 정보 전용으로 설계
• Pod과 분리해서 만들 수 있어 — Pod 생성·조회·편집 과정에서 민감 데이터가 노출될 위험이 줄어듦

보안 주의 — 기본 상태는 “암호화 아님”

• 기본적으로 Secret은 etcd에 평문(unencrypted) 저장됨 — 단순 base64 인코딩일 뿐 암호화가 아님
• API 접근 권한이 있는 누구나 Secret을 읽거나 수정할 수 있고, etcd에 접근 가능한 사람도 마찬가지
• namespace 안에서 Pod 생성 권한만 있어도 그 namespace의 모든 Secret을 읽을 수 있음 — Deployment 생성 같은 간접 경로도 포함
• 안전하게 쓰려면 최소한
  • Encryption at Rest 활성화
  • RBAC 최소 권한 원칙 적용
  • 특정 컨테이너로만 Secret 접근 제한
  • 외부 Secret store provider(예: Secrets Store CSI Driver) 검토

Uses for Secrets

• 컨테이너 환경 변수로 자격 증명 주입
• Pod에 SSH 키·비밀번호 같은 자격 증명을 파일로 제공
• kubelet이 private registry에서 이미지를 pull할 때 사용 (imagePullSecrets)
• 컨트롤 플레인도 내부적으로 Secret 사용 — 예: bootstrap token으로 노드 등록 자동화

Use case: dotfiles in a secret volume

• key 이름이 .로 시작하면 — 볼륨 마운트 시 숨김 파일(dotfile)로 노출
• 예: key .secret-file → /etc/secret-volume/.secret-file로 생성
• ls -l에는 안 보이고 ls -la로만 보임

Use case: 컨테이너 1개에만 Secret을 한정

• HTTP 요청 처리 + 복잡한 비즈니스 로직 + HMAC 서명 같은 작업을 한 컨테이너에서 다 하면 — 원격 파일 읽기 취약점이 private key를 노출시킬 위험
• 두 컨테이너로 분리 — frontend(요청·로직, key 안 보임) + signer(key 보유, localhost로 서명 요청만 처리)
• 공격자가 임의 코드 실행을 해야만 key에 접근 가능해져 공격 난이도가 올라감

Alternatives to Secrets

• 민감 데이터를 보호하는 게 목적이라면 Secret 외의 선택지도 있음

대안	용도
ServiceAccount + token	같은 클러스터 내 다른 앱에 클라이언트 인증할 때
외부 secret 관리 서비스	HTTPS로 Secret을 제공하는 third-party 도구 (Vault 등)
Custom signer + CertificateSigningRequest	X.509 인증서 발급용 커스텀 signer 구현
Device plugin	TPM 같은 노드-로컬 암호화 하드웨어를 특정 Pod에 노출

• 여러 옵션을 조합해도 됨 — 예: operator가 외부 서비스에서 단기 세션 토큰을 받아 Secret으로 만들어주면, Pod은 토큰 발급 메커니즘을 몰라도 됨

Types of Secret

• Secret 생성 시 type 필드로 종류를 지정 — 프로그래밍 방식의 처리와 유효성 검증을 쉽게 하기 위한 용도
• 커스텀 type도 가능 — type에 빈 문자열이 아닌 아무 문자열이나 넣으면 됨. 관례상 도메인/이름 형식 권장 (예: cloud-hosting.example.net/cloud-api-credentials)

Built-in Type	용도	필수 key
Opaque	임의의 사용자 정의 데이터 (기본값)	없음
kubernetes.io/service-account-token	ServiceAccount 토큰	— (컨트롤러가 채움)
kubernetes.io/dockercfg	~/.dockercfg 직렬화	.dockercfg
kubernetes.io/dockerconfigjson	~/.docker/config.json 직렬화	.dockerconfigjson
kubernetes.io/basic-auth	Basic 인증 자격 증명	username 또는 password 중 하나 이상
kubernetes.io/ssh-auth	SSH 인증 자격 증명	ssh-privatekey
kubernetes.io/tls	TLS 인증서 + 키	tls.crt, tls.key
bootstrap.kubernetes.io/token	노드 부트스트랩 토큰	token-id, token-secret

Opaque

• type 미지정 시 기본값 — kubectl create secret generic으로 생성
• 아무 구조나 제약 없이 자유롭게 key-value를 저장

ServiceAccount token

• ServiceAccount 인증 토큰을 저장하는 레거시 방식 — 만료 없이 영속되므로 보안 노출 위험
• v1.22+부터는 TokenRequest API로 단기·자동 갱신 토큰을 쓰는 것이 권장
  • kubectl create token 명령으로 직접 발급
  • projected volume으로 Pod에 자동 마운트 — Pod 삭제 시 토큰도 무효화
• 레거시 방식 사용 시 — kubernetes.io/service-account.name annotation에 기존 ServiceAccount 이름을 지정해야 함. Secret 생성 후 컨트롤러가 token key와 service-account.uid annotation을 자동으로 채워 줌

Docker config

• 컨테이너 이미지 레지스트리 인증 정보를 저장
• dockercfg (레거시 포맷) 또는 dockerconfigjson (신규 포맷) 중 택1
• kubectl create secret docker-registry로 간편 생성 가능

kubectl create secret docker-registry my-secret \
  --docker-username=user \
  --docker-password=pass \
  --docker-server=my-registry.example:5000

• API server가 필수 key 존재 + JSON 파싱 가능 여부만 확인 — 실제 Docker 설정 파일인지까지는 검증하지 않음
• data의 auth 값은 단순 base64 → 읽을 수 있으면 레지스트리 토큰이 노출됨. 동적 자격 증명이 필요하면 credential provider 권장

Basic authentication

• username / password 두 key 중 하나 이상 필수 — 값은 base64 인코딩 (또는 stringData로 평문 제공)
• 편의를 위한 타입 — 실질적으로 Opaque로도 동일하게 쓸 수 있지만, 타입을 명시하면 용도와 key 규칙이 명확해짐

SSH authentication

• ssh-privatekey key 필수 — SSH private key를 값으로 저장
• API server가 필수 key 존재를 검증
• SSH private key만으로는 신뢰된 통신이 보장되지 않음 — known_hosts 파일 등을 ConfigMap으로 함께 관리해야 MITM 방어 가능

TLS

• tls.crt (인증서) + tls.key (개인 키) 두 key 필수
• 대표 용도 — Ingress의 TLS 종단 설정. 그 외 워크로드에서 직접 사용도 가능
• API server는 필수 key 존재만 확인 — 인증서·키의 유효성(만료·일치 여부)은 검증하지 않음
• kubectl create secret tls로 간편 생성 가능

Bootstrap token

• 노드 부트스트랩 과정에서 사용하는 토큰 — kube-system namespace에 bootstrap-token-<token-id> 이름으로 생성
• 주요 data key

key	설명	필수
token-id	6자리 랜덤 ID	O
token-secret	16자리 랜덤 토큰	O
description	토큰 설명	X
expiration	RFC3339 UTC 만료 시각	X
usage-bootstrap-<usage>	토큰의 추가 용도 boolean 플래그	X
auth-extra-groups	system:bootstrappers 외 추가 인증 그룹 (쉼표 구분)	X

Working with Secrets

생성

• 3가지 방법 — kubectl / 설정 파일(YAML) / Kustomize
• data 필드 값은 base64 인코딩 필수. 평문으로 넣고 싶으면 stringData 필드 사용
• stringData는 내부적으로 data에 병합됨 — 같은 key가 둘 다에 있으면 stringData가 우선
• key 규칙 — 영숫자 + - _ . 만 허용 (ConfigMap과 동일)
• 이름 규칙 — DNS subdomain name

크기 제한

• 개별 Secret은 1 MiB 이하 — API server·kubelet 메모리 보호 목적
• 작은 Secret을 대량 생성해도 메모리를 소진할 수 있음 → ResourceQuota로 namespace 내 Secret 수를 제한 가능

수정

• immutable이 아닌 Secret은 kubectl edit / 설정 파일 재적용 / Kustomize로 수정 가능
• Kustomize는 기존 Secret을 수정하는 게 아니라 새 Secret 객체를 생성

Pod에서 Secret 사용

• Volume 마운트 또는 환경 변수로 노출 — ConfigMap과 동일한 패턴
• Secret volume source는 실제로 Secret 타입 객체를 가리키는지 검증됨 → Secret이 먼저 존재해야 함
• Secret을 가져올 수 없으면(존재하지 않거나 API server 연결 실패) — kubelet이 주기적으로 재시도하고 Event를 보고

Optional Secrets

• Pod에서 Secret 참조 시 optional: true를 지정하면 — Secret이 없어도 무시하고 진행
• 기본값은 required — 모든 non-optional Secret이 준비되어야 Pod 컨테이너가 시작됨
• non-optional Secret이 존재하지만 참조한 key가 없으면 → Pod 시작 실패

Volume으로 마운트

• ConfigMap과 동일한 방식 — spec.volumes[].secret.secretName + volumeMounts[]
• Secret이 업데이트되면 마운트된 파일도 결국엔(eventually) 반영 — 캐시 전략도 ConfigMap과 동일 (configMapAndSecretChangeDetectionStrategy)
• 예외 — subPath로 마운트한 컨테이너는 자동 갱신 안 됨

환경 변수로 사용

• env[].valueFrom.secretKeyRef로 개별 key 매핑
• 환경 변수 이름에 허용되지 않는 문자가 key에 있으면 해당 key는 노출되지 않음 (Pod은 정상 시작)
• 환경 변수는 Pod 재시작 없이 갱신되지 않음

imagePullSecrets

• private 이미지 레지스트리에서 pull할 때 — kubelet에 레지스트리 인증 정보를 전달하는 방식
• Pod의 spec.imagePullSecrets에 같은 namespace의 Secret 참조 목록을 지정
• 수동 지정 외에 — ServiceAccount에 imagePullSecrets를 등록해두면, 해당 SA로 생성되는 모든 Pod에 자동 적용

static Pod 제한

• static Pod에서는 Secret(과 ConfigMap)을 사용할 수 없음

Immutable Secrets

• v1.21 stable — immutable: true로 설정하면 data 수정 불가, 되돌리기도 불가
• 변경하려면 삭제 후 재생성 — 기존 Pod은 삭제된 Secret의 마운트 포인트를 유지하므로 Pod도 재생성 권장
• 기존 mutable Secret을 immutable로 전환도 가능 (반대는 불가)
• 효과
  • 사고 방지 — 실수로 인한 변경으로 앱 outage가 나는 것을 막음
  • 성능 개선 — kubelet이 immutable Secret에 대한 watch를 닫아 kube-apiserver 부하 감소. Secret–Pod 마운트가 수만 건 이상인 클러스터에서 유의미

Information security for Secrets

• ConfigMap과 Secret은 비슷하게 동작하지만, K8s는 Secret에 추가 보호를 적용

전송·저장 보호

• Secret은 해당 Secret을 필요로 하는 Pod이 있는 노드에만 전송됨
• kubelet은 Secret 데이터를 tmpfs에 저장 — 디스크(비휘발성 스토리지)에 기록되지 않음
• Pod이 삭제되면 kubelet이 해당 Secret의 로컬 복사본도 삭제

컨테이너 격리

• 컨테이너는 기본적으로 default ServiceAccount의 Secret에만 접근 — 다른 Secret에 접근하려면 env나 volumeMounts를 명시적으로 설정해야 함
• 같은 노드의 여러 Pod이 각각 Secret을 쓰더라도, 한 Pod이 다른 Pod의 Secret에 접근하는 것은 불가

RBAC 주의사항

• namespace에서 list 또는 watch 권한이 있으면 — Pod이 명시적으로 참조하지 않는 Secret까지 포함해 해당 namespace의 모든 Secret을 읽을 수 있음
• 워크로드에 필요한 최소 권한만 부여. cluster-admin 같은 광범위한 역할은 관리 목적 외에는 피해야 함
• 별도 namespace 분리로 마운트된 Secret 접근 범위를 격리하는 것이 권장
• privileged: true로 실행되는 컨테이너는 해당 노드의 모든 Secret에 접근 가능 — 주의