96. K8s Sealed Secrets - GitOps 시크릿 암호화 관리

핵심 인사이트 (3줄 요약)

본질: Sealed Secrets는 데이터베이스 비밀번호 같은 민감한 K8s Secret을 단방향 비대칭키로 암호화하여, Git 저장소에 안전하게 커밋할 수 있도록 돕는 보안 커스텀 리소스(CRD)다.

가치: "모든 인프라 코드는 Git에 선언되어야 한다"는 GitOps의 원칙과 "비밀번호를 평문으로 올리면 안 된다"는 보안의 딜레마를 완벽히 타파하여, DevSecOps의 심리적 안전감을 제공한다.

판단 포인트: 클러스터 내부에 보관된 복호화용 '프라이빗 키'를 오프라인에 백업하지 않으면, 클러스터 장애 시 Git에 저장된 모든 암호화 시크릿이 영구적으로 복구 불가능한 쓰레기 데이터가 된다.

Ⅰ. 개요 및 필요성

ArgoCD나 Flux를 활용하는 최신 GitOps 아키텍처는 쿠버네티스의 모든 상태를 Git(Source of Truth)으로 관리한다. 하지만 여기에는 치명적인 보안 딜레마가 존재한다. 쿠버네티스의 기본 Secret 리소스는 암호화가 아닌 단순 Base64 인코딩 방식을 사용하기 때문이다. 이를 그대로 Git에 올리는 것은 해커에게 데이터베이스 비밀번호나 API 인증서를 평문으로 던져주는 것과 같다.

그렇다고 시크릿만 Git에서 빼고 수동으로 클러스터에 주입하면, GitOps의 핵심인 '완전한 자동화 및 선언적 복원력'이 깨진다. Bitnami에서 개발한 K8s Sealed Secrets는 이 모순을 비대칭 암호화(Asymmetric Encryption) 기술로 해결했다. 누구나 암호화할 수 있지만 오직 클러스터만이 해독할 수 있게 만들어, 시크릿 코드도 퍼블릭 Git 저장소에 안전하게 푸시할 수 있는 환경을 열었다.

📢 섹션 요약 비유: 투명한 유리상자(Git) 안에 일기장(Secret)을 넣어야 하는 규칙과, 일기장을 남에게 보여주면 안 된다는 규칙이 충돌할 때, 일기장 내용 자체를 외계어로 번역(Sealed)해서 유리상자에 넣는 마법의 번역기다.

Ⅱ. 아키텍처 및 핵심 원리

Sealed Secrets 시스템은 클러스터 내부에 상주하는 '컨트롤러(Controller)'와 개발자 로컬 PC에서 구동되는 '클라이언트 도구(kubeseal)'로 역할을 나눈다.

구성 요소	역할	상세 기제
Sealed Secrets Controller	비대칭 키 생성 및 복호화	클러스터 시작 시 RSA 퍼블릭/프라이빗 키 쌍을 자동 생성하고 프라이빗 키 보관
`kubeseal` (CLI)	로컬 환경에서의 단방향 암호화	클러스터에서 퍼블릭 키를 다운받아, 로컬의 평문 Secret을 `SealedSecret` CRD로 암호화
GitOps Agent (ArgoCD)	상태 동기화 및 반영	Git에 푸시된 암호화 매니페스트를 K8s 클러스터로 끌고 와서 적용 (Pull)

┌──────────────────────────────────────────────────────────────┐
│           Sealed Secrets 기반의 GitOps 파이프라인           │
├──────────────────────────────────────────────────────────────┤
│  [개발자 로컬 PC]             [Git 저장소]            [K8s 클러스터] │
│                                                              │
│ 1. 평문 Secret 작성                                          │
│         │                                                    │
│ 2. `kubeseal` 실행 ──(Public Key)──┐                       │
│         │                          │                       │
│ 3. 암호화된 SealedSecret 생성        │  [Controller] (Private Key)│
│         │                          │                       │
│ 4. Git Push ─────────────────▶ 저장 ────(ArgoCD Sync)──▶ 5. K8s 배포 │
│                                                            │ │
│                                        [원본 Secret 복원] ◀─┘ │
└──────────────────────────────────────────────────────────────┘

가장 중요한 원리는 단방향 워크플로다. 개발자는 퍼블릭 키를 사용해 평문을 묶어(Seal) 암호문 덩어리로 만들 수 있지만, 이 암호문은 개발자 본인조차도 다시 풀 수 없다. 오직 클러스터 안에서 프라이빗 키를 품고 있는 컨트롤러만이 이를 해독하여 K8s 내부에 실제 Secret 객체를 렌더링한다.

📢 섹션 요약 비유: 개발자는 엽서에 비밀번호를 적고 '열면 터지는 특수 자물쇠(kubeseal)'를 채워 우체통(Git)에 넣는다. 도둑이 엽서를 주워도 열 수 없으며, 오직 마스터 키를 가진 우체국장(Controller)만이 안전하게 뜯어볼 수 있다.

Ⅲ. 비교 및 연결

시크릿 관리 솔루션은 인프라 종속성과 운영 복잡도에 따라 크게 3가지 패러다임으로 나뉜다. Sealed Secrets는 가장 'GitOps 친화적'이고 가벼운 방식이다.

비교 항목	K8s Sealed Secrets	HashiCorp Vault (External)	AWS Secrets Manager
저장 위치	Git 저장소 (암호화 상태)	별도의 Vault 중앙 서버	클라우드 벤더의 관리형 서비스
운영 복잡도	낮음 (K8s 내 컨트롤러 1개)	매우 높음 (클러스터 외 별도 시스템)	중간 (IAM 및 OIDC 권한 연동 필요)
동적 제어 능력	낮음 (정적 패스워드 암호화 특화)	높음 (단기 토큰 동적 발급 특화)	높음 (자동 로테이션 특화)
가장 적합한 환경	소/중규모, 완전한 GitOps 추구 조직	멀티 클러스터 대규모 엔터프라이즈	AWS 인프라 100% 종속 환경

Vault나 AWS Secrets Manager가 비밀번호를 외부 금고에 숨겨두고 K8s가 런타임에 열쇠를 빌려오는(External) 방식이라면, Sealed Secrets는 비밀번호 자체를 코드화(IaC)하여 Git이라는 한 바구니에 담아 버전 관리를 통합할 수 있다는 뚜렷한 장점이 있다.

📢 섹션 요약 비유: Vault가 돈을 거대한 은행 금고에 맡기고 체크카드만 쓰는 것이라면, Sealed Secrets는 돈을 튼튼한 개인 금고에 넣은 채 금고째로 방(Git)에 보관하는 것이다.

Ⅳ. 실무 적용 및 기술사 판단

Sealed Secrets는 도입은 쉽지만, 핵심 보안 키의 라이프사이클 관리를 잘못하면 대형 사고로 이어진다.

치명적 리스크: 마스터 키 재해 복구 (DR):
- 컨트롤러가 가진 프라이빗 키를 백업하지 않고 K8s 클러스터가 파괴(재설치)되었다면?
- Git에 수천 줄의 SealedSecret 코드가 남아있어도, 이를 해독할 키가 없으므로 서비스는 영원히 복구되지 않는다.
- 의사결정: 클러스터 구축 직후 컨트롤러의 프라이빗 키(TLS Secret)를 반드시 추출하여, 사내 오프라인 물리 금고나 AWS KMS 같은 가장 안전한 곳에 **수동 백업(DR)**해야 한다.
키 로테이션 (Key Rotation) 정책:
- 보안 규정에 따라 30일마다 퍼블릭/프라이빗 키 쌍을 갱신(로테이션)해야 할 수 있다.
- 키가 바뀌더라도 기존에 옛날 키로 암호화된 시크릿은 컨트롤러가 과거 키 이력을 기억하여 여전히 복호화할 수 있으나, 새로 암호화할 때는 반드시 최신 퍼블릭 키를 가져오도록 파이프라인을 설계해야 한다.

📢 섹션 요약 비유: 아무리 튼튼한 자물쇠(Sealed Secrets)를 수백 개 샀더라도, 하나뿐인 마스터 열쇠(프라이빗 키)를 복사해서 안방 장롱(DR 백업)에 넣어두지 않으면, 열쇠를 잃어버리는 순간 집안의 모든 가구를 부숴야 한다.

Ⅴ. 기대효과 및 결론

Sealed Secrets의 도입은 'DevSecOps (개발-보안-운영 통합)' 체계의 완성을 의미한다. 개발자는 더 이상 로컬 PC에 텍스트 파일로 비밀번호를 관리하거나 슬랙으로 키를 주고받지 않아도 되며, 인프라스트럭처 애즈 코드(IaC)의 완전성을 보장받을 수 있다.

하지만 조직의 규모가 커져 여러 클러스터에서 동일한 데이터베이스 계정을 공유하거나, 매 시간 바뀌는 동적 토큰 발급이 필요해지면 Sealed Secrets의 한계가 명확해진다. 따라서 초기에는 GitOps 친화적인 Sealed Secrets로 선언적 배포의 이점을 취하고, 기업 보안 성숙도가 높아짐에 따라 Vault 기반의 External Secrets Operator로 진화하는 하이브리드 아키텍처 전략이 이상적이다.

📢 섹션 요약 비유: Sealed Secrets는 초보 기사도 쉽게 다룰 수 있는 가볍고 튼튼한 마법 방패다. 전장이 커져서 성 전체를 방어해야 할 때는 더 큰 성벽(Vault)이 필요해지겠지만, 개인의 생존을 지키는 데는 이보다 완벽한 도구가 없다.

📌 관련 개념 맵

개념	연결 포인트
GitOps	선언적 코드를 Git에서 관리하는 패러다임으로, Sealed Secrets 도입의 근본 원인
Asymmetric Cryptography (비대칭 암호화)	퍼블릭 키(암호화)와 프라이빗 키(복호화)를 분리하는 핵심 보안 원리
External Secrets Operator	Sealed Secrets의 정적 관리를 넘어, 외부 KMS(Vault 등)와 연동하기 위한 대체/확장 기술
Disaster Recovery (재해 복구)	컨트롤러의 마스터 프라이빗 키를 백업하여 클러스터 소실 시 복원력을 확보하는 필수 절차

📈 관련 키워드 및 발전 흐름도

Base64 인코딩 K8s Secret (단순 평문)
    │
    ▼
GitOps 도입에 따른 시크릿 유출 취약점 발생
    │
    ▼
K8s Sealed Secrets (GitOps 친화적 비대칭 암호화)
    │
    ▼
HashiCorp Vault / External Secrets Operator (중앙 집중식 동적 관리)
    │
    ▼
Secret Rotation & OIDC/SPIFFE (비밀번호 없는 자격 증명 연동)

이 흐름도는 인프라 보안 관리 방식이 "평문 노출 → 로컬 정적 암호화 → 외부 중앙화 → 단기 토큰/무암호화"로 진화하는 과정을 보여준다.

👶 어린이를 위한 3줄 비유 설명

학교 게시판(Git)에 친구에게 줄 비밀 쪽지(Secret)를 그냥 붙이면 나쁜 친구들이 다 읽어버려요.
Sealed Secrets는 비밀 쪽지를 '마법의 암호 상자'에 넣어서 게시판에 붙이게 도와주는 규칙이에요.
이 상자는 오직 쪽지를 받을 진짜 친구(클러스터 컨트롤러)만이 가진 열쇠로만 찰칵! 하고 열 수 있답니다!