kalee's 공부방

OpenBao 서버가 왜 잠긴 채로 시작하는지 짚고, init, unseal, 자동 unseal seal 스탠자, recovery key, rotate-keys와 rotate, generate-root, seal migration, 2.6의 네임스페이스 seal까지 운영자가 실제로 하는 일을 순서대로 다룹니다. 2026년 11월 기준 OpenBao 2.7 공식 문서를 바탕으로 했고, Vault와의 관계는 짧게만 언급합니다.

Show Notes

OpenBao 서버가 왜 잠긴 채로 시작하는지 짚고, init, unseal, 자동 unseal seal 스탠자, recovery key, rotate-keys와 rotate, generate-root, seal migration, 2.6의 네임스페이스 seal까지 운영자가 실제로 하는 일을 순서대로 다룹니다. 2026년 11월 기준 OpenBao 2.7 공식 문서를 바탕으로 했고, Vault와의 관계는 짧게만 언급합니다.

전체 대본 보기

참고 자료

이 에피소드의 음성은 TTS로 합성되었습니다.

What is kalee's 공부방?

kalee 가 공부하고자 하는 내용들을 두서없이 업로드하는 팟캐스트

진행자: 안녕하세요. 오늘은 OpenBao를 실제로 운영할 때 가장 먼저 부딪히는 문제를 다뤄 볼게요. 서버를 띄웠는데 아무것도 안 되는 상태, 바로 sealed 상태예요.

전문가: 네. 개발 모드로만 써 본 분들은 이 상태를 거의 못 보셨을 거예요. 개발 모드는 자동으로 초기화되고 unseal까지 된 채로 뜨거든요.

전문가: 대신 데이터가 메모리에만 있어서 재시작하면 다 사라지고, 공식 문서는 개발 모드를 절대 운영에 쓰지 말라고 아주 강하게 적어 놨어요.

진행자: 그러니까 운영 모드로 처음 띄우는 순간 처음 마주치는 벽이네요. 오늘은 원리는 꼭 필요한 만큼만 짚고, 초기화부터 unseal, 자동 unseal, 키 회전, seal 방식 전환, 그리고 2.6에서 새로 들어온 네임스페이스 seal까지 실제 사용법 위주로 가 볼게요.

전문가: 기준은 2026년 11월 현재 공식 문서, 버전으로는 2.7 계열이에요.

진행자: 시작 전에 하나만요. OpenBao 하면 Vault 얘기가 꼭 나오잖아요. 오늘 내용과 어떤 관계예요?

전문가: 짧게만 말씀드리면, OpenBao는 HashiCorp Vault의 커뮤니티 포크예요. 2023년에 HashiCorp가 라이선스를 Business Source License로 바꾼 게 계기였고, 지금은 Linux Foundation 산하 OpenSSF에서 MPL 2.0 라이선스로 관리돼요.

전문가: 공식 이전 가이드가 Vault 1.14.1의 Raft 데이터를 그대로 이어 쓰는 절차를 다룰 정도로 저장 구조와 Shamir unseal 모델을 공유해요.

진행자: 그럼 Vault를 써 본 분은 오늘 내용이 익숙하겠네요.

전문가: 네. 명령어가 vault 대신 bao로 시작하고 토큰 접두사가 다른 정도라서, 오늘 얘기는 대부분 그대로 통한다고 보시면 돼요.

진행자: 그럼 용어부터 정리하고 갈게요. 오늘 KMS, HSM 같은 약어가 계속 나올 텐데, 하나씩 풀어 주세요.

전문가: KMS는 Key Management Service, 클라우드에서 제공하는 키 관리 서비스예요. HSM은 Hardware Security Module, 키를 하드웨어 안에 가둬 두는 보안 장비고요.

진행자: PGP랑 OTP도 나오죠?

전문가: PGP는 Pretty Good Privacy, 공개키로 암호화하는 도구예요. OTP는 One-Time Password, 한 번만 쓰는 비밀번호고요. HA는 High Availability, 고가용성이요.

진행자: 그리고 제일 중요한 Shamir요.

전문가: Shamir's Secret Sharing, 샤미르 비밀 분산이에요. 비밀 하나를 여러 조각으로 나눠서, 정해진 수 이상의 조각이 모여야만 원래 비밀을 복원할 수 있게 하는 방식이에요. 이 정해진 수를 임계값, threshold라고 불러요.

진행자: 자, 그럼 본론이요. 서버가 왜 굳이 잠긴 채로 깨어나는 거예요?

전문가: OpenBao가 저장소에 쓰는 데이터는 전부 암호화돼 있어요. 그리고 OpenBao는 저장소 자체를 신뢰하지 않아요. 저장소는 barrier라는 암호화 계층 바깥에 있어서, 누가 저장소에 접근해도 암호문만 얻게 돼요.

전문가: 열쇠가 세 겹이에요. 데이터를 암호화하는 키들이 keyring에 있고, 그 keyring을 root key가 암호화하고, root key를 다시 unseal key가 암호화해요.

진행자: 금고 안에 금고가 있는 셈이네요.

전문가: 맞아요. 서버가 막 시작하면 저장소에 손은 닿는데 맨 바깥 열쇠가 없어서 아무것도 못 풀어요. 그래서 인증도, 마운트 관리도 거의 다 막혀요. 이 상태가 sealed이고, unseal은 결국 root key에 접근하는 과정이에요.

전문가: unseal이 끝나야 audit 장치, 인증 방법, 시크릿 엔진을 불러와요.

진행자: 한 번 열면 계속 열려 있어요?

전문가: 다시 seal하거나, 재시작하거나, 복구 불가능한 저장소 오류가 날 때까지는 열려 있어요. 거꾸로 말하면 재시작할 때마다 다시 열어야 한다는 뜻이에요.

진행자: 그럼 실제로 해 볼게요. 운영 모드 서버를 처음 띄우면 제일 먼저 뭘 해요?

전문가: bao operator init이에요. 저장소를 데이터 받을 수 있는 상태로 준비하는 명령이에요. 이미 초기화된 클러스터에는 실행이 안 되고, HA 구성이면 저장소를 공유하니까 서버 하나에서만 하면 돼요.

전문가: init이 root key를 만들어서 암호화한 채 저장소에 두고, unseal key를 Shamir로 쪼개서 조각들을 출력해 줘요. 기본값은 조각 다섯 개, 임계값 세 개예요.

진행자: 다섯 개 중에 세 개가 모이면 열린다. 이 숫자는 어떻게 정해요?

전문가: 문서가 정답을 주진 않아요. 다만 규칙은 하나 있어요. 임계값이 조각 수보다 클 수는 없어요.

전문가: 제 생각엔 이렇게 보시면 돼요. 임계값이 낮으면 재시작할 때 편하지만 몇 명만 공모해도 열 수 있어요. 높으면 안전하지만 새벽 장애 때 사람 모으기가 힘들어요. 조각 수는 휴가나 퇴사를 감안해서 임계값보다 여유 있게 두는 거고요.

진행자: 출력된 조각은 화면에 그냥 나오는 거예요?

전문가: 기본은 그래요. 그래서 pgp-keys 옵션을 써서 사람마다 다른 PGP 공개키를 지정하면, 각 조각이 그 사람 키로 암호화돼서 나와요. 지정하는 키 개수는 조각 수와 맞아야 하고요.

전문가: 같이 나오는 초기 루트 토큰도 root-token-pgp-key로 암호화해서 받을 수 있어요.

진행자: init 한 사람이 모든 조각을 평문으로 보는 상황을 피하는 거네요.

전문가: 네. 공식 빠른 시작 문서도 이 값들이 매우 민감하다고 경고하고, 조각을 보안 안 된 메모 앱에 붙여 두는 식의 지름길을 하지 말라고 해요. unseal key가 없으면 저장소를 영영 복호화할 수 없으니까요.

전문가: 자동화 팁도 하나 있어요. init에 status 옵션을 붙이면 종료 코드로 초기화 여부를 알려 줘요. 0이면 초기화됨, 2면 아직 안 됨, 1이면 오류예요.

진행자: 초기화했으면 이제 여는 거죠. unseal은 어떻게 해요?

전문가: bao operator unseal을 실행하면 조각 하나를 서버에 넣어요. 임계값만큼 모이면 열려요. 출력에 진행도가 나와서 지금 몇 개 들어갔는지 볼 수 있어요.

전문가: 조각은 한 번에 하나씩, 순서 상관없이, 서로 다른 기계에서 넣어도 돼요. 세 사람이 각자 자기 자리에서 넣으면 되는 거예요.

진행자: 명령에 조각을 바로 붙여서 넣어도 되나요?

전문가: 되긴 하는데 권장하지 않아요. 셸 history에 키가 남거든요. 인자 없이 실행하면 프롬프트가 뜨고 입력이 화면에 안 보여요. 그 방식을 쓰세요.

전문가: 중간에 잘못 넣었다 싶으면 reset 옵션으로 지금까지 넣은 걸 버리고 처음부터 할 수 있어요.

진행자: 클러스터면 한 번만 열면 되나요?

전문가: 아니요, 여기가 자주 놓치는 부분이에요. 노드마다 따로 unseal해야 해요. 노드가 세 대면 세 번 하는 거예요.

진행자: 열렸는지는 어떻게 확인해요?

전문가: bao status예요. sealed 상태여도 출력되고, 종료 코드가 0이면 열림, 2면 잠김, 1이면 오류예요. 그래서 헬스체크나 재시작 스크립트에 넣기 좋아요.

진행자: 반대로 일부러 잠글 수도 있어요?

전문가: bao operator seal이요. 메모리에 있던 root key를 버리고, 다시 unseal할 때까지 모든 요청에 응답하지 않아요. 이미 잠겨 있으면 아무 일도 안 하고, unseal이 진행 중이었다면 그 진행이 초기화돼요.

전문가: 재미있는 건 비대칭이에요. 열 때는 여러 사람의 조각이 필요한데, 닫는 건 root 권한을 가진 운영자 한 명이면 충분해요.

진행자: 침해가 의심되면 한 명이 바로 비상 브레이크를 당길 수 있다는 거네요.

전문가: 그렇게 쓸 수 있다는 게 이 비대칭의 의미라고 봐요. 대신 다시 열려면 조각 보유자들을 모아야 하니, 당기기 전에 그 비용도 생각해야죠.

진행자: init 때 같이 받은 루트 토큰은 어떻게 다뤄요?

전문가: 초기 루트 토큰은 만료가 없어요. 공식 문서 권고는 분명해요. 인증 방법과 정책을 구성하는 초기 설정, 그리고 비상시에만 쓰고, 필요 없어지면 즉시 폐기하라는 거예요.

전문가: 운영 환경에서는 루트 토큰이 살아 있는 동안 여러 사람이 터미널을 같이 지켜보라는 권고까지 있어요.

진행자: 폐기했는데 나중에 또 필요하면요?

전문가: bao operator generate-root로 다시 만들어요. 조각 보유자 정족수가 모여야 해요. 일회용 비밀번호를 만들고, 시작하고, 조각을 차례로 넣고, 마지막에 그 비밀번호로 토큰을 풀어내는 순서예요.

전문가: 2.6부터는 이 명령이 인증이 필요한 새 엔드포인트를 써요. 예전 인증 없던 엔드포인트는 deprecated가 됐고요.

진행자: 그런데 재시작할 때마다 세 사람을 모아야 한다면, 쿠버네티스 위에서 파드가 수시로 재시작되는 환경에선 너무 힘들 것 같아요.

전문가: 그래서 자동 unseal이 있어요. 서버 설정 파일에 seal 스탠자를 넣으면 기본 Shamir 대신 HSM이나 클라우드 KMS 같은 외부 수단이 root key를 암호화하고 풀어 줘요.

전문가: 2.7 문서 기준으로 AWS, Azure, GCP, OCI 같은 클라우드 KMS, PKCS#11 HSM, KMIP, 다른 OpenBao의 Transit 엔진, 그리고 Static Key까지 목록에 있어요.

진행자: 2.6, 2.7에서 이쪽도 바뀌었다고 들었어요.

전문가: 네. 2.6부터 kms라는 플러그인 타입이 생겨서, 자동 unseal 수단을 외부 바이너리로 붙일 수 있어요. 설정 파일에 플러그인을 등록하고 seal 스탠자 이름을 맞추면 돼요. 같은 제공자가 내장과 플러그인 둘 다 있으면 플러그인이 우선이고요.

전문가: 이 플러그인은 죽어도 인스턴스 전체를 재시작하지 않고 자동으로 다시 떠요.

전문가: 그리고 2.6에서 클라우드 KMS와 PKCS#11 내장 seal들이 제거 예정으로 표시됐고, 2.7에서는 별도 HSM 배포판이 없어지고 벤더 자동 unseal 수단이 플러그인으로 옮겨 갔어요.

진행자: 업그레이드할 때 설정을 꼭 확인해야겠네요.

전문가: 네. 설정 파일과 환경 변수에 같은 값이 있으면 환경 변수가 이긴다는 것도 알아 두시면 좋아요. seal 헬스체크도 기본으로 켜져 있어서, 실패하면 서버 로그에 경고가 남아요.

진행자: Static Key는 뭐예요? 이름만 들으면 좀 불안한데요.

전문가: 설정에 32바이트 키를 직접 넣거나, 환경 변수나 파일 경로로 참조하게 하는 자동 unseal이에요. 외부 KMS가 필요 없죠.

전문가: 문서도 신중하라고 해요. 이미 믿을 만한 다른 시크릿 관리자가 있어서 거기서 키를 안전하게 주입할 수 있을 때만 권장한대요.

진행자: 그럼 Shamir와 자동 unseal, 어떻게 골라요?

전문가: Shamir는 외부 의존이 없고 운영자가 직접 통제해요. 대신 수동이라 자동화가 어렵고, 재시작마다 조각 보유자가 있어야 하죠.

전문가: 자동 unseal은 운영이 쉽고 자동화가 돼요. 대신 외부 seal에 강하게 묶여요. 문서에서 가장 무거운 경고가 여기 있어요. seal 수단이나 그 키가 영구 삭제되면, 백업이 있어도 클러스터를 복구할 수 없어요.

진행자: 백업으로도 안 된다고요?

전문가: 네. root key는 암호화된 채 저장소에 들어 있으니, 백업에 담긴 root key도 결국 그 seal 키가 있어야 풀린다고 이해하시면 돼요. 그래서 문서는 AWS Service Control Policy 같은 장치로 seal 키를 엄격히 통제하라고 권해요.

진행자: 쿠버네티스 DR 시리즈 6편에서 KMS 키를 지우면 클러스터 시크릿을 복구할 수 없다고 했던 것과 같은 얘기네요.

전문가: 같은 교훈이에요. 편의를 얻은 대신 위험이 사람 손에서 클라우드 키 한 개로 옮겨 간 거예요.

진행자: 자동 unseal을 쓰면 조각은 아예 없어지는 거예요?

전문가: 아니요. init 때 unseal key 대신 recovery key를 받아요. 기본값은 똑같이 다섯 개 중 세 개고요.

전문가: 여기서 가장 흔한 오해가 있어요. recovery key로는 unseal을 못 해요. root key를 풀 수 없거든요. KMS가 먹통이면 recovery key를 아무리 모아도 서버는 안 열려요.

진행자: 그럼 recovery key는 어디에 써요?

전문가: 루트 토큰을 새로 만들 때, unseal 키를 회전할 때 승인용으로, recovery key 자체를 회전할 때, 그리고 자동 unseal 환경에서 일부러 seal한 뒤 API로 다시 열 때 써요.

전문가: 그리고 init 때 recovery 조각 수를 0으로 주면 생성을 미룰 수 있는데, 문서가 일부러 당부해요. 필요해지기 한참 전에 만들어 두라고요.

진행자: 이제 키 회전이요. 조각 보유자 한 명이 퇴사하면 어떻게 해요?

전문가: bao operator rotate-keys예요. 2.4부터 있는 명령이고, 예전 이름은 rekey였는데 지금은 deprecated예요.

전문가: 새 조각 세트를 만들어 주고, 이때 조각 수나 임계값도 바꿀 수 있어요. 다운타임은 없어요. 대신 서버가 열려 있어야 하고, 기존 조각의 정족수가 필요해요.

진행자: 절차는요?

전문가: init 옵션으로 시작하면서 새 조각 수와 임계값을 정해요. 그다음 기존 보유자들이 차례로 조각을 넣는데, 매번 시작할 때 받은 nonce를 같이 넣어야 해요. 다 모이면 새 조각이 나와요. 중간에 그만두려면 cancel, 진행 상황은 status로 봐요.

전문가: 자동 unseal 환경이면 target을 recovery로 줘서 recovery key를 회전하고요.

진행자: rotate-keys랑 그냥 rotate가 따로 있던데, 헷갈려요.

전문가: 층이 달라요. rotate-keys는 금고 열쇠 조각을 바꾸는 거고, bao operator rotate는 금고 안에서 데이터를 암호화하는 키를 바꾸는 거예요. rotate는 keyring에 새 키를 추가하고, 새 데이터는 새 키로, 옛 데이터는 keyring에 남은 옛 키로 풀어요.

전문가: rotate도 온라인 작업이라 다운타임이 없고, 저장소를 공유하니 클러스터에서 한 번만 하면 돼요.

진행자: 사람이 바뀌면 rotate-keys, 데이터 키를 정기적으로 바꾸고 싶으면 rotate. 이렇게 기억하면 되겠네요.

진행자: 이미 Shamir로 운영 중인데 자동 unseal로 바꾸고 싶으면요?

전문가: seal migration이에요. Shamir에서 자동으로, 자동에서 Shamir로, 자동에서 다른 자동으로 다 가능해요. 다만 이건 다운타임 없이는 못 해요. 클러스터를 잠깐 내려야 해요.

전문가: 시작 전에 백업을 받고, 전환하는 동안은 옛 seal과 새 seal이 둘 다 살아 있어야 해요.

진행자: 순서대로 설명해 주세요.

전문가: 먼저 standby 노드 하나를 멈추고 설정을 바꿔요. Shamir에서 자동으로 가면 새 seal 스탠자를 추가하고, 자동에서 Shamir로 가면 옛 스탠자에 disabled를 true로 줘요. 자동에서 다른 자동이면 옛 걸 disabled로 두고 새 걸 추가하고요.

전문가: 그 노드를 재시작하고 unseal 명령에 migrate 옵션을 붙여서 조각을 넣어요. 다른 standby도 한 대씩 똑같이 해요. Raft를 쓴다면 정족수를 지키려고 한 대씩 하는 거예요.

전문가: 그다음 active 노드를 step-down시켜요. standby 하나가 active가 되고, 이 새 active가 실제 migration을 수행해요. 완료는 서버 로그로 확인해요.

전문가: 마지막으로 옛 active 노드는 새 seal 설정만 남겨서 띄우고, 모든 노드에서 옛 seal 설정을 지우면 끝이에요.

진행자: 기존 조각은 어떻게 돼요?

전문가: Shamir에서 자동으로 가면 기존 unseal 조각이 새 seal의 recovery key가 돼요. 반대로 자동에서 Shamir로 가면 recovery key가 Shamir unseal 조각이 되고요.

진행자: 마지막 기능이요. 2.6에서 네임스페이스 seal이 들어왔다고 하셨죠.

전문가: 네, 2.6.0이 2026년 7월 14일에 나왔고, 네임스페이스를 만들 때 Shamir seal 설정을 줄 수 있게 됐어요. 이런 네임스페이스는 전역 seal과 별개로 자기 keyring과 root key를 가져요.

전문가: 의미는 이거예요. 테넌트가 자기 네임스페이스를 seal하면 인스턴스 운영자도 그 데이터를 못 읽어요. 다른 테넌트에는 영향이 없고요.

진행자: 운영자를 믿지 않아도 되는 구조네요. 그냥 잠그는 lock 기능과는 뭐가 달라요?

전문가: lock은 API 요청만 막아요. seal은 메모리의 키를 버리는 암호학적 조치예요.

진행자: 사용법은요?

전문가: bao namespace create에 key-shares와 key-threshold를 주면 seal 가능한 네임스페이스가 만들어지고, 출력에 그 네임스페이스 전용 조각이 나와요. PGP로 조각을 암호화해 받을 수도 있어요.

전문가: 새로 만든 네임스페이스는 잠긴 상태로 시작해요. bao namespace unseal로 열고, bao namespace seal로 닫고, seal-status로 상태를 봐요.

전문가: 전역 seal과 다른 점이 하나 있어요. 네임스페이스는 노드마다가 아니라 클러스터당 한 번만 열면 돼요.

진행자: 재시작하면 어떻게 돼요?

전문가: 단일 노드면 재시작할 때 모든 네임스페이스가 잠겨요. 전역 unseal을 먼저 하고, 부모부터 차례로 열어야 해요. 다중 노드면 한 노드가 재시작해도 클러스터의 네임스페이스 상태가 유지되고, 그 노드가 동료에게서 상태를 받아 와요.

전문가: 그리고 부모가 잠기면 자기 seal을 가진 자식 네임스페이스도 같이 잠겨요.

전문가: 키 회전, keyring 회전, 루트 토큰 생성도 아까 말한 명령에 네임스페이스 옵션만 붙이면 돼요.

진행자: 주의할 점은요?

전문가: 두 가지예요. 아직 Shamir만 지원하고 자동 unseal은 계획 단계예요. 그리고 기존 네임스페이스를 나중에 seal 가능하게 바꾸는 변환이 안 돼요. 만들 때 정해야 해요.

전문가: 하나 더 붙이면, 잠긴 네임스페이스를 지우는 delete-sealed는 lease를 통한 외부 리소스 정리를 하지 않아요. 지우기 전에 그 점을 알고 있어야 해요.

진행자: 오늘 내용을 정리해 볼게요. 첫째, OpenBao는 저장소를 믿지 않기 때문에 잠긴 채로 깨어나고, 재시작할 때마다 노드별로 열어야 한다.

진행자: 둘째, Shamir는 사람에게, 자동 unseal은 KMS 키에 위험을 맡긴다. 자동 unseal에서 seal 키를 잃으면 백업으로도 복구가 안 되고, recovery key로는 서버를 못 연다.

진행자: 셋째, 사람이 바뀌면 rotate-keys, 데이터 키는 rotate, 방식을 바꾸려면 다운타임을 잡고 seal migration. 그리고 2.6부터는 테넌트별로 자기 금고를 잠글 수 있다.

전문가: 하나만 덧붙이면, 실제 장애는 키를 몰라서보다 재시작 런북이 없어서 커지는 경우가 많다고 봐요. 누가 조각을 갖고 있는지, 새벽에 몇 명을 깨워야 하는지를 미리 적어 두세요.

진행자: 오늘 참고한 공식 문서와 릴리스 노트 링크는 설명란에 정리해 뒀어요. 들어 주셔서 고맙습니다.