Conectar seu provedor de identidade do Azure ao Driver da CSI do Repositório de Segredos do Azure Key Vault no AKS (Serviço de Kubernetes do Azure)

Saiba como se conectar ao Azure Key Vault com o Driver Secrets Store CSI em um cluster do AKS (Serviço de Kubernetes do Azure) usando o Conector de serviço. Neste artigo, você concluirá as seguintes tarefas:

Pré-requisitos

• Uma conta do Azure com uma assinatura ativa. Crie uma conta gratuitamente.
• O CLI do Azure. Entre usando o comando az login.
• Docker e kubectl. Para instalar o kubectl localmente, use o comando az aks install-cli.
• Conhecimento básico de contêineres e AKS. Comece preparando um aplicativo para o AKS.
• Antes de começar, verifique se você concluiu as etapas em Usar o provedor do Azure Key Vault para o Driver da CSI do Repositório de Segredos em um cluster do AKS (Serviço de Kubernetes do Azure) para habilitar o Driver da CSI do Repositório de Segredos no Azure Key Vault em seu cluster do 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
   

   Dica

   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 da CLI do Azure para obter uma lista de serviços de destino com suporte para o cluster do AKS.

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

Criar uma conexão de serviço no AKS com o Conector de Serviço

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

Testar a conexão

Clonar o repositório de exemplo e implantar arquivos de manifesto

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

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

2. Altere os diretórios para o exemplo do provedor de 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 informações do Azure Key Vault:

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

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

   kubectl apply -f secret_provider_class.yaml
   

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

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

   kubectl apply -f pod.yaml
   

Verificar conexão

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

   kubectl get pod/sc-demo-keyvault-csi
   

   Depois que o pod é iniciado, o conteúdo montado no caminho do volume especificado no YAML de implantação fica disponível.

2. Mostre os segredos mantidos no repositório de segredos usando o comando kubectl exec.

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

3. Exiba um segredo usando o comando kubectl exec.

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

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

Pré-requisitos para driver CSI com identidade de carga de trabalho

• Antes de começar, verifique se você concluiu as etapas em Usar o provedor do Azure Key Vault para o Driver da CSI do Repositório de Segredos em um cluster do AKS (Serviço de Kubernetes do Azure) para habilitar o Driver da CSI do Repositório de Segredos no Azure Key Vault em seu cluster do AKS.
• A ID de carga de trabalho do Microsoft Entra dá suporte a clusters do Windows e do Linux.

Acesso com uma ID de carga de trabalho do Microsoft Entra

Um ID de carga de trabalho do Microsoft Entra é uma identidade que um aplicativo ou serviço usa para se autenticar em outros serviços Azure, como cargas de trabalho no software. O Secrets Store CSI Driver integra-se com os recursos nativos do Kubernetes para se federar a provedores de identidade externos.

Nesse modelo de segurança, o cluster do AKS atua como o emissor do token. Quando o Secrets Store CSI Driver monta o volume, ele solicita um token de conta de serviço do Kubernetes, e o provedor do Azure Key Vault troca esse token por um token do Microsoft Entra. O aplicativo lê os arquivos montados e não precisa da biblioteca de cliente do Azure Identity nem da biblioteca Biblioteca do Microsoft Authenticator (MSAL) nesse fluxo de montagem de volume. Se o aplicativo solicitar de maneira independente tokens do Microsoft Entra para chamar APIs protegidas, use o Azure Identity ou o MSAL no aplicativo.

Configurar identidade de carga de trabalho

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

   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 comando az identity create.

   Observação

   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 do 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 KEYVAULT_TENANT_ID="$(az keyvault show --name $KEYVAULT_NAME --query properties.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, as chaves de acesso e os certificados, utilizando o comando az role assignment create.

   Importante

   • Se você configurar o cofre de chaves com --enable-rbac-authorization e estiver usando o tipo key ou cert, atribua a função Key Vault Certificate User para conceder as permissões.
   • Se o seu cofre de chaves estiver definido com --enable-rbac-authorization e você estiver usando o tipo secret, atribua a função Key Vault Secrets User.
   • Se o seu cofre de chaves não estiver definido com --enable-rbac-authorization, você poderá usar o comando az keyvault set-policy com o parâmetro --key-permissions get, --certificate-permissions get, ou --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 --secret-permissions get --object-id <identity-object-id>
   

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

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

   Observação

   Esta etapa pressupõe que você tenha um cluster AKS existente com a URL do Emissor OIDC habilitada. Se a URL do Emissor do OIDC não estiver habilitada, consulte Atualizar um cluster do 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. Crie uma conta de serviço do Kubernetes para a carga de trabalho. Atualize os valores para SERVICE_ACCOUNT_NAME e SERVICE_ACCOUNT_NAMESPACE 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 gerenciada, o emissor da conta de serviço e o assunto 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 comando kubectl apply e o script YAML a seguir.

Os seguintes parâmetros configuram o acesso à identidade da carga de trabalho:

• usePodIdentity: Defina como "false" ao usar a identidade da carga de trabalho.

• clientID: definido como ${USER_ASSIGNED_CLIENT_ID}, o identificador do cliente da identidade gerenciada atribuída pelo usuário usada para identidade de carga de trabalho.

• cloudName: opcional. Deixe vazio para usar o ambiente padrão AzurePublicCloud .

• objectType: defina como o tipo de objeto do Key Vault a ser montado. Os valores válidos são secret, keye cert.

• tenantId: defina para a ID do locatário que contém o cofre de chaves.

  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
    namespace: ${SERVICE_ACCOUNT_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: "${KEYVAULT_TENANT_ID}"     # The tenant ID of the key vault
  EOF
  

  Observação

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

  Observação

  Para que o SecretProviderClass funcione corretamente, preencha seu Azure Key Vault com segredos, chaves ou certificados antes de referenciá-los na seção objects.

1. Implante um pod de exemplo usando o comando kubectl apply e o script YAML a seguir.

   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
     namespace: ${SERVICE_ACCOUNT_NAMESPACE}
     labels:
       azure.workload.identity/use: "true"
   spec:
     serviceAccountName: ${SERVICE_ACCOUNT_NAME}
     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
   

Validar os segredos do Key Vault com a identidade de carga de trabalho

Depois que o pod iniciar, o conteúdo montado em /mnt/secrets-store estará disponível. Use os comandos a seguir para validar seus segredos e imprimir um segredo de teste.

1. Mostrar segredos mantidos no repositório de segredos usando o comando a seguir.

   kubectl exec --namespace $SERVICE_ACCOUNT_NAMESPACE busybox-secrets-store-inline-wi -- ls /mnt/secrets-store/
   

2. Exiba um segredo no repositório usando o comando a seguir. Este comando de exemplo mostra o segredo de teste secret1.

   kubectl exec --namespace $SERVICE_ACCOUNT_NAMESPACE busybox-secrets-store-inline-wi -- cat /mnt/secrets-store/secret1
   

Pré-requisitos para driver CSI com identidade gerenciada

• Antes de começar, verifique se você concluiu as etapas em Usar o provedor do Azure Key Vault para o Driver da CSI do Repositório de Segredos em um cluster do AKS (Serviço de Kubernetes do Azure) para habilitar o Driver da CSI do Repositório de Segredos no Azure Key Vault em seu cluster do AKS.

Acesso com identidade gerenciada

Esse método usa a identidade gerenciada atribuída ao usuário, criada automaticamente pelo AKS quando você habilita o provedor do Azure Key Vault para o Secrets Store CSI Driver. A identidade é denominada azurekeyvaultsecretsprovider-xxxxx, está armazenada no grupo de recursos do nó e é atribuída ao conjunto de escalonamento da máquina virtual.

Uma identidade gerenciada Microsoft Entra permite que um recurso ou carga de trabalho Azure se autentique em serviços que dão suporte à autenticação Microsoft Entra sem armazenar credenciais no código. Conceda a essa identidade as permissões apropriadas do plano de dados do Key Vault por meio do Azure RBAC ou de políticas de acesso e, em seguida, use-a nas etapas a seguir.

Configurar uma identidade gerenciada

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

   export RESOURCE_GROUP=<resource-group>
   export CLUSTER_NAME=<cluster-name>
   export KEYVAULT_NAME=<key-vault-name>
   
   export IDENTITY_OBJECT_ID=$(az aks show --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --query addonProfiles.azureKeyvaultSecretsProvider.identity.objectId -o tsv)
   export USER_ASSIGNED_CLIENT_ID=$(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 conjunto de dimensionamento da VM (máquina virtual) ou a cada instância de VM em seu conjunto de disponibilidade.

   export USER_ASSIGNED_IDENTITY_NAME=<identity-name>
   
   az identity create --resource-group $RESOURCE_GROUP --name $USER_ASSIGNED_IDENTITY_NAME
   
   export IDENTITY_RESOURCE_ID=$(az identity show --resource-group $RESOURCE_GROUP --name $USER_ASSIGNED_IDENTITY_NAME --query id -o tsv)
   export IDENTITY_OBJECT_ID=$(az identity show --resource-group $RESOURCE_GROUP --name $USER_ASSIGNED_IDENTITY_NAME --query principalId -o tsv)
   export USER_ASSIGNED_CLIENT_ID=$(az identity show --resource-group $RESOURCE_GROUP --name $USER_ASSIGNED_IDENTITY_NAME --query clientId -o tsv)
   

   Para um cluster com base em conjunto de dimensionamento de máquinas virtuais, atribua a identidade ao conjunto de dimensionamento de máquinas virtuais.

   az vmss identity assign --resource-group <node-resource-group> --name <agent-pool-vmss> --identities $IDENTITY_RESOURCE_ID
   

   Para um cluster baseado em conjunto de disponibilidade, atribua a identidade a cada instância de VM no conjunto de disponibilidade.

   az vm identity assign --resource-group <node-resource-group> --name <agent-pool-vm> --identities $IDENTITY_RESOURCE_ID
   

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

   Importante

   • Se você configurar seu Key Vault com --enable-rbac-authorization e estiver usando o tipo key ou cert, atribua a função Key Vault Certificate User.
   • Se o seu cofre de chaves estiver definido com --enable-rbac-authorization e você estiver usando o tipo secret, atribua a função Key Vault Secrets User.
   • Se o seu cofre de chaves não estiver definido com --enable-rbac-authorization, você poderá usar o comando az keyvault set-policy com o parâmetro --key-permissions get, --certificate-permissions get, ou --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 --secret-permissions get --object-id $IDENTITY_OBJECT_ID
   

   export KEYVAULT_SCOPE=$(az keyvault show --name $KEYVAULT_NAME --query id -o tsv)
   
   # Example commands for a key vault with Azure RBAC enabled using `key` and `secret` types
   az role assignment create --role "Key Vault Certificate User" --assignee-object-id $IDENTITY_OBJECT_ID --assignee-principal-type ServicePrincipal --scope $KEYVAULT_SCOPE
   az role assignment create --role "Key Vault Secrets User" --assignee-object-id $IDENTITY_OBJECT_ID --assignee-principal-type ServicePrincipal --scope $KEYVAULT_SCOPE
   

3. Crie um SecretProviderClass usando o ID do cliente de identidade. Certifique-se de usar seus próprios valores para os objetos a serem recuperados do cofre de chaves.

   Os seguintes parâmetros configuram o acesso de identidade gerenciada atribuído pelo usuário:

   • usePodIdentity: Defina como "false" ao usar identidade gerenciada.
   • useVMManagedIdentity: defina para "true" habilitar o modo de identidade gerenciada.
   • userAssignedIdentityID: defina como a ID do cliente da identidade gerenciada atribuída pelo usuário.
   • tenantId: defina para a ID do locatário que contém o cofre de chaves.

   export KEYVAULT_TENANT_ID=$(az keyvault show --name $KEYVAULT_NAME --query properties.tenantId -o tsv)
   
   cat <<EOF > secretproviderclass.yaml
   # 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: ${USER_ASSIGNED_CLIENT_ID} # Set the client ID of the user-assigned managed identity to use
       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
             objectType: secret              # object types: secret, key, or cert
             objectVersion: ""               # [OPTIONAL] object versions, default to latest if empty
           - |
             objectName: key1
             objectType: key
             objectVersion: ""
       tenantId: ${KEYVAULT_TENANT_ID}       # The tenant ID of the key vault
   EOF
   

   Observação

   Se você usar objectAlias em vez de objectName, certifique-se de atualizar o script YAML.

   Observação

   Para que o SecretProviderClass funcione corretamente, preencha seu Azure Key Vault com segredos, chaves ou certificados antes de referenciá-los na seção objects.

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

   kubectl apply -f secretproviderclass.yaml
   

5. Crie um manifesto de pod chamado pod.yaml usando o comando a seguir.

   cat <<EOF > pod.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"
   EOF
   

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

   kubectl apply -f pod.yaml
   

Validar segredos do Key Vault usando identidade gerenciada

Após a inicialização do pod, o conteúdo montado em /mnt/secrets-store estará disponível. Use os comandos a seguir para validar seus segredos e imprimir um segredo de teste.

1. Mostrar segredos mantidos no repositório de segredos usando o comando a seguir.

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

2. Exiba um segredo no repositório usando o comando a seguir. Este comando de exemplo mostra o segredo de teste secret1.

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

Obter certificados e chaves

O design do Azure Key Vault faz distinções claras entre chaves, segredos e certificados. Os recursos de certificado do serviço do Key Vault foram feitos para usar recursos de chave e de segredo. 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 do certificado x509 público. O cofre de chaves armazena os componentes públicos e privados do certificado em um segredo. Você pode obter cada componente individual especificando o objectType em SecretProviderClass. A tabela a seguir mostra os valores objectType que você pode especificar em SecretProviderClass para recuperar diferentes componentes de um certificado de um cofre de chaves e o que cada valor retorna:

Desabilitar o complemento em clusters existentes

Desabilite a capacidade do provedor do Azure Key Vault para o Driver do CSI do Armazenamento de Segredos 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óximas etapas

Neste artigo, você aprendeu a criar e fornecer uma identidade para acessar seu Azure Key Vault. A integração do Conector de Serviço ajuda a simplificar a configuração de conexão para cargas de trabalho do AKS e serviços de backup do Azure. De maneira segura, ele lida com autenticação e configurações de rede e segue as práticas recomendadas para se conectar aos serviços do Azure. Para obter mais informações, consulte Usar o provedor do Azure Key Vault para o driver CSI do Repositório de Segredos em um cluster do AKS e a Introdução ao Conector de Serviço.

Se você quiser definir 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 Repositório de Segredos no AKS.