Configure el almacenamiento de secretos

Para configurar la autenticación OIDC JWT y Kubernetes:

1. Ejecute el siguiente comando para habilitar la autenticación OIDC JWT para la ruta de montaje. Si se configuran varios clústeres de Kubernetes, se debe habilitar la autenticación OIDC JWT 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 clúster kube01.internal.io:

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

3. Ejecuta 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 el URL en el documento de descubrimiento OIDC en .well-known/openid-configuration.

   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 se especifica en pasos posteriores.

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

5. Ejecuta el comando para crear un rol de HashiCorp Vault y enlazar una cuenta de servicio de Kubernetes a este rol, lo que restringe el acceso de la cuenta de servicio dentro del HashiCorp Vault.

   El siguiente comando crea el rol jwt-kube01-system para el público vault del tipo JWT (OIDC). El comando especifica la reclamación de usuario sub, y la cuenta de servicio de Kubernetes default en el namespace mongodb-atlas-system como el sujeto vinculado. Este comando vincula el rol al conjunto de permisos de la política external-secrets 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 rol jwt-kube01-default para el público vault del tipo JWT (OIDC). Este comando especifica el reclamo de usuario sub y la cuenta de servicio de Kubernetes default en el namespace default como el sujeto vinculado. Este comando vincula el rol al conjunto de permisos de la política external-secrets 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úrate 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 las credenciales OIDC JWT de la cuenta de servicio del sistema.

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

   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 tus credenciales OIDC JWT para la cuenta de servicio por defecto.

Para configurar la autenticación de Kubernetes:

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

   vault auth enable -path=jwt-kube01 kubernetes

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

2. Crea directivas que permitan el acceso a los secretos que deseas 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. Ejecuta los comandos para confiar en el clúster de Kubernetes y utilizar 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. Ejecuta el comando para crear un rol de HashiCorp Vault y enlazar una cuenta de servicio de Kubernetes a este rol, lo que restringe el acceso de la cuenta de servicio dentro del 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 secretos de KV v2 bajo la ruta kube01/secrets-store:

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

5. Asegura 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. Garantizar que la autenticación de Kubernetes se ejecute correctamente para la cuenta por defecto:

   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 External Secrets Operator:

1. Implementa 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. Implementa 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. Despliegue 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 Atlas Kubernetes Operator pueda hallar el secreto que crea External Secrets operador.

   Antes de ejecutar el siguiente comando, asegúrese de que HashiCorp Vault tenga el secreto poblado 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 referencia el secreto que contiene las credenciales de usuario de base de datos. Debes configurar spec.target.template.metadata.labels en atlas.mongodb.com/type con el valor credentials para que el Atlas Kubernetes Operator pueda encontrar el secreto que crea el External Secrets Operator.

   Antes de ejecutar el siguiente comando, asegura que HashiCorp Vault tiene el secreto poblado en la ruta Kv V2 secret/data/kube01/external-secrets/db-user con la propiedad password.

   $ 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úrate de que los secretos se devuelvan como se espera cuando ejecutes 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. Despliegue el recurso personalizado SecretProviderClass en el namespace mongodb-atlas-system. Debe configurar spec.secretObjects.labels en atlas.mongodb.com/type con el valor credentials para que Atlas Kubernetes Operator encuentre el secreto que Secrets Store CSI crea.

   Antes de ejecutar el siguiente comando, asegúrese de que HashiCorp Vault tenga el secreto poblado 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. Ejecuta 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 referencia el secreto que contiene las credenciales de usuario de base de datos. Debe establecer spec.target.template.metadata.labels en atlas.mongodb.com/type con el valor credentials para que el Atlas Kubernetes Operator encuentre el secreto que crea el Secrets Store CSI.

   Antes de ejecutar el siguiente comando, asegura que HashiCorp Vault tiene el secreto poblado en la ruta Kv V2 secret/data/kube01/external-secrets/db-user con la propiedad password.

   $ 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, el cual asegura que el driver Secrets Store CSI obtenga las credenciales de 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úrate de que los secretos se devuelvan como se espera cuando ejecutes los siguientes comandos:

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

   $ kubectl get -n default secrets/dbuser-password