Conectar seu provedor de identidade do Azure ao Driver CSI do Azure Key Vault Secrets Store no Serviço Kubernetes do Azure (AKS)

Saiba como se conectar ao Azure Key Vault com o Secret Store CSI Driver num cluster do Azure Kubernetes Service (AKS) usando o Service Connector. Neste artigo, você conclui as seguintes tarefas:

Pré-requisitos

• Uma conta do Azure com uma subscrição ativa. Crie uma conta gratuitamente.
• CLI do Azure. Entre usando o az login comando.
• Docker e kubectl. Para instalar o kubectl localmente, use o az aks install-cli comando.
• Uma compreensão básica de contêineres e AKS. Comece por preparar uma candidatura para o AKS.
• Antes de começar, certifique-se de concluir as etapas em Usar o provedor do Azure Key Vault para o Driver CSI de Armazenamento de Segredos em um cluster do Serviço de Kubernetes do Azure (AKS) para habilitar o Driver CSI de Armazenamento de Segredos do Azure Key Vault no seu cluster AKS.

Configuração inicial

1. Se você estiver usando o Service Connector pela primeira vez, comece executando o comando az provider register para registrar os provedores de recursos do Service Connector e da Configuração do Kubernetes.

   az provider register -n Microsoft.ServiceLinker
   

   az provider register -n Microsoft.KubernetesConfiguration
   

   Gorjeta

   Você pode verificar se esses provedores de recursos já foram registrados executando os comandos az provider show -n "Microsoft.ServiceLinker" --query registrationState e az provider show -n "Microsoft.KubernetesConfiguration" --query registrationState.

2. Opcionalmente, use o comando CLI do Azure para obter uma lista de serviços de destino suportados para o cluster AKS.

   az aks connection list-support-types --output table
   

Criar recursos do Azure

1. Crie um grupo de recursos usando o az group create comando.

   az group create \
       --name <resource-group-name> \
       --___location <___location>
   

2. Crie um cluster AKS usando o az aks create comando. O exemplo a seguir cria um cluster AKS de nó único com identidade gerenciada habilitada.

   az aks create \
       --resource-group <resource-group-name> \
       --name <cluster-name> \
       --enable-managed-identity \
       --node-count 1
   

3. Conecte-se ao cluster usando o az aks get-credentials comando.

   az aks get-credentials \
       --resource-group <resource-group-name> \
       --name <cluster-name>
   

4. Crie um cofre de chaves do Azure usando o az keyvault create comando.

   az keyvault create \
       --resource-group <resource-group-name> \  
       --name <key-vault-name> \
       --___location <___location>
   

5. Crie um segredo no cofre de chaves usando o az keyvault secret set comando.

   az keyvault secret set \
       --vault-name <key-vault-name> \
       --name <secret-name> \
       --value <secret-value>
   

Criar uma conexão de serviço no AKS com o Service Connector

Você pode criar uma conexão de serviço com o Cofre da Chave do Azure usando o portal do Azure ou a CLI do Azure.

Testar a ligação

Faça um clone do repositório de exemplo e implante os arquivos de manifesto.

1. Clone o repositório de exemplo usando o git clone comando.

   git clone https://github.com/Azure-Samples/serviceconnector-aks-samples.git
   

2. Altere os diretórios para o exemplo de provedor CSI do Azure Key Vault.

   cd serviceconnector-aks-samples/azure-keyvault-csi-provider
   

3. No arquivo secret_provider_class.yaml, substitua os seguintes espaços reservados pelas suas informações do Cofre de Chaves do Azure:

   • Substitua <AZURE_KEYVAULT_NAME> pelo nome do cofre de chaves que você criou e conectou.
   • Substitua <AZURE_KEYVAULT_TENANTID> pelo ID do inquilino do cofre de chaves.
   • Substitua <AZURE_KEYVAULT_CLIENTID> pelo ID do cliente de identidade do azureKeyvaultSecretsProvider addon.
   • Substitua <KEYVAULT_SECRET_NAME> pelo segredo do cofre de chaves que você criou. Por exemplo, ExampleSecret.

4. Implante o SecretProviderClass CRD usando o kubectl apply comando.

   kubectl apply -f secret_provider_class.yaml
   

5. Implante o arquivo de manifesto Pod usando o kubectl apply comando.

   O comando cria um pod nomeado sc-demo-keyvault-csi no namespace padrão do seu cluster AKS.

   kubectl apply -f pod.yaml
   

Verificar a ligação

1. Verifique se o pod foi criado com êxito usando o kubectl get comando.

   kubectl get pod/sc-demo-keyvault-csi
   

   Assim que o pod for iniciado, o conteúdo montado no caminho de volume especificado no YAML de implantação ficará disponível.

2. Mostre os segredos guardados na loja de segredos usando o kubectl exec comando.

   kubectl exec sc-demo-keyvault-csi -- ls /mnt/secrets-store/
   

3. Exiba um segredo usando o kubectl exec comando.

   Este comando de exemplo mostra um segredo de teste chamado ExampleSecret.

   kubectl exec sc-demo-keyvault-csi -- cat /mnt/secrets-store/ExampleSecret
   

Pré-requisitos para o driver CSI

• Antes de começar, certifique-se de concluir as etapas em Usar o provedor do Azure Key Vault para o Driver CSI de Armazenamento de Segredos em um cluster do Serviço de Kubernetes do Azure (AKS) para habilitar o Driver CSI de Armazenamento de Segredos do Azure Key Vault no seu cluster AKS.
• O Microsoft Entra Workload ID suporta clusters Windows e Linux.

Acesso com um ID de carga de trabalho do Microsoft Entra

Uma ID de Carga de Trabalho do Microsoft Entra é uma identidade que um aplicativo em execução em um pod usa para autenticar-se em outros serviços do Azure, como cargas de trabalho em software. O driver CSI do Secret Store integra-se aos recursos nativos do Kubernetes para federar com provedores de identidade externos.

Neste modelo de segurança, o cluster AKS atua como emissor de token. Em seguida, o Microsoft Entra ID usa o OIDC para descobrir chaves de assinatura públicas e verificar a autenticidade do token da conta de serviço antes de trocá-lo por um token do Microsoft Entra. Para que sua carga de trabalho troque um token de conta de serviço projetado para seu volume por um token do Microsoft Entra, você precisa da biblioteca de cliente do Azure Identity no SDK do Azure ou na Biblioteca de Autenticação da Microsoft (MSAL)

Configurar identidade da carga de trabalho

1. Defina sua assinatura usando o az account set comando.

   export SUBSCRIPTION_ID=<subscription id>
   export RESOURCE_GROUP=<resource group name>
   export UAMI=<name for user assigned identity>
   export KEYVAULT_NAME=<existing keyvault name>
   export CLUSTER_NAME=<aks cluster name>
   
   az account set --subscription $SUBSCRIPTION_ID
   

2. Crie uma identidade gerenciada usando o az identity create comando.

   Nota

   Esta etapa pressupõe que você tenha um cluster AKS existente com a identidade da carga de trabalho habilitada. Se a identidade da carga de trabalho não estiver habilitada, consulte Habilitar a identidade da carga de trabalho em um cluster AKS existente para habilitá-la.

   az identity create --name $UAMI --resource-group $RESOURCE_GROUP
   
   export USER_ASSIGNED_CLIENT_ID="$(az identity show --resource-group $RESOURCE_GROUP --name $UAMI --query 'clientId' -o tsv)"
   export IDENTITY_TENANT=$(az aks show --name $CLUSTER_NAME --resource-group $RESOURCE_GROUP --query identity.tenantId -o tsv)
   

3. Crie uma atribuição de função que conceda à identidade da carga de trabalho permissão para acessar os segredos do cofre de chaves, chaves de acesso e certificados usando o az role assignment create comando.

   Importante

   • Se o cofre de chaves estiver definido com --enable-rbac-authorization e estiver a usar os tipos key ou certificate, atribua a função Key Vault Certificate User para conceder permissões.
   • Se o cofre de chaves estiver definido com --enable-rbac-authorization e estiver a utilizar o tipo secret, atribua a função Key Vault Secrets User.
   • Se o cofre de chaves não estiver definido com --enable-rbac-authorization, você poderá usar o az keyvault set-policy comando com o --key-permissions getparâmetro , --certificate-permissions getou --secret-permissions get para criar uma política de cofre de chaves para conceder acesso a chaves, certificados ou segredos. Por exemplo:

   az keyvault set-policy --name $KEYVAULT_NAME --key-permissions get --object-id $IDENTITY_OBJECT_ID
   

   export KEYVAULT_SCOPE=$(az keyvault show --name $KEYVAULT_NAME --query id -o tsv)
   
   # Example command for key vault with Azure RBAC enabled using `key` type
   az role assignment create --role "Key Vault Certificate User" --assignee $USER_ASSIGNED_CLIENT_ID --scope $KEYVAULT_SCOPE
   

4. Obtenha o URL do Emissor OIDC do cluster AKS usando o az aks show comando.

   Nota

   Esta etapa pressupõe que você tenha um cluster AKS existente com a URL do Emissor OIDC habilitada. Se o URL do Emissor OIDC não estiver habilitado, consulte Atualizar um cluster AKS com o Emissor OIDC para habilitá-lo.

   export AKS_OIDC_ISSUER="$(az aks show --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --query "oidcIssuerProfile.issuerUrl" -o tsv)"
   echo $AKS_OIDC_ISSUER
   

5. Estabeleça uma credencial de identidade federada entre o aplicativo Microsoft Entra, o emissor da conta de serviço e o assunto. Obtenha a ID do objeto do aplicativo Microsoft Entra usando os seguintes comandos. Certifique-se de atualizar os valores para serviceAccountName e serviceAccountNamespace com o nome da conta de serviço do Kubernetes e seu namespace.

   export SERVICE_ACCOUNT_NAME="workload-identity-sa"  # sample name; can be changed
   export SERVICE_ACCOUNT_NAMESPACE="default" # can be changed to namespace of your workload
   
   cat <<EOF | kubectl apply -f -
   apiVersion: v1
   kind: ServiceAccount
   metadata:
     annotations:
       azure.workload.identity/client-id: ${USER_ASSIGNED_CLIENT_ID}
     name: ${SERVICE_ACCOUNT_NAME}
     namespace: ${SERVICE_ACCOUNT_NAMESPACE}
   EOF
   

6. Crie a credencial de identidade federada entre a identidade gerida, o emissor da conta de serviço e o sujeito, usando o comando az identity federated-credential create.

   export FEDERATED_IDENTITY_NAME="aksfederatedidentity" # can be changed as needed
   
   az identity federated-credential create --name $FEDERATED_IDENTITY_NAME --identity-name $UAMI --resource-group $RESOURCE_GROUP --issuer ${AKS_OIDC_ISSUER} --subject system:serviceaccount:${SERVICE_ACCOUNT_NAMESPACE}:${SERVICE_ACCOUNT_NAME}
   

7. Implante um SecretProviderClass usando o kubectl apply comando e o seguinte script YAML.

   cat <<EOF | kubectl apply -f -
   # This is a SecretProviderClass example using workload identity to access your key vault
   apiVersion: secrets-store.csi.x-k8s.io/v1
   kind: SecretProviderClass
   metadata:
     name: azure-kvname-wi # needs to be unique per namespace
   spec:
     provider: azure
     parameters:
       usePodIdentity: "false"
       clientID: "${USER_ASSIGNED_CLIENT_ID}" # Setting this to use workload identity
       keyvaultName: ${KEYVAULT_NAME}       # Set to the name of your key vault
       cloudName: ""                         # [OPTIONAL for Azure] if not provided, the Azure environment defaults to AzurePublicCloud
       objects:  |
         array:
           - |
             objectName: secret1             # Set to the name of your secret
             objectType: secret              # object types: secret, key, or cert
             objectVersion: ""               # [OPTIONAL] object versions, default to latest if empty
           - |
             objectName: key1                # Set to the name of your key
             objectType: key
             objectVersion: ""
       tenantId: "${IDENTITY_TENANT}"        # The tenant ID of the key vault
   EOF
   

   Nota

   Se você usar objectAlias em vez de objectName, atualize o script YAML para contabilizá-lo.

   Nota

   Para que o SecretProviderClass funcione corretamente, preencha seu Cofre de Chaves do Azure com segredos, chaves ou certificados antes de fazer referência a eles na objects seção.

8. Implante um pod de exemplo usando o kubectl apply comando e o seguinte script YAML.

   cat <<EOF | kubectl apply -f -
   # This is a sample pod definition for using SecretProviderClass and workload identity to access your key vault
   kind: Pod
   apiVersion: v1
   metadata:
     name: busybox-secrets-store-inline-wi
     labels:
       azure.workload.identity/use: "true"
   spec:
     serviceAccountName: "workload-identity-sa"
     containers:
       - name: busybox
         image: registry.k8s.io/e2e-test-images/busybox:1.29-4
         command:
           - "/bin/sleep"
           - "10000"
         volumeMounts:
         - name: secrets-store01-inline
           mountPath: "/mnt/secrets-store"
           readOnly: true
     volumes:
       - name: secrets-store01-inline
         csi:
           driver: secrets-store.csi.k8s.io
           readOnly: true
           volumeAttributes:
             secretProviderClass: "azure-kvname-wi"
   EOF
   

Pré-requisitos para o driver CSI

• Antes de começar, certifique-se de concluir as etapas em Usar o provedor do Azure Key Vault para o Driver CSI de Armazenamento de Segredos em um cluster do Serviço de Kubernetes do Azure (AKS) para habilitar o Driver CSI de Armazenamento de Segredos do Azure Key Vault no seu cluster AKS.

Acesso com identidade gerenciada

Uma Identidade Gerida do Microsoft Entra é uma identidade que um administrador usa para autenticar-se em relação a outros serviços do Azure. A identidade gerenciada usa o RBAC do Azure para federar com provedores de identidade externos.

Neste modelo de segurança, pode conceder acesso aos recursos do cluster a membros da equipa ou inquilinos que partilhem uma função gerida. A função é verificada quanto ao escopo para acessar o keyvault e outras credenciais. Quando ativou o provedor Azure Key Vault para o CSI Driver do Secrets Store no seu Cluster AKS, foi criada uma identidade de utilizador.

Configurar identidade gerenciada

1. Acesse seu cofre de chaves usando o az aks show comando e a identidade gerenciada atribuída pelo usuário criada pelo complemento. Você também deve recuperar a identidade clientId, que você usa em etapas posteriores ao criar um SecretProviderClass.

   az aks show --resource-group <resource-group> --name <cluster-name> --query addonProfiles.azureKeyvaultSecretsProvider.identity.objectId -o tsv
   az aks show --resource-group <resource-group> --name <cluster-name> --query addonProfiles.azureKeyvaultSecretsProvider.identity.clientId -o tsv
   

   Como alternativa, você pode criar uma nova identidade gerenciada e atribuí-la ao seu conjunto de escala de máquina virtual (VM) ou a cada instância de VM em seu conjunto de disponibilidade usando os comandos a seguir.

   az identity create --resource-group <resource-group> --name <identity-name>
   az vmss identity assign --resource-group <resource-group> --name <agent-pool-vmss> --identities <identity-resource-id>
   az vm identity assign --resource-group <resource-group> --name <agent-pool-vm> --identities <identity-resource-id>
   
   az identity show --resource-group <resource-group> --name <identity-name> --query 'clientId' -o tsv
   

2. Crie uma atribuição de função que conceda a permissão de identidade para acessar os segredos do cofre de chaves, chaves de acesso e certificados usando o az role assignment create comando.

   Importante

   • Se o cofre de chaves estiver definido com --enable-rbac-authorization e estiver a usar o tipo key ou certificate, atribua a função Key Vault Certificate User.
   • Se o cofre de chaves estiver definido com --enable-rbac-authorization e estiver a utilizar o tipo secret, atribua a função Key Vault Secrets User.
   • Se o cofre de chaves não estiver definido com --enable-rbac-authorization, você poderá usar o az keyvault set-policy comando com o --key-permissions getparâmetro , --certificate-permissions getou --secret-permissions get para criar uma política de cofre de chaves para conceder acesso a chaves, certificados ou segredos. Por exemplo:

   az keyvault set-policy --name $KEYVAULT_NAME --key-permissions get --object-id $IDENTITY_OBJECT_ID
   

   export IDENTITY_OBJECT_ID="$(az identity show --resource-group <resource-group> --name <identity-name> --query 'principalId' -o tsv)"
   export KEYVAULT_SCOPE=$(az keyvault show --name <key-vault-name> --query id -o tsv)
   
   # Example command for key vault with Azure RBAC enabled using `key` type
   az role assignment create --role "Key Vault Certificate User" --assignee $USER_ASSIGNED_CLIENT_ID --scope $KEYVAULT_SCOPE
   

3. Crie um SecretProviderClass usando o seguinte YAML. Certifique-se de usar seus próprios valores para userAssignedIdentityID, keyvaultName, tenantIde os objetos a serem recuperados do cofre de chaves.

   # This is a SecretProviderClass example using user-assigned identity to access your key vault
   apiVersion: secrets-store.csi.x-k8s.io/v1
   kind: SecretProviderClass
   metadata:
     name: azure-kvname-user-msi
   spec:
     provider: azure
     parameters:
       usePodIdentity: "false"
       useVMManagedIdentity: "true"          # Set to true for using managed identity
       userAssignedIdentityID: <client-id>   # Set the clientID of the user-assigned managed identity to use
       keyvaultName: <key-vault-name>        # Set to the name of your key vault
       cloudName: ""                         # [OPTIONAL for Azure] if not provided, the Azure environment defaults to AzurePublicCloud
       objects:  |
         array:
           - |
             objectName: secret1
             objectType: secret              # object types: secret, key, or cert
             objectVersion: ""               # [OPTIONAL] object versions, default to latest if empty
           - |
             objectName: key1
             objectType: key
             objectVersion: ""
       tenantId: <tenant-id>                 # The tenant ID of the key vault
   

   Nota

   Se utilizares objectAlias em vez de objectName, certifica-te de atualizar o script YAML.

   Nota

   Para que o SecretProviderClass funcione corretamente, preencha seu Cofre de Chaves do Azure com segredos, chaves ou certificados antes de fazer referência a eles na objects seção.

4. Aplique o SecretProviderClass ao cluster usando o kubectl apply comando.

   kubectl apply -f secretproviderclass.yaml
   

5. Crie um pod usando o seguinte YAML.

   # This is a sample pod definition for using SecretProviderClass and the user-assigned identity to access your key vault
   kind: Pod
   apiVersion: v1
   metadata:
     name: busybox-secrets-store-inline-user-msi
   spec:
     containers:
       - name: busybox
         image: registry.k8s.io/e2e-test-images/busybox:1.29-4
         command:
           - "/bin/sleep"
           - "10000"
         volumeMounts:
         - name: secrets-store01-inline
           mountPath: "/mnt/secrets-store"
           readOnly: true
     volumes:
       - name: secrets-store01-inline
         csi:
           driver: secrets-store.csi.k8s.io
           readOnly: true
           volumeAttributes:
             secretProviderClass: "azure-kvname-user-msi"
   

6. Aplique o pod ao seu cluster usando o comando kubectl apply.

   kubectl apply -f pod.yaml
   

Valide os segredos do 'Key Vault'

Assim que o pod for iniciado, o conteúdo montado no caminho de volume especificado no YAML de implantação ficará disponível. Use os comandos a seguir para validar seus segredos e imprimir um segredo de teste.

1. Mostrar segredos mantidos no armazenamento de segredos usando o seguinte comando.

   kubectl exec busybox-secrets-store-inline-user-msi -- ls /mnt/secrets-store/
   

2. Exiba um segredo na loja usando o seguinte comando. Este comando de exemplo mostra o segredo de teste ExampleSecret.

   kubectl exec busybox-secrets-store-inline-user-msi -- cat /mnt/secrets-store/ExampleSecret
   

Obter certificados e chaves

O design do Azure Key Vault faz distinções nítidas entre chaves, segredos e certificados. Os recursos de certificados do serviço Cofre de Chaves são concebidos para tirar partido das funcionalidades de chaves e segredos. Quando você cria um certificado de cofre de chaves, ele cria uma chave endereçável e um segredo com o mesmo nome. Essa chave permite operações de autenticação e o segredo permite a recuperação do valor do certificado como um segredo.

Um certificado de cofre de chaves também contém metadados de certificado x509 públicos. O cofre de chaves armazena os componentes públicos e privados do seu certificado em segredo. Você pode obter cada componente individual especificando o objectType in SecretProviderClass. A tabela seguinte mostra quais objetos mapeiam os vários recursos associados ao seu certificado.

Desativar o addon em clusters existentes

Desative o fornecedor do Azure Key Vault para a capacidade do Driver CSI do Secrets Store em um cluster existente usando o comando az aks disable-addons com o complemento azure-keyvault-secrets-provider.

az aks disable-addons --addons azure-keyvault-secrets-provider --resource-group myResourceGroup --name myAKSCluster

Próximos passos

Neste artigo, você aprendeu como criar e fornecer uma identidade para acessar seu Cofre da Chave do Azure. A integração do Service Connector ajuda a simplificar a configuração de conexão para cargas de trabalho AKS e serviços de suporte do Azure. Ele lida com segurança com autenticação e configurações de rede e segue as práticas recomendadas para se conectar aos serviços do Azure. Para mais informações, consulte Usar o provedor do Cofre de Chaves do Azure para o Driver CSI do Repositório de Segredos num cluster AKS e a introdução ao Service Connector.

Se você quiser configurar opções de configuração adicionais ou executar a solução de problemas, consulte Opções de configuração e recursos de solução de problemas para o provedor do Azure Key Vault com o Driver CSI do Secrets Store no AKS.