Secret trust boundaries

Dev Vault

dev-k3s는 단일 self-hosted Vault를 사용합니다. 동일 workload 클러스터에 별도의 Transit Vault를 두지 않습니다. 단일 Vault는 다음을 소유합니다.

KV-v2 runtime secret path
Kubernetes auth와 workload role
dynamic PostgreSQL credential
애플리케이션 JWT signing용 Transit key

dev Vault는 Shamir 1-of-1로 한 번 초기화하고 재시작 시 명시적으로 unseal합니다. 이 방식은 개발 환경 전용입니다. production에서는 managed Vault 또는 독립 failure domain의 HA integrated-Raft와 KMS/HSM auto-unseal을 사용해야 합니다.

Terraform

vault-core state는 mounts, auth, policies, roles와 JWT key를 소유하며 제한된 관리자만 적용합니다. vault-database는 PostgreSQL connection과 dynamic roles만 소유하고 vault-database-automation-dev 정책을 사용합니다.

Terraform variable로 전달되는 token과 PostgreSQL password는 ephemeral/ write-only 경계를 사용합니다. KV payload는 Terraform resource/data source로 읽거나 쓰지 않습니다.

Workload authentication

workload는 audience vault, TTL 1시간의 projected ServiceAccount token으로 Vault Kubernetes auth에 로그인합니다. token은 Vault Agent가 사용하며 application container에 Kubernetes bearer token을 직접 노출하지 않습니다.

Secret payload는 승인된 운영자가 Vault에 직접 기록합니다. 값은 Git, Gitea Actions log, Terraform state, Kubernetes manifest에 남기지 않습니다.

Bootstrap material

Vault init output은 기본적으로 .local/vault/dev-k3s-init.json에 mode 0600으로 생성됩니다. encrypted custody로 이동한 후 working copy를 제거합니다. initial root token은 vault-core와 operator auth 검증 직후 폐기합니다.

Sealed Secrets는 private GHCR pull credential에만 사용합니다. controller private key는 별도 복구 저장소에 백업해야 합니다.

Dev limitations

Vault, PostgreSQL, ingress가 아직 TLS를 사용하지 않음
single-node Vault와 PostgreSQL
Kubernetes API egress CIDR가 현재 dev cluster에 종속
정적 bootstrap secret은 coordinated rotation 필요

이 제약은 production에서 허용되지 않습니다.

2.2 KiB Raw Blame History