OpenBao 유지 관리

OpenBao의 백업 및 복원, 복구 키 관리, 인증 복구 및 데이터 초기화 절차를 설명합니다.

Status: Beta Geo 장애 조치에 대해서는 Geo 재해 복구 를 참조하세요. OpenBao 백업 및 복원 # OpenBao는 PostgreSQL의 별도 논리 데이터베이스에 데이터를 저장합니다. 장애 발생 후 시크릿을 복원할 수 있도록 이 데이터베이스를 정기적인 GitLab 백업과 함께 백업하세요. OpenBao에 특화된 자세한 백업 및 복원 절차는 OpenBao 백업 문서 를 참조하세요. 복구 키 관리 # 복구 키 저장, 조회, 루트 토큰 생성 등 OpenBao 복구 키 관리에 대한 정보는 복구 키 관리 를 참조하세요. OpenBao 인증 복구 # JWT aud (audience) 클레임과 저장된 bound_audiences 값이 서로 달라진 경우 OpenBao 인증을 복구해야 할 수 있습니다. 저장된 시크릿이 보존되는 복구 키를 사용하여 인증을 재구성하는 방법을 먼저 시도하세요. 모든 저장된 시크릿이 삭제되므로 OpenBao 데이터 초기화는 최후의 수단으로만 사용하세요. 복구 키로 인증 재구성 # 이 방법은 저장된 모든 시크릿을 보존하지만 복구 키가 필요합니다. 복구 키에서 임시 루트 토큰을 생성합니다. 절차는 복구 키에서 루트 토큰 생성 을 참조하세요. 현재 인증 권한을 읽어 전체 구성을 확인합니다: OPENBAO_POD=$(kubectl get pods -n gitlab -l app.kubernetes.io/name=openbao -o name | head -1) kubectl exec -n gitlab "$OPENBAO_POD" -c openbao-server -- \ sh -c "BAO_ADDR=http://127.0.0.1:8200 BAO_TOKEN=<root_token> bao read auth/gitlab_rails_jwt/role/app" 수정된 bound_audiences 와 이전 단계에서 얻은 다른 모든 필드를 사용하여 권한을 다시 적용합니다. 업데이트 시 OpenBao는 생략된 필드를 기본값으로 초기화하므로 요청에 전체 구성이 포함되어야 합니다. 중요한 사항: role_type 필드는 기본값이 oidc 이므로 role_type=jwt 를 반드시 포함해야 합니다. 그렇지 않으면 권한이 손상됩니다. claim_mappings 필드는 생략하면 빈 값으로 초기화되어 인가가 손상됩니다. 이전 단계에서 반환된 동일한 매핑을 포함하세요. bound_claims 와 claim_mappings 는 맵이므로 bao write <path> - 로 표준 입력을 통해 JSON 형식으로 구성을 제공하세요. <your-domain> 을 OpenBao 도메인으로 교체하고, claim_mappings 및 다른 값은 이전 단계에서 반환된 값으로 교체하세요: kubectl exec -i -n gitlab "$OPENBAO_POD" -c openbao-server -- \ sh -c "BAO_ADDR=http://127.0.0.1:8200 BAO_TOKEN=<root_token> bao write auth/