Configure el almacenamiento de secretos

Para configurar la autenticación de OIDC JWT y Kubernetes:

1. Ejecute el siguiente comando para habilitar la autenticación JWT de OIDC para la ruta de montaje. Si configura varios clústeres de Kubernetes, debe habilitar la autenticación JWT de OIDC para la ruta de montaje de cada clúster.

   vault auth enable -path=jwt-kube01 jwt

2. Ejecute el siguiente comando para permitir el acceso no autenticado a las URL de descubrimiento de OIDC en el kube01.internal.io clúster:

   $ kubectl create clusterrolebinding oidc-reviewer  \
     --clusterrole=system:service-account-issuer-discovery \
     --group=system:unauthenticated

3. Ejecute el siguiente comando para indicar a HashiCorp Vault que confíe en el clúster. El emisor del clúster en https://kube01.internal.io/ debe coincidir con la URL del documento de descubrimiento de OIDC .well-known/openid-configuration en.

   curl https://kube01.internal.io/.well-known/openid-configuration | jq .issuer
   https://kube01.internal.io/
   vault write auth/jwt-kube01/config jwks_url="https://kube01.internal.io/openid/v1/jwks"

4. Crea las directivas que permiten el acceso a los secretos que deseas exponer al clúster.

   El siguiente ejemplo crea la política external-secrets que especificará en pasos posteriores.

   echo external-secrets-policy.hcl
   path "secret/data/kube01/external-secrets/*" {
     capabilities = ["read"]
   }

5. Ejecute el comando para crear un rol de HashiCorp Vault y vincular una cuenta de servicio de Kubernetes al rol, lo que restringe el acceso de la cuenta de servicio dentro de HashiCorp Vault.

   El siguiente comando crea el jwt-kube01-system rol de tipo JWT (OIDC) para la vault audiencia. El comando especifica la sub notificación de usuario y la default cuenta de servicio de Kubernetes en el mongodb-atlas-system espacio de nombres como sujeto enlazado. Este comando vincula el rol al external-secrets conjunto de permisos de la política dentro de HashiCorp Vault.

   vault write auth/jwt-kube01/role/jwt-kube01-system role_type="jwt" bound_audiences=vault \
     user_claim="sub" bound_subject="system:serviceaccount:mongodb-atlas-system:default" \
     policies="external-secrets"

6. Ejecute el comando para crear otro rol para que el External Secrets Operator acceda al namespace default.

   El siguiente comando crea el jwt-kube01-default rol de tipo JWT (OIDC) para la vault audiencia. Este comando especifica la sub notificación de usuario y la default cuenta de servicio de Kubernetes en el default espacio de nombres como sujeto enlazado. Este comando vincula el rol al external-secrets conjunto de permisos de políticas dentro de HashiCorp Vault.

   vault write auth/jwt-kube01/role/jwt-kube01-default role_type="jwt" bound_audiences=vault \
     user_claim="sub" bound_subject="system:serviceaccount:default:default" \
     policies="external-secrets"

7. Asegúrese de que la autenticación OIDC se ejecute correctamente para la cuenta de servicio del sistema:

   export TEST_JWT_TOKEN=$(kubectl -n mongodb-atlas-system create token default --audience "vault")
   vault write auth/jwt-kube01/login role=jwt-kube01-system jwt=$(TEST_JWT_TOKEN)

   Atlas Kubernetes Operator devuelve sus credenciales JWT de OIDC para la cuenta de servicio del sistema.

8. Asegúrese de que la autenticación OIDC se ejecute correctamente para la cuenta de servicio predeterminada:

   export TEST_JWT_TOKEN=$(kubectl -n default create token default --audience "vault")
   vault write auth/jwt-kube01/login role=jwt-kube01-default jwt=$(TEST_JWT_TOKEN)

   Atlas Kubernetes Operator devuelve sus credenciales JWT de OIDC para la cuenta de servicio predeterminada.

Para configurar la autenticación de Kubernetes:

1. Ejecute el siguiente comando para habilitar la autenticación de Kubernetes en la ruta de montaje. Si configura varios clústeres de Kubernetes, debe habilitar la autenticación de Kubernetes en la ruta de montaje de cada clúster.

   vault auth enable -path=jwt-kube01 kubernetes

   Cuando se instala con Helm, se configura automáticamente la vinculación de roles del clúster.

2. Cree políticas que permitan el acceso a los secretos que desea exponer al clúster.

   El siguiente ejemplo crea la política vault-secret utilizada en pasos posteriores. Utiliza vault, un secreto de Kubernetes vinculado a la cuenta de servicio HashiCorp Vault que configura el proveedor Helm Chart CSI.

   echo vault-secret.yaml
   apiVersion: v1
   kind: Secret
   metadata:
     name: vault
     annotations:
       kubernetes.io/service-account.name: vault
   type: kubernetes.io/service-account-token
   $ kubectl apply -f vault-secret.yaml

3. Ejecute los comandos para confiar en el clúster de Kubernetes y usar la autenticación de Kubernetes:

   export VAULT_JWT ?= $(shell kubectl get secret/vault -o jsonpath='{.data.token}' |base64 -d)

   vault write auth/k8s-kube01/config kubernetes_host="kube01.internal.io" token_reviewer_jwt=$(VAULT_JWT)

4. Ejecute el comando para crear un rol de HashiCorp Vault y vincular una cuenta de servicio de Kubernetes al rol, lo que restringe el acceso de la cuenta de servicio dentro de HashiCorp Vault.

   El siguiente comando crea el rol k8s-kube01 en auth/k8s-kube01 vinculado a la cuenta de servicio de Kubernetes en los namespaces default o mongodb-atlas-system. Este rol está vinculado a la política de permisos de secrets-store en HashiCorp Vault.

   vault write auth/k8s-kube01/role/k8s-kube01-role \
     bound_service_account_names=default,mongodb-atlas-operator \
     bound_service_account_namespaces=default,mongodb-atlas-system \
     policies=secrets-store

   Las políticas deben existir y permitir el acceso a los secretos. El siguiente ejemplo de política permite el acceso a los secretos KV v2 en la ruta kube01/secrets-store:

   path "secret/data/kube01/secrets-store/*" {
     capabilities = ["read"]
   }

5. Asegúrese de que la autenticación de Kubernetes se ejecute correctamente para la cuenta de servicio del sistema:

   export TEST_JWT_TOKEN=$( kubectl create -n mongodb-atlas-system token mongodb-atlas-operator)
   vault write auth/jwt-kube01/login role=jwt-kube01-system jwt=$(TEST_JWT_TOKEN)

6. Asegúrese de que la autenticación de Kubernetes se ejecute correctamente para la cuenta predeterminada:

   export TEST_JWT_TOKEN=$(kubectl -n default create token default)
   vault write auth/jwt-kube01/login role=jwt-kube01-default jwt=$(TEST_JWT_TOKEN)

Para aprovisionar secretos con el operador de secretos externos:

1. Implemente el recurso personalizado SecretStore para la cuenta de servicio default en el espacio de nombres mongodb-atlas-system:

   $ cat external-secrets/vault-system.yaml
   apiVersion: external-secrets.io/v1beta1
   kind: SecretStore
   metadata:
     name: vault-store
     namespace: mongodb-atlas-system
   spec:
     provider:
       vault:
         server: "https://vault.internal.io"
         path: "secret"
         version: "v2"
         auth:
           jwt:
             path: "jwt-kube01"
             role: "jwt-kube01-system"
             kubernetesServiceAccountToken:
               expirationSeconds: 600
               serviceAccountRef:
                 name: "default"
                 audiences:
                 - vault
   $ kubectl apply -f external-secrets/vault-system.yaml

2. Implemente el recurso personalizado SecretStore para la cuenta de servicio default en el espacio de nombres default:

   $ cat external-secrets/vault-default.yaml
   apiVersion: external-secrets.io/v1beta1
   kind: SecretStore
   metadata:
     name: vault-store
     namespace: default
   spec:
     provider:
       vault:
         server: "https://vault.internal.io"
         path: "secret"
         version: "v2"
         auth:
           jwt:
             path: "jwt-kube01"
             role: "jwt-role"
             kubernetesServiceAccountToken:
               expirationSeconds: 600
               serviceAccountRef:
                 name: "default"
                 audiences:
                 - vault
   $ kubectl apply -f external-secrets/vault-default.yaml

3. Implemente el recurso personalizado ExternalSecret que hace referencia al secreto que contiene la clave API. Debe establecer spec.target.template.metadata.labels en atlas.mongodb.com/type con el valor credentials para que el operador de Kubernetes de Atlas encuentre el secreto creado por el operador de secretos externos.

   Antes de ejecutar el siguiente comando, asegúrese de que HashiCorp Vault tenga el secreto rellenado en la ruta Kv V2 secret/data/kube01/external-secrets/atlas-account con las siguientes propiedades:

   • orgId

   • publicApiKey

   • privateApiKey

   $ cat external-secrets/atlas.yaml
   apiVersion: external-secrets.io/v1beta1
   kind: ExternalSecret
   metadata:
     name: atlas
     namespace: mongodb-atlas-system
   spec:
       refreshInterval: "15s"
       secretStoreRef:
         name: vault-store
         kind: SecretStore
       target:
         name: mongodb-atlas-operator-api-key
         template:
           metadata:
             labels:
               atlas.mongodb.com/type: credentials
       data:
       - secretKey: orgId
         remoteRef:
           key: secret/data/kube01/external-secrets/atlas-account
           property: orgId
       - secretKey: publicApiKey
         remoteRef:
           key: secret/data/kube01/external-secrets/atlas-account
           property: publicApiKey
       - secretKey: privateApiKey
         remoteRef:
           key: secret/data/kube01/external-secrets/atlas-account
           property: privateApiKey
     $ kubectl apply -f external-secrets/atlas.yaml

   Este comando crea el secreto mongodb-atlas-operator-api-key de Kubernetes en el namespace mongodb-atlas-system.

4. Implemente el recurso personalizado ExternalSecret que hace referencia al secreto que contiene las credenciales de usuario de la base de datos. Debe establecer spec.target.template.metadata.labels en atlas.mongodb.com/type con el valor credentials para que el operador de Kubernetes de Atlas encuentre el secreto creado por el operador de secretos externos.

   Antes de ejecutar el siguiente comando, asegúrese de que HashiCorp Vault tenga el secreto rellenado en la ruta Kv V2 secret/data/kube01/external-secrets/db-user con la password propiedad.

   $ cat external-secrets/dbuser.yaml
   apiVersion: external-secrets.io/v1beta1
   kind: ExternalSecret
   metadata:
     name: dbuser
     namespace: default
   spec:
       refreshInterval: "15s"
       secretStoreRef:
         name: vault-store
         kind: SecretStore
       target:
         name: dbuser-password
         template:
           metadata:
             labels:
               atlas.mongodb.com/type: credentials
       data:
       - secretKey: password
         remoteRef:
           key: secret/data/kube01/external-secrets/db-user
           property: password
     $ kubectl apply -f external-secrets/atlas.yaml

5. Asegúrese de que los secretos regresen como se espera cuando ejecute los siguientes comandos:

   $ kubectl get -n mongodb-atlas-system secrets/mongodb-atlas-operator-api-key

   $ kubectl get -n default secrets/dbuser-password

Para aprovisionar secretos con Secrets Store CSI:

1. Implemente el recurso personalizado SecretProviderClass en el espacio de nombres mongodb-atlas-system. Debe establecer spec.secretObjects.labels en atlas.mongodb.com/type con el valor credentials para que Atlas Kubernetes Operator encuentre el secreto que crea Secrets Store CSI.

   Antes de ejecutar el siguiente comando, asegúrese de que HashiCorp Vault tenga el secreto rellenado en la ruta Kv V2 secret/data/kube01/external-secrets/atlas-account con las siguientes propiedades:

   • orgId

   • publicApiKey

   • privateApiKey

   $ cat secrets-store/atlas.yaml
   apiVersion: secrets-store.csi.x-k8s.io/v1
   kind: SecretProviderClass
   metadata:
     name: atlas
     namespace: mongodb-atlas-system
   spec:
     provider: vault
     secretObjects:
     - data:
       - key: orgId
         objectName: atlas-org
       - key: publicApiKey
         objectName: atlas-pub-key
       - key: privateApiKey
         objectName: atlas-secret-key
       secretName: mongodb-atlas-operator-api-key
       type: Opaque
       labels:
         atlas.mongodb.com/type: credentials
     parameters:
       vaultAddress: https://vault.internal.io
       vaultKubernetesMountPath: k8s-kube01
       roleName: k8s-kube01-role
       objects: |
         - objectName: atlas-org
           secretPath: secret/data/kube01/secrets-store/atlas-account
           secretKey: orgId
         - objectName: atlas-pub-key
           secretPath: secret/data/kube01/secrets-store/atlas-account
           secretKey: publicApiKey
         - objectName: atlas-secret-key
           secretPath: secret/data/kube01/secrets-store/atlas-account
           secretKey: privateApiKey
   $ kubectl apply -f secrets-store/atlas.yaml

   Este comando crea el secreto mongodb-atlas-operator-api-key de Kubernetes en el namespace mongodb-atlas-system.

2. Ejecute el siguiente comando para agregar un pod que monte los secretos requeridos:

   $ cat secrets-store/ako-patch.yaml
     template:
       spec:
         containers:
         - name: system-secret-placeholder
           image: mongodb/atlas
           command: ["sleep", "infinity"]
           volumeMounts:
           - name: secrets-store-mount
             mountPath: "/mnt/secrets-store"
             readOnly: true
         volumes:
           - name: secrets-store-mount
             csi:
               driver: secrets-store.csi.k8s.io
               readOnly: true
               volumeAttributes:
                 secretProviderClass: atlas
   $ kubectl apply -f secrets-store/ako-patch.yaml

3. Implemente el recurso personalizado SecretProviderClass que hace referencia al secreto que contiene las credenciales de usuario de la base de datos. Debe establecer spec.target.template.metadata.labels en atlas.mongodb.com/type con el valor credentials para que el operador de Kubernetes de Atlas encuentre el secreto que crea el CSI del almacén de secretos.

   Antes de ejecutar el siguiente comando, asegúrese de que HashiCorp Vault tenga el secreto rellenado en la ruta Kv V2 secret/data/kube01/external-secrets/db-user con la password propiedad.

   $ cat external-secrets/dbuser.yaml
   apiVersion: external-secrets.io/v1beta1
   kind: SecretProviderClass
   metadata:
     name: dbuser
     namespace: default
   spec:
     provider: vault
     secretObjects:
     - data:
       - key: password
         objectName: dbuser
       secretName: dbuser-password
       type: Opaque
       labels:
         atlas.mongodb.com/type: credentials
    parameters:
       vaultAddress: https://vault.internal.io
       vaultKubernetesMountPath: k8s-kube01
       roleName: k8s-kube01-role
       objects: |
         - objectName: "dbuser"
           secretPath: "secret/data/kube01/secrets-store/db-user"
           secretKey: "password"
   $ kubectl apply -f secrets-store/dbuser.yaml

4. Ejecute el siguiente comando para crear el pod centinela secret-placeholder, que garantiza que el controlador CSI de Secrets Store obtenga las credenciales dbuser y las sincronice con Kubernetes:

   $ cat secrets-store/placeholder.yaml
   kind: Pod
   apiVersion: v1
   metadata:
     name: secret-placeholder
   spec:
     containers:
     - image: mongodb/atlas
       command: ["sleep", "infinity"]
       name: secret-placeholder
       volumeMounts:
       - name: secrets-store-mount
         mountPath: "/mnt/secrets-store"
         readOnly: true
     volumes:
       - name: secrets-store-mount
         csi:
           driver: secrets-store.csi.k8s.io
           readOnly: true
           volumeAttributes:
             secretProviderClass: dbuser
   $ kubectl apply -f secrets-store/placeholder.yaml

5. Asegúrese de que los secretos regresen como se espera cuando ejecute los siguientes comandos:

   $ kubectl get -n mongodb-atlas-system secrets/mongodb-atlas-operator-api-key

   $ kubectl get -n default secrets/dbuser-password