donghyeon.kang/llm-wiki
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
Files
6c53ded9cb70f2d7cf3e66ff50d42f2d151c98b1
llm-wiki/vault/20-evidence/official-docs/secrets-k8s-secret-external-secrets-operator.md
T

9.0 KiB
Raw Blame History

title, source_type, status, confidence, url, archive_url, tags, related_branches, related_projects, created, last_reviewed
title source_type status confidence url archive_url tags related_branches related_projects created last_reviewed
Kubernetes Secret + External Secrets Operator (ESO) official-doc raw high https://kubernetes.io/docs/concepts/configuration/secret/
ca-secrets
kubernetes
external-secrets-operator
eso
secret-sync
feature-secrets-config-source-contract
ca-skeleton-operational-contract
2026-05-22 2026-05-27

Kubernetes Secret + External Secrets Operator (ESO)

Layer: raw/official-docs/ — Kubernetes 공식 Secret 페이지 + ESO 공식 docs 결합. ca-tmpl prod = secret manager OR mounted env 의 "mounted env" 경로 구현 후보의 1차 근거.

Parent / 활용 branch (필수)

Branch 이 자료가 정당화하는 결정
raw/branch-notes/feature-secrets-config-source-contract ca-tmpl prod = secret manager OR mounted env 의 mounted env 경로에서 plain K8s Secret 만으로 부족한 이유 (etcd unencrypted, API full read) + ESO 가 외부 SSOT 와 K8s Secret 을 잇는 정확한 경로라는 결정 근거
raw/project-notes/ca-skeleton-operational-contract ca-tmpl Group G-B (Secrets sub-topic) 의 K8s 환경 구현 대안 input

컨텍스트

feature-secrets-config-source-contract ca-tmpl prod = secret manager OR mounted env 의 "mounted env" 경로의 실제 구현 후보. baseline 이 plain Kubernetes Secret 만으로 충분한지, ESO 같은 외부 sync layer 가 필요한지 판단 근거.

출처 / Source

핵심 인용 / Key quotes (verbatim)

Kubernetes 공식 (Secret 페이지)

[§Secret — definition] "A Secret is an object that contains a small amount of sensitive data such as a password, a token, or a key."

[§Secret — storage] "Kubernetes Secrets are, by default, stored unencrypted in the API server's underlying data store (etcd)."

[§Secret — access risk] "Anyone with API access can retrieve or modify a Secret, and so can anyone with access to etcd."

External Secrets Operator (external-secrets.io)

[§ESO — overview/architecture] "The External Secrets Operator extends Kubernetes with Custom Resources, which define where secrets live and how to synchronize them."

[§ESO — overview/architecture] "The controller fetches secrets from an external API and creates Kubernetes secrets. If the secret from the external API changes, the controller will reconcile the state in the cluster and update the secrets accordingly."

Claims Extracted / 추출된 주장

Claim ID Claim (이 자료가 직접 말하는 것) Evidence quote Strength Applies to Does not prove
K8S-ESO-C1 Kubernetes Secret 은 password / token / key 같은 소량의 sensitive data 를 담는 object [§Secret — definition] "A Secret is an object that contains a small amount of sensitive data such as a password, a token, or a key." official-vendor-doc K8s 환경 secret 관리 일반 Secret 이 대용량 sensitive data (예: TLS bundle 수십 MB) 를 담는 용도라는 뜻은 아님 — "small amount" 명시
K8S-ESO-C2 Kubernetes Secret 은 기본적으로 API server 의 underlying data store (etcd) 에 unencrypted 로 저장 됨 [§Secret — storage] "Kubernetes Secrets are, by default, stored unencrypted in the API server's underlying data store (etcd)." official-vendor-doc K8s 기본 설정 Encryption at Rest 를 활성화한 클러스터에도 적용된다는 뜻은 아님 — "by default" 한정
K8S-ESO-C3 API access 권한자 + etcd access 권한자는 누구나 Secret 을 retrieve 또는 modify 가능 [§Secret — access risk] "Anyone with API access can retrieve or modify a Secret, and so can anyone with access to etcd." official-vendor-doc RBAC 미설정 또는 wide-permission 클러스터 RBAC 로 Secret 접근을 세밀화하면 동일하게 적용된다는 뜻은 아님 — RBAC 적용 시 access 제어 가능
K8S-ESO-C4 ESO 는 Kubernetes 를 Custom Resources 로 확장하여 secrets 의 위치 (where they live) 와 동기화 방법 (how to synchronize) 을 정의 [§ESO — overview/architecture] "The External Secrets Operator extends Kubernetes with Custom Resources, which define where secrets live and how to synchronize them." official-vendor-doc ESO 가 설치된 K8s cluster 모든 secret provider 에 대해 동일한 sync semantics 가 보장된다는 뜻은 아님 — provider 별 capability 차이 존재
K8S-ESO-C5 ESO controller 는 external API 에서 secret 을 fetch 하여 K8s secret 을 생성 하고, external API 변경 시 cluster 의 state 를 reconcile + secret 갱신 [§ESO — overview/architecture] "The controller fetches secrets from an external API and creates Kubernetes secrets. If the secret from the external API changes, the controller will reconcile the state in the cluster and update the secrets accordingly." official-vendor-doc ESO 의 sync 동작 모델 application 이 자동으로 rotated value 를 reload 한다는 뜻은 아님 — application 측 reload 메커니즘 (Pod restart 등) 은 별도 필요

Usage Boundaries / 적용 경계

  • 이 자료가 직접 증명하는 것:
    • K8S-ESO-C1/C2/C3: K8s Secret 의 정의, 기본 unencrypted 저장, API/etcd 접근 위험
    • K8S-ESO-C4/C5: ESO 의 CRD 기반 외부 secret sync 모델
  • 이 자료가 증명하지 않는 것:
    • ESO 가 모든 K8s 환경에서 plain Secret 보다 우월하다는 점 — 소규모 단일 클러스터에서는 plain Secret + RBAC + Encryption at Rest 로 충분할 수 있음
    • ESO sync interval (default 1h) 이 모든 rotation policy 와 호환된다는 점 — high-frequency rotation 시 별도 튜닝 필요
    • ESO 의 40+ provider 지원이 모두 동일한 SLA 와 feature parity 라는 점 — provider 별 capability 차이 존재
    • K8s Encryption at Rest 가 활성화되면 K8S-ESO-C2 의 위험이 완전 제거 — KEK 관리 / etcd backup 등 별도 위험 존재
    • ESO 가 자동으로 application 에 rotated value 를 전달한다는 점 — Pod restart 필요 (ca-tmpl restart-only 와 호환)
  • 내 프로젝트에 적용하려면 추가 확인이 필요한 것:
    • ca-tmpl 의 K8s 환경 채택 시 plain Secret vs ESO vs 직접 secret manager SDK 의 비용/운영 부담 비교
    • ESO 의 ClusterSecretStore vs SecretStore 의 namespace 격리 정책 적용
    • ESO sync interval 의 ca-tmpl rotation SLA 와의 정합성
    • 외부 provider (Vault / AWS SM / GCP SM) 선택 시 audit log 의 ca-tmpl 감사 요건 충족 여부

메모 (내 프로젝트 해석)

본 섹션은 자료 직접 인용 아님. ca-tmpl 결정 컨텍스트 해석.

  • plain Kubernetes Secret 의 한계:
    • etcd 기본 unencrypted → Encryption at Rest 별도 활성화 필요.
    • API access = full read. RBAC 세밀화 필수.
    • SSOT 가 cluster 에 갇혀 있음 → multi-cluster 환경에서 동기화 어려움.
  • ESO 가 보강하는 점:
    • external store (AWS Secrets Manager, Vault, GCP SM 등) 를 SSOT 로 두고 cluster 에 Kubernetes Secret 으로 sync.
    • 외부 secret 변경 시 자동 reconcile (rotation 이후 etcd value 갱신).
    • 그러나 application 은 여전히 Kubernetes Secret 을 mounted env 로 읽음 → ca-tmpl restart-only 정책과 호환.
  • ca-tmpl 결정과의 매핑:
    • "external secret manager OR mounted secret" → ESO + Kubernetes Secret 이 이 둘을 잇는 정확한 경로.
    • ESO sync 후 etcd value 가 바뀌어도 application 은 자동 reload 안 함 (Pod restart 필요) → restart-only 결정과 일치.
  • 장점:
    • 외부 SSOT 의 장점(audit, central rotation) + Kubernetes 환경 친화성.
    • 40+ provider 지원 (Vault, AWS SM, GCP SM, Azure KV, 1Password 등).
    • ClusterSecretStore 로 다중 namespace 공유.
  • 단점:
    • operator 운영 부담.
    • etcd unencrypted 한계는 그대로 → Encryption at Rest 별도.
    • sync interval 안에 외부 rotation 반영 지연 (default 1h).
  • 결정 권고:
    • ca-tmpl 이 platform-neutral baseline 이므로 ESO 를 강제하지 않음. 단 Kubernetes 환경에서는 ESO 가 plain Secret 보다 우선 후보.

Related / 관련

Reference in New Issue View Git Blame Copy Permalink