Configurar armazenamento secreto

Para configurar o token web OIDC JSON web token e a autenticação Kubernetes :

1. Execute o comando a seguir para habilitar a autenticação de token da web OIDC JSON para o caminho de montagem. Se você configurar vários clusters do Kubernetes , deverá ativar a autenticação de token da web OIDC JSON para o caminho de montagem de cada cluster.

   vault auth enable -path=jwt-kube01 jwt

2. Execute o seguinte comando para permitir o acesso não autenticado aos URLs de descoberta do OIDC no cluster kube01.internal.io :

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

3. Execute o seguinte comando para direcionar HashiCorp Vault a confiar no cluster. O emissor do cluster em https://kube01.internal.io/ deve corresponder à URL no documento de descoberta do OIDC em .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. Crie as políticas que permitem acesso aos segredos que você deseja expor ao cluster.

   O exemplo a seguir cria a política external-secrets que você especifica nas etapas posteriores.

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

5. Execute o comando para criar uma função do HashiCorp Vault e vincular uma conta de serviço do Kubernetes à função, que restringe o acesso da conta de serviço dentro do HashiCorp Vault.

   O comando a seguir cria a função jwt-kube01-system do tipo JSON web token (OIDC) para o público vault. O comando especifica a declaração de usuário sub e a conta de serviço default do Kubernetes no namespace mongodb-atlas-system como o assunto vinculado. Este comando vincula a função ao conjunto de permissões da política external-secrets no 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. Execute o comando default para criar outro role para o External Secrets Operator acessar o namespace .

   O comando a seguir cria a função jwt-kube01-default do tipo JSON web token (OIDC) para o público vault. Este comando especifica a declaração de usuário sub e a conta de serviço default do Kubernetes no namespace default como o assunto vinculado. Este comando vincula a função ao conjunto de permissões da política external-secrets no 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. Garanta que a autenticação OIDC seja executada com sucesso para a conta de serviço do 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 retorna suas credenciais de token da web OIDC JSON web token para a conta de serviço do sistema.

8. Garanta que a autenticação OIDC seja executada com sucesso para a conta de serviço padrão:

   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 retorna suas credenciais de token da web OIDC JSON web token para a conta de serviço padrão.

Para configurar a autenticação do Kubernetes:

1. Execute o comando a seguir para habilitar a autenticação do Kubernetes para o caminho de montagem. Se você configurar vários clusters Kubernetes, deverá habilitar a autenticação do Kubernetes para o caminho de montagem de cada cluster.

   vault auth enable -path=jwt-kube01 kubernetes

   Quando você instala com o Helm, ele configura automaticamente a vinculação de função do cluster.

2. Crie políticas que permitam acesso aos segredos que você deseja expor no cluster.

   O exemplo a seguir cria a política vault-secret usada nas etapas posteriores. Ele usa vault, um segredo do Kubernetes vinculado à conta de serviço HashiCorp Vault que o fornecedor Helm Chart CSI configura.

   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. Execute os comandos para confiar no cluster Kubernetes e usar a autenticação 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. Execute o comando para criar uma função do HashiCorp Vault e vincular uma conta de serviço do Kubernetes à função, que restringe o acesso da conta de serviço dentro do HashiCorp Vault.

   O comando a seguir cria a função k8s-kube01 no auth/k8s-kube01 vinculado à conta de serviço do Kubernetes nos namespaces default ou mongodb-atlas-system. Esta função está vinculada à política de permissões do secrets-store dentro 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

   As políticas devem existir e permitir acesso aos segredos. A política de exemplo a seguir permite acesso aos segredos KV v2 no caminho kube01/secrets-store :

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

5. Verifique se a autenticação do Kubernetes é executada com sucesso para a conta de serviço do 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. Certifique-se de que a autenticação do Kubernetes seja executada com sucesso para a conta padrão:

   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 provisionar segredos com o Operador de segredos externo:

1. Implemente o recurso personalizado SecretStore para a conta de serviço default no namespace 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 o recurso personalizado SecretStore para a conta de serviço default no namespace 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 o recurso personalizado do ExternalSecret que referencia o segredo que contém a chave API. Você deve definir spec.target.template.metadata.labels como atlas.mongodb.com/type com o valor credentials para o Atlas Kubernetes Operator encontrar o segredo que o External Secrets Operator cria.

   Antes de executar o seguinte comando, certifique-se de que o HashiCorp Vault tenha o segredo preenchido no caminho Kv V2 secret/data/kube01/external-secrets/atlas-account com as seguintes propriedades:

   • 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 cria o segredo do Kubernetes mongodb-atlas-operator-api-key no namespace mongodb-atlas-system.

4. Deploy the ExternalSecret custom resource that references the secret that contains database user credentials. Você deve definir spec.target.template.metadata.labels como atlas.mongodb.com/type com o valor credentials para o Atlas Kubernetes Operator encontrar o segredo que o External Secrets Operator cria.

   Antes de executar o comando a seguir, verifique se o HashiCorp Vault tem o segredo preenchido no caminho Kv V2 secret/data/kube01/external-secrets/db-user com a propriedade 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. Certifique-se de que os segredos retornam conforme o esperado ao executar os seguintes comandos:

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

   $ kubectl get -n default secrets/dbuser-password

Para provisionar segredos com o CSI do Secrets Store:

1. Implemente o recurso personalizado do SecretProviderClass no namespace do mongodb-atlas-system . Você deve definir spec.secretObjects.labels como atlas.mongodb.com/type com o valor credentials para o Atlas Kubernetes Operator encontrar o segredo criado pelo CSI do Secrets Store.

   Antes de executar o seguinte comando, certifique-se de que o HashiCorp Vault tenha o segredo preenchido no caminho Kv V2 secret/data/kube01/external-secrets/atlas-account com as seguintes propriedades:

   • 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 cria o segredo do Kubernetes mongodb-atlas-operator-api-key no namespace mongodb-atlas-system.

2. Execute o seguinte comando para adicionar um pod que monta os segredos necessários:

   $ 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 o SecretProviderClass recurso personalizado que referencia o segredo que contém credenciais de usuário de banco de dados . Você deve definir spec.target.template.metadata.labels como atlas.mongodb.com/type com o valor credentials para o Atlas Kubernetes Operator para encontrar o segredo criado pelo CSI do Secrets Store.

   Antes de executar o comando a seguir, verifique se o HashiCorp Vault tem o segredo preenchido no caminho Kv V2 secret/data/kube01/external-secrets/db-user com a propriedade 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. Execute o seguinte comando para criar o pod sentido horário do secret-placeholder , que garante que o driver CSI do Secrets Store busque as credenciais do dbuser e sincronize-as com o 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. Certifique-se de que os segredos retornam conforme o esperado ao executar os seguintes comandos:

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

   $ kubectl get -n default secrets/dbuser-password