Docs Menu
Docs Home
/
MongoDB Enterprise Kubernetes 연산자
/
보안

시크릿 스토리지 구성

이 페이지의 내용

  • 지원되는 비밀 저장 도구
  • 저장할 수 있는 시크릿
  • 제한 사항
  • 시크릿 스토리지 도구 설정
  • 다음 단계

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 Enterprise Kubernetes Operator 문서의 모든 Kubernetes 튜토리얼은 시크릿을 사용합니다. 기본값. Kubernetes 시크릿 을 사용하려면 Kubernetes Operator에 대한 시크릿을 저장 하려면 Kubernetes Operator 설치를 진행하고 튜토리얼의 단계를 따르세요.

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

전제 조건

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

  • Vault 인스턴스를 설정합니다. Kubernetes Operator가 실행 중인 Kubernetes 클러스터는 Vault 인스턴스에 대한 액세스 권한이 있어야 합니다.

    참고

    Vault가 개발 모드 에서 실행 되고 있지 않은지 확인합니다. Vault 설치가 해당 구성 권장 사항을 준수하는지 확인합니다.

  • Kubernetes 인증 활성화 Vault 인스턴스의 경우. 이렇게 하면 Vault로 인증할 수 있습니다.

  • Vault Agent 사이드카 인젝터 배포 Kubernetes 클러스터에서. 이를 통해 Vault의 시크릿을 Kubernetes Pod에 주입할 수 있습니다.

  • 4개의 Vault 정책 파일 다운로드 Kubernetes Operator, MongoDB 데이터베이스, MongoDB Ops Manager 및 AppDB의 경우.

  • 역할만들기 mongodbenterprise 라는 이름으로 Vault에 있습니다. Kubernetes Operator의 시크릿 구성은 이 역할 의 존재 여부와 정확한 이름에 따라 달라집니다.

절차

1

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

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

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

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

2

볼트 역할을 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}
3

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

이 단계에서 명령을 실행 하기 전에 Vault 역할 을 생성 했는지 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
4

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용 .

5

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}
6

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

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

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

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

다음 명령을 실행하여 ConfigMap 을 만듭니다. Vault 정보 포함:

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

이렇게 하면 ConfigMap 이 secret-configuration 생성됩니다. 이름은 입니다. 이 ConfigMap 파일의 내용을 config 포함합니다.

8

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

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

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

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

참고

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

다음 단계

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

돌아가기

인증 활성화

다음

Vault에 시크릿 생성