SealedSecret이 못 남기는 것 - OpenBao + External Secrets Operator로 감사 로그 확보하기

목표

시리즈 6(ISMS-P 매핑)에서 남겨둔 숙제 하나 - SealedSecret은 "평문이 Git에 올라가지 않는다"는 것까지는 보장하지만, 누가 언제 그 시크릿을 열람·변경했는지에 대한 감사 로그를 남기지 않는다. 이 갭을 메우는 표준적인 방법(OpenBao + External Secrets Operator)을 실제로 구성해보고, 이 랩 규모에서는 그 방법을 실제로 도입할 가치가 있는지까지 따져본다.

개념: 시크릿마다 "진실 공급원"이 다르다

시리즈 5에서 Keycloak 클라이언트 시크릿을 SealedSecret으로 풀었다 - kubeseal로 암호화해서 Git에 커밋하고, 클러스터 안의 컨트롤러만 복호화할 수 있는 방식이다. 값이 거의 안 바뀌고 Git으로 이력 관리가 되면 충분한 시크릿에는 이 방식이 잘 맞는다.

반면 DB 접속 정보, 외부 API 키, 서비스 간 통신 토큰처럼 회전(rotation)이 필요하거나, 여러 서비스가 같은 값을 공유해야 하거나, 값 자체를 감사(audit)해야 하는 시크릿은 성격이 다르다. SealedSecret은 "이미 암호화된 값을 Git에 안전하게 두는 것"에는 강하지만, 그 값 자체를 중앙에서 관리하고 회전 이력을 추적하는 용도로는 설계되어 있지 않다.

OpenBao(HashiCorp Vault 계열의 오픈소스 시크릿 관리 도구)는 시크릿을 중앙에 저장하고, 누가 언제 어떤 시크릿에 접근했는지 감사 로그를 남기며, 주기적인 자동 회전까지 지원하는 전용 시스템이다. 문제는 서비스가 이 저장소를 직접 호출하게 만들면 코드가 특정 도구에 종속된다는 것 - 그래서 **External Secrets Operator(ESO)**가 중간에서 OpenBao의 값을 읽어 평범한 Kubernetes Secret으로 동기화해준다. 서비스 입장에서는 여전히 일반 Secret을 쓰는 것과 다르지 않다.

[ OpenBao ]  ← 시크릿의 단일 진실 공급원, 회전·감사 이력 관리
     │  ExternalSecret 리소스가 참조
     ▼
[ External Secrets Operator ]
     │  주기적으로 동기화
     ▼
[ 네임스페이스별 Kubernetes Secret ]
     │  일반 Secret처럼 마운트/환경변수로 주입
     ▼
[ 서비스 파드 ]

실제 구축 절차

1. OpenBao + ESO 설치

helm repo add openbao https://openbao.github.io/openbao-helm
helm install openbao openbao/openbao --namespace security --create-namespace

helm repo add external-secrets https://charts.external-secrets.io
helm install external-secrets external-secrets/external-secrets --namespace security

2. SecretStore / ExternalSecret 연결

apiVersion: external-secrets.io/v1beta1
kind: SecretStore
metadata:
  name: openbao-backend
  namespace: app
spec:
  provider:
    vault:
      server: "http://openbao.security:8200"
      path: "secret"
      version: "v2"
      auth:
        tokenSecretRef:
          name: openbao-token
          key: token
---
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: api-server-db-secret
  namespace: app
spec:
  secretStoreRef: {name: openbao-backend, kind: SecretStore}
  target: {name: api-server-db-secret}
  refreshInterval: 1h
  data:
    - secretKey: DB_PASSWORD
      remoteRef: {key: app/db, property: password}

위 예시는 토큰 기반 인증이지만, 운영 환경에서는 정적 토큰을 또 하나의 시크릿으로 관리해야 하는 문제를 피하려고 쿠버네티스 ServiceAccount 인증 방식을 쓰는 경우가 많다 - ESO가 자신의 ServiceAccount 토큰을 제시하면 OpenBao가 역할(role)에 매핑해서 접근을 허용하는 방식이다. 정적 크리덴셜을 하나 더 만드는 대신, 이미 있는 쿠버네티스 신원 체계를 그대로 재사용하는 셈이다.

refreshInterval도 시크릿 성격에 따라 다르게 잡을 수 있다 - 자주 참조되고 회전 가능성이 있는 값은 짧은 주기(분 단위), 거의 안 바뀌는 값은 긴 주기(시간 단위)로 두면 된다. 전부 짧게 잡으면 OpenBao에 불필요한 폴링 부하가 쌓이고, 전부 길게 잡으면 회전이 반영되는 데 오래 걸린다.

3. 검증

# 1) OpenBao에서 값 변경
bao kv put secret/app/db password=<새 값>

# 2) ESO 다음 동기화 주기 후 K8s Secret이 자동 갱신됐는지 확인
kubectl get secret api-server-db-secret -n app -o jsonpath='{.data.DB_PASSWORD}' | base64 -d

# 3) OpenBao 감사 로그(audit log) 활성화 후, 방금 그 조회가 기록되는지 확인
bao audit enable file file_path=/vault/logs/audit.log

"누가 이 시크릿을 읽었는지"가 감사 로그에 실제로 남는다는 것 - 이게 SealedSecret으로는 만들 수 없었던 증적이다.

검증 방법

• OpenBao에서 값을 바꾼 뒤, ExternalSecret의 refreshInterval이 지나면 K8s Secret이 실제로 갱신되는지 확인
• 감사 로그를 켠 상태에서 시크릿을 조회하고, 그 조회 기록이 감사 로그에 남는지 확인
• (이 랩처럼 도입하지 않기로 했다면) 왜 안 했는지를 위 표처럼 트레이드오프로 설명할 수 있는지 - "안 했다"가 아니라 "왜 안 했는지"가 증적이자 판단 근거가 된다

체크리스트

• OpenBao + External Secrets Operator 설치, SecretStore/ExternalSecret 연결 확인
• 감사 로그 활성화 + 시크릿 접근 기록 확인
• SealedSecret과 OpenBao+ESO 중 무엇을 쓸지, 이 랩/프로젝트 규모에 맞는 기준으로 판단하고 근거 문서화