[TIL] Secret 관리... (feat. OpenBao)

🗣️ 주절주절
회사에서 솔루션 고도화 얘기할 때마다 꼭 한 번씩 나오는 주제...
“Secret 이랑 Credential 관리 해야 돼.”
처음엔 아~ 중요한가보다 하고 흘려들었는데 이번에 배포 쪽 기능을 맡게 되면서 Secret과 Credential 관리의 중요성을 느끼게 되었달까...
환경 변수가 여기저기 흩어져 있고 누가 언제 어떤 키를 썼는지 모르면.. 레전드 사고라는 것..
그래서 회의하면서 계속 언급되던 Vault랑 OpenBao에 대해서 찾아보았다!

📍 Vault 와 OpenBao

• 둘 다 Secret 관리 도구
• ex) DB 계정 / 비밀번호, API Key / 토큰 (AWS, GitHub), 인증서/키 (TLS, SSH, 암호화 키)

🔑 Vault란?

• 민감정보(Secret)를 안전하게 저장, 배포, 통제하는 Secrets Management 솔루션
• 누가, 어떤 서비스가, 어떤 조건에서, 얼마나 안전하게 가져가게 할 거냐를 체계화
• 필요할 때만 발급(동적 발급), 주기적으로 바꿈(로테이션), 누가 썼는지 기록(감사 로그) 같은 운영 기능이 강점

🥟 OpenBao란?

• Vault를 기반으로 만들어진 오픈소스 커뮤니티 포크(fork)

❓ 오픈소스 커뮤니티 포크

• 원래 프로젝트 코드를 가져와서 다른 방향으로 계속 개발해 나가는 것
• 보통은 프로젝트의 방향(특히 라이선스/거버넌스/상용 정책)이 커뮤니티나 기업들이 원하는 방향과 어긋날 때 포크가 탄생

ex) Redis의 라이선스 변화 이후 Valkey 같은 포크가 탄생

📍 어떤 식으로 관리하는가

1️⃣ 저장

• 시크릿을 암호화해서 저장
• 내부적으로 시크릿을 암호화한 뒤 스토리지에 저장

스토리지 자체가 털려도 원문 시크릿이 바로 유출되지 않도록 설계된 것

2️⃣ 인증/인가

• 누가 가져갈 수 있는지 나누기

누구인지 확인(인증)한 다음, 그 사람이/서비스가 어디까지 할 수 있는지(인가)를 정책으로 제한

ex)
kv/data/prod/myapp/* (운영 환경 myapp)
kv/data/prod/payments/* (운영 결제 서비스)
kv/data/dev/myapp/* (개발 환경 myapp)

myapp 서비스 계정 → kv/data/prod/myapp/* 만 읽기 가능
payments 서비스 계정 → kv/data/prod/payments/* 만 읽기 가능
운영자 → prod 전체 읽기 가능
CI/CD → 배포에 필요한 최소 경로만 읽기 가능 (이미지 레지스트리 토큰, 배포용 키)

3️⃣ 배포

• 앱이 시크릿을 가지고 시작하지 않게 만들기 (코드/이미지/레포지토리에 두지 않기)

.env 파일, CI 변수, 서버에 수동 저장, 이미지에 저장되는 것이 아닌
앱이 실행될 때 필요한 시크릿을 안전하게 받아오고 만료되면 다시 받는다

😗 그래서.. 우리는 OpenBao로!

• 우리는 라이선스 변경 이슈를 고려해서 OpenBao 를 사용하기로 결정!

• 오픈소스 도입할 때는 라이선스(Apache, MIT 등)부터 먼저 체크하는 습관이 진짜 중요하다.. (왜냐 내가 책임 질 수 없음,,,,ㅠㅠ)

  Vault	OpenBao
  HashiCorp의 대표 시크릿 관리 제품	Vault 기반 커뮤니티 포크, Linux Foundation 관리
  HashiCorp가 BSL 채택	오픈소스/오픈 거버넌스를 전면에 둔 포크
  https://developer.hashicorp.com/vault	https://openbao.org/