CNCF 블로그는 OpenBao와 CloudNativePG를 결합하여 Kubernetes에서 오픈 소스 시크릿 관리 스택을 구축하는 운영 방법을 소개한다. OpenBao는 Linux Foundation 산하의 HashiCorp Vault 오픈 소스 포크이며, CloudNativePG는 PostgreSQL 클러스터를 자동 복구, 동기 복제 및 인증서 기반 인증을 지원하는 서비스로 전환한다. 이 방법은 CNCF 졸업 프로젝트인 Kubernetes와 CNCF 기술 감독 위원회의 평가를 거쳐 Incubation 단계로 이동하는 절차가 진행 중인 Sandbox 프로젝트인 CloudNativePG를 활용한다.
핵심 아이디어는 PostgreSQL을 단순한 저장소로 사용하는 데 그치지 않고, 특정 클라우드 제공업체의 독점 데이터베이스에 의존하지 않으면서 OpenBao가 높은 유연성을 갖춘 PostgreSQL 백엔드에 의존하도록 만드는 것이다. 이 방법은 세 개의 CloudNativePG 인스턴스를 사용하고 정족수 기반 동기 복제를 구성하므로, 데이터 내구성을 보장하려면 동기 대기 복제본 하나만 사용 가능하면 된다. 반대로 필요한 내구성 조건을 충족하는 대기 복제본이 없으면 쓰기 작업이 중단될 수 있다.
설계에서 달라지는 점
OpenBao는 PostgreSQL 네이티브 스토리지를 사용하며, ha_enabled = true 옵션을 통해 고가용성 잠금 테이블을 활성화한다. 이 설정은 데이터를 저장하는 openbao_kv_store 테이블과 고가용성 잠금 레코드를 보관하는 openbao_ha_locks 테이블을 생성한다. 이 방법은 모든 상태가 CloudNativePG에 남아 있어야 하므로 OpenBao 스키마의 기본 로컬 스토리지를 비활성화한다.
CloudNativePG는 세 개의 인스턴스로 구성된 PostgreSQL 클러스터를 실행하며, 노드 선택기, 톨러레이션 및 파드 안티어피니티 제약 조건을 사용하여 전용 노드에 배치하고 별도의 장애 도메인에 분산한다. 이 방법은 고정 이미지 태그를 직접 작성하는 대신 PostgreSQL 18의 슬림 버전을 지정하는 이미지 카탈로그를 사용하며, SHA 다이제스트로 고정된 보안 이미지가 사용된 테스트 상태도 보여 준다.
비밀번호 없는 인증
이 방법의 가장 중요한 측면 중 하나는 OpenBao와 데이터베이스 간 연결에서 비밀번호를 제거하는 것이다. CloudNativePG는 스키마를 소유하는 역할과 openbao-rw라는 제한된 실행 역할을 위한 DatabaseRole 객체를 생성하며, 두 역할 모두 TLS 클라이언트 인증서를 받는다. pg_hba 규칙은 이 두 역할에 TLS 연결과 클라이언트 인증서를 사용하도록 강제하고, 암호화되지 않은 연결은 거부한다.
이 세부 사항은 인증서 생성만으로는 자동으로 사용이 강제되지 않기 때문에 중요하다. 각 연결에서 인증서, 비밀번호 또는 거부 중 무엇을 사용할지는 PostgreSQL 규칙이 결정한다. 또한 이 방법은 컨테이너에 마운트된 시크릿 파일의 권한을 0640으로 설정한다. libpq는 기본값인 0644로 마운트되어 그룹 또는 모든 사용자가 읽을 수 있는 개인 키를 거부하기 때문이다.
자료에 따르면 DatabaseRole은 현재 테이블 수준의 권한 부여를 관리하지 않으므로, 일회성 Job이 테이블을 생성하고 제한된 역할에 SELECT, INSERT, UPDATE 및 DELETE 권한을 부여하는 명령을 실행한다. 또한 이 Job은 PUBLIC에서 CONNECT 권한을 취소하고 PUBLIC에서 public 스키마 사용 권한을 취소한 다음, openbao-rw에 필요한 최소 권한을 다시 부여한다. OpenBao 설정에서는 skip_create_table 옵션을 활성화하여 제한된 실행 역할이 직접 테이블을 생성하려 하지 않도록 한다.
Kubernetes 운영자에게 이것이 실제로 의미하는 것
이 방법은 사전에 CloudNativePG 설정이 포함된 6노드 Kind 클러스터를 생성하는 cnpg-playground 저장소를 사용하여 로컬에서 테스트할 수 있는 경로를 제공한다. 테스트에는 Docker, Kind, Helm 및 kubectl이 필요하다. 그러나 테스트 환경의 노드 배치는 중요한 제약을 만든다. 전용으로 라벨이 지정된 PostgreSQL 노드가 있고, 강제 어피니티를 적용하여 OpenBao 복제본 세 개를 배치할 수 있는 일반 노드는 두 개만 남기 때문이다. 따라서 이 방법은 Kind 환경에서 OpenBao가 일시적으로 컨트롤 플레인 노드를 사용할 수 있도록 허용하지만, 이 톨러레이션을 운영 환경으로 옮기지 말라고 명시적으로 경고한다. 라벨이 지정되지 않은 워커 노드가 세 개 있는 운영 클러스터에서는 이러한 처리가 필요하지 않다.
OpenBao 차트를 설치한 후에는 각 인스턴스를 개별적으로 초기화하고, 5개 중 필요한 Shamir 키 3개를 사용하여 각 인스턴스의 봉인을 해제해야 한다. 첫 번째 인스턴스의 봉인을 해제해도 다른 두 인스턴스의 봉인이 해제되지는 않는다. 또한 기본 StatefulSet 정책인 OrderedReady는 이전 인스턴스가 준비될 때까지 다음 인스턴스의 생성을 지연시킨다. 따라서 봉인 해제 키와 루트 토큰을 안전하게 보관한 뒤 각 인스턴스에 순서대로 키를 입력해야 한다.
초기화 후 OpenBao는 부트스트랩 상태와 키를 openbao_kv_store 테이블에 저장하며, 테스트 시크릿 값은 PostgreSQL 테이블에 직접 접근하더라도 평문이 아닌 BYTEA 유형의 암호화된 데이터로 저장된다. 자료는 제한된 PostgreSQL 역할을 사용하여 KV v2로 시크릿을 쓰고 읽는 테스트가 성공했음을 확인한다.
운영상의 제약과 이 방법에서 다루지 않은 사항
CloudNativePG 측에서는 인증서가 자동으로 갱신된다. CNPG 클라이언트 인증서의 유효 기간은 90일이며, 일반적으로 만료 약 1주일 전에 갱신된다. 그러나 OpenBao는 인증서 파일을 자동으로 다시 읽지 않는다. PostgreSQL 스토리지 인터페이스가 프로세스 시작 시 연결 풀을 열기 때문이다. 따라서 갱신 후 OpenBao 인스턴스를 점진적으로 재시작하도록 계획해야 하며, 기존 인증서가 만료되기 전 83일의 갱신 기간 안에 이를 수행하는 것이 바람직하다.
또한 Kubernetes 클러스터 내부의 고가용성이 완전한 재해 복구 계획을 의미하는 것은 아니다. 이 방법은 전체 클러스터 손실에 대비한 백업이나 복구를 자동으로 생성하지 않는다. 운영 환경에서는 Amazon S3, Google Cloud Storage 또는 Azure Blob Storage와 같은 객체 스토리지와 함께 Barman Cloud Plugin을 추가하고, WAL 및 기본 백업을 보관하며 특정 시점 복구를 활성화하기 위해 Backup 및 ScheduledBackup 리소스를 사용할 것을 자료는 권장한다. 전체 클러스터 손실에도 생존해야 하는 RTO 및 RPO 목표에는 두 번째 클러스터 또는 리전에 비동기 PostgreSQL 클러스터가 필요하다.