시크릿 스토리지 구성

MongoDB 엔터프라이즈 Kubernetes Operator는 더 이상 사용되지 않습니다. The new Kubernetes Operator용 MongoDB 컨트롤러 가 MongoDB 엔터프라이즈 Kubernetes Operator를 대체합니다. Kubernetes Operator용 컨트롤러의 첫 번째 버전은 Enterprise Kubernetes Operator 의 v1.33 버전과 기능적으로 동일합니다. 이 변경 사항에 대한 자세한 내용과 새 연산자로 마이그레이션하는 방법에 대한 지침은 첫 번째 새 버전의 출시 노트 를 참조하세요. MongoDB 엔터프라이즈 Kubernetes Operator의 향후 릴리스는 없을 예정입니다. 각 버전은 기존 1년 지원 정책에 따라 수명이 종료됩니다. 지속적인 지원 받으려면 Kubernetes Operator용 컨트롤러로 마이그레이션 하세요.

Kubernetes 연산자용 시크릿 스토리지 도구를 선택할 수 있습니다. 시크릿 스토리지 도구는 Kubernetes 연산자가 managed하는 구성 요소에 대한 민감한 정보를 안전하게 저장할 수 있는 장소입니다. 여기에는 MongoDB 데이터베이스, Ops Manager 및 AppDB에 대한 비밀이 포함됩니다.

시크릿 스토리지를 구성하면 Kubernetes 연산자는 이 도구에 액세스하고, 시크릿을 검색하고, 이를 사용하여 안전하게 연결을 설정합니다.

지원되는 비밀 저장 도구

Kubernetes 연산자는 다음과 같은 시크릿 스토리지 도구를 지원합니다.

Kubernetes : 민감한 정보를 시크릿 ( Kubernetes 용 내장 시크릿 저장 )로 저장 . Kubernetes 시크릿 은 인증 자격 증명을 저장하여 Kubernetes만 액세스할 수 있습니다.
HashiCorp Vault: 기밀 관리 위한 타사 서비스인 Vault에 민감한 정보를 저장 .

저장할 수 있는 시크릿

제한 사항에 나열된 것을 제외하고 MongoDB Enterprise Kubernetes Operator 설명서의 모든 시크릿에 대해 지원되는 모든 시크릿 저장 도구를 사용할 수 있습니다.

중요

구성 후 Kubernetes Operator는 제한 사항 에 나열된 시크릿을 제외한 모든 시크릿에 대해 선택한 시크릿 저장소 도구를 사용합니다. 시크릿 스토리지 도구를 혼합하여 사용할 수는 없습니다.

제한 사항

지원되는 시크릿 저장 도구에는 다음과 같은 제한 사항이 있습니다.

OpenShift 와 같은 일부 레지스트리는 리포지토리 에서 이미지를 가져오려면 imagePullSecrets 가 필요합니다. Kubernetes Operator는 HashiCorp Vault에서 imagePullSecrets를 제공할 수 없습니다. kubelet 이미지 자격 증명 제공자 지정 하여 대신 Kubernetes 사용하여 컨테이너 이미지 레지스트리에 대한 자격 증명 조회 할 수 있습니다.

시크릿 스토리지 도구 설정

비밀 저장소 도구를 설정하려면 다음 옵션 중 하나를 선택합니다.

이 MongoDB 엔터프라이즈 Kubernetes Operator 설명서의 모든 튜토리얼에서는 기본값으로 Kubernetes 시크릿 을 사용합니다. Kubernetes 시크릿 을 사용하여 Kubernetes Operator에 대한 시크릿을 저장 하려면 Kubernetes Operator 설치를 진행하고 튜토리얼의 단계를 따르세요.

HashiCorp Vault 를 사용하여 Kubernetes Operator에 대한 시크릿을 저장 하려면 다음 절차를 완료하세요.

전제 조건

시작하기 전에 반드시 해야 할 것은 다음과 같습니다.

Vault 인스턴스를 설정합니다. Kubernetes Operator가 실행 중인 Kubernetes 클러스터는 Vault 인스턴스에 대한 액세스 권한이 있어야 합니다.
참고
Vault가 개발 모드 에서 실행 있지 않은지, Vault 설치가 해당 구성 권장 사항을 준수하는지 확인하세요.
Vault 인스턴스에 대해 Kubernetes 인증을 활성화합니다. 이렇게 하면 Vault로 인증할 수 있습니다.
Kubernetes 클러스터에 Vault Agent 사이드카 인젝터를 배포합니다. 이를 통해 Vault의 시크릿을 Kubernetes Pod에 주입할 수 있습니다.
Kubernetes Operator, MongoDB database, MongoDB Ops Manager 및 AppDB에 대한 네 가지 Vault 정책 파일을 다운로드합니다.
Vault에서 라는이름으로 역할 mongodbenterprise 생성합니다. Kubernetes Operator의 시크릿 구성은 이 역할 의 존재 여부와 정확한 이름에 따라 달라집니다.

절차

Kubernetes Operator 및 해당 구성 요소에 대한 볼트 정책을 추가합니다.

다음 명령을 사용하여 Kubernetes Operator, MongoDB database, MongoDB Ops Manager 및 AppDB 리소스에 대한 정책을 Vault에 작성하고 변수를 표의 값으로 바꿉니다.

자리 표시자	설명
{PolicyName}	Vault에서 생성 중인 정책을 식별하는 사람이 읽을 수 있는 레이블입니다.
{PathToPolicyFile}	다운로드한 정책 파일 의 절대 경로입니다.

vault policy write {PolicyName} {PathToPolicyFile}

Vault에 추가하는 모든 리소스에 대해 명령을 반복합니다.

볼트 역할을 Kubernetes 연산자 및 해당 구성 요소에 대한 볼트 정책에 바인딩합니다.

다음 네 가지 명령을 사용하여 Kubernetes Operator, MongoDB database, MongoDB Ops Manager 및 AppDB 리소스에 대한 정책에 Vault 역할을 바인딩하고 변수를 표의 값으로 바꿉니다.

자리 표시자	설명
{OperatorPolicyName}	Vault에서 Kubernetes 연산자 정책을 식별하는 사람이 읽을 수 있는 레이블입니다.
{DatabasePolicyName}	Vault에서 MongoDB database 정책을 식별하는 사람이 읽을 수 있는 레이블입니다.
{OpsManagerPolicyName}	Vault에서 MongoDB Ops Manager 정책을 식별하는 사람이 읽을 수 있는 레이블입니다.
{AppDBPolicyName}	Vault에서 AppDB 정책을 식별하는 사람이 읽을 수 있는 레이블입니다.
{ServiceAccountNamespace}	포드에 바인딩된 서비스 계정의 네임스페이스 를 식별하는 레이블입니다.

vault write auth/kubernetes/role/{OperatorPolicyName}
bound_service_account_names=enterprise-operator bound_service_account_namespaces={ServiceAccountNamespace}

vault write auth/kubernetes/role/{DatabasePolicyName}
bound_service_account_names=mongodb-enterprise-database-pods bound_service_account_namespaces={ServiceAccountNamespace}

vault write auth/kubernetes/role/{OpsManagerPolicyName}
bound_service_account_names=mongodb-enterprise-ops-manager bound_service_account_namespaces={ServiceAccountNamespace}

vault write auth/kubernetes/role/{AppDBPolicyName}
bound_service_account_names=mongodb-enterprise-appdb bound_service_account_namespaces={ServiceAccountNamespace}

이러한 명령은 각 구성 요소의 pod가 해당 정책에 지정된 액세스 만 갖도록 합니다.

참고

이 단계에서는 Vault에 대한 Kubernetes Operator 액세스 권한을 부여합니다. Kubernetes Operator가 관리하지 않는 애플리케이션에서 Vault를 사용하려면 해당 애플리케이션에 대한 Vault 정책을 작성하고 바인딩해야 합니다.

이 단계의 명령을 조정하여 서비스 계정의 이름을 바꿔 다른 정책을 바인딩할 수 있습니다. 다른 애플리케이션이 Vault를 사용하도록 구성하려면 다음 명령에서 {ServiceAccountName}을 애플리케이션의 포드에 사용되는 서비스 계정으로 바꿉니다.

vault write auth/kubernetes/role/{PolicyName}
bound_service_account_names={ServiceAccountName} bound_service_account_namespaces={ServiceAccountNamespace}

Kubernetes 배포서버 파일 에 어노테이션을 추가합니다.

이 단계에서 명령을 실행 전에 라는 이름의 볼트 역할 생성했는지 mongodbenterprise 확인하세요.

Kubernetes Operator 배포서버 파일 의 spec.template.metadata.annotations 섹션에 강조 표시된 다음 줄을 추가합니다. 대부분의 사용자의 경우 이 파일의 이름은 mongodb-enterprise.yaml 또는 mongodb-enterprise-openshift.yaml 입니다.

참고

Helm을 사용하여 Kubernetes Operator를 설치하고 operator.vaultSecretBackend.enabled 를 true 로 설정한 경우, Kubernetes Operator는 다음 주석을 추가합니다. 다음 단계로 진행할 수 있습니다.

apiVersion: apps/v1
kind: Deployment
metadata:
   name: mongodb-enterprise-operator
   namespace: production
spec:
   replicas: 1
   template:
      metadata:
        annotations:
          vault.hashicorp.com/agent-inject: "true"
          vault.hashicorp.com/role: "mongodbenterprise"

TLS 모드 에서 Vault를 실행 연산자.vaultSecretBackend.tlsSecretRef 값을 지정한 경우, Kubernetes 연산자는 다음 주석을 추가합니다. 그렇지 않으면 다음과 같이 강조 표시된 줄을 파일 에 추가하고 {TLSSecret} 를 ca.crt 항목이 포함된 시크릿의 이름으로 바꿉니다. ca.crt 항목의 내용은 Vault TLS 인증서를 생성하는 데 사용된 CA 의 인증서와 일치해야 합니다.

        annotations:
          vault.hashicorp.com/agent-inject: "true"
          vault.hashicorp.com/role: "mongodbenterprise"
          vault.hashicorp.com/tls-secret: {TLSSecret}
          vault.hashicorp.com/ca-cert: /vault/tls/ca.crt

Kubernetes 에서 환경 변수를 정의합니다.

Kubernetes Operator 배포서버 파일 의 spec.env 섹션에 강조 표시된 다음 줄을 추가합니다. 대부분의 사용자의 경우 이 파일의 이름은 mongodb-enterprise.yaml 또는 mongodb-enterprise-openshift.yaml 입니다.

apiVersion: apps/v1
kind: Deployment
metadata:
   name: mongodb-enterprise-operator
   namespace: production
spec:
   env:
   - name: OPERATOR_ENV
     value: ENVIRONMENT_NAME
   - name: SECRET_BACKEND
     value: VAULT_BACKEND

이는 Kubernetes 의 Vault에 대한 환경 변수를 정의합니다.

Vault 구성 정보가 포함된 파일 을 생성합니다.

선호하는 텍스트 편집 애플리케이션 을 사용하여 config 이라는 파일 을 만듭니다. 다음 텍스트를 파일 에 붙여넣습니다.

apiVersion: v1
kind: ConfigMap
metadata:
  name: secret-configuration
  namespace: {Namespace}
data:
  VAULT_SERVER_ADDRESS: {VaultServerAddress}
  OPERATOR_SECRET_BASE_PATH: mongodbenterprise/operator
  DATABASE_SECRET_BASE_PATH: mongodbenterprise/database
  OPS_MANAGER_SECRET_BASE_PATH: mongodbenterprise/opsmanager
  APPDB_SECRET_BASE_PATH: mongodbenterprise/appdb

이 파일 의 경로는 기본값 경로입니다. Kubernetes Operator 구성을 사용자 지정한 경우 기본 경로로 바꿀 수 있습니다.

TLS 모드 에서 Vault를 실행 경우 파일 에 다음과 같이 강조 표시된 줄도 추가해야 합니다.

   OPS_MANAGER_SECRET_BASE_PATH: mongodbenterprise/opsmanager
   APPDB_SECRET_BASE_PATH: mongodbenterprise/appdb
   TLS_SECRET_REF: {TLSSecret}

Vault 구성 정보에서 자리 표시자를 바꿉니다.

config 파일 의 자리 표시자를 이 값으로 바꿉니다. .txt 파일 확장자를 .yaml 로 바꿔서 파일 을 YAML 파일 형식으로 저장합니다.

자리 표시자	설명
{Namespace}	Kubernetes Operator에 대해 생성한 네임스페이스 입니다. 기본값 네임스페이스 는 `mongodb` 입니다.
{VaultServerAddress}	Kubernetes Operator가 Vault에 연결하는 데 사용해야 하는 주소입니다.
{TLSSecret}	`ca.crt` 항목이 포함된 시크릿의 이름입니다. `ca.crt` 항목의 내용은 Vault TLS 인증서를 생성하는 데 사용된 CA 의 인증서와 일치해야 합니다.

볼트 구성으로 ConfigMap을 생성합니다.

볼트 정보가 포함된 ConfigMap 을 생성하려면 다음 명령을 실행합니다.

kubectl create configmap secret-configuration --from-file=config.yaml

그러면 라는 ConfigMap이 secret-configuration생성됩니다. 이 ConfigMap 에는 config 파일의 내용이 포함되어 있습니다.

자동으로 마이그레이션되지 않는 시크릿 수동 마이그레이션

다음 시크릿을 Vault에 저장 하려면 수동으로 마이그레이션 해야 합니다.

해당되는 경우 Kubernetes 시크릿 으로 저장된 연산자 자격 증명 을 포함하여 기존 사용자가 생성한 시크릿
Kubernetes Operator가 생성 하는 gen-key 시크릿
MongoDB Ops Manager 관리자 자격 증명/관리자 키 Kubernetes Operator가 생성하는
TLS 시크릿

시크릿을 수동으로 마이그레이션 하거나 생성하려면 Vault에 추가하세요. Vault에 추가한 후 Kubernetes 에서 제거 할 수 있습니다.

Kubernetes Operator가 생성한 다른 모든 시크릿은 자동으로 마이그레이션 되며, Kubernetes Operator는 새 시크릿에 Vault를 사용합니다. 사용자가 생성한 시크릿은 Vault에 추가되어야 합니다.

참고

cert-manager는 Kubernetes에서 삭제 경우 생성하는 Kubernetes 시크릿 을 자동으로 다시 생성합니다. 시크릿이 Kubernetes 에 저장되지 않도록 하려면 이러한 시크릿의 제거를 수동으로 관리 cert-manager 사용을 중지해야 합니다.

다음 단계

MongoDB Enterprise Kubernetes Operator용 시크릿 스토리지 도구를 구성한 후에는 다음을 수행할 수 있습니다.

돌아가기

인증 활성화

Vault에 시크릿 생성