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

Artigo
03/07/2024

O driver CSI (Secrets Store Container Storage Interface) no Serviço Kubernetes do Azure (AKS) fornece vários métodos de acesso baseado em identidade ao seu Cofre de Chaves do Azure. Este artigo descreve esses métodos e práticas recomendadas para quando usar modelos de segurança RBAC (controle de acesso baseado em função) ou OpenID Connect (OIDC) para acessar seu cofre de chaves e cluster AKS.

Você pode usar um dos seguintes métodos de acesso:

ID da carga de trabalho do Microsoft Entra
Identidade gerenciada atribuída pelo usuário

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 do Repositório de Segredos em um cluster do Serviço Kubernetes do Azure (AKS) para habilitar o Driver CSI do Azure Key Vault Secrets Store em seu cluster AKS.

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)

Nota

Este método de autenticação substitui a identidade gerenciada pelo pod do Microsoft Entra (visualização). A identidade gerenciada por pod do Microsoft Entra de código aberto (visualização) no Serviço Kubernetes do Azure foi preterida a partir de 24/10/2022.
O Microsoft Entra Workload ID é compatível com clusters Windows e Linux.

Configurar identidade da carga de trabalho

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

Crie uma identidade gerenciada usando o az identity create comando.

az identity create --name $UAMI --resource-group $RESOURCE_GROUP

export USER_ASSIGNED_CLIENT_ID="$(az identity show -g $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)

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.
```
export KEYVAULT_SCOPE=$(az keyvault show --name $KEYVAULT_NAME --query id -o tsv)

az role assignment create --role "Key Vault Administrator" --assignee $USER_ASSIGNED_CLIENT_ID --scope $KEYVAULT_SCOPE
```
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 você não o tiver 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
```

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

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

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}

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.

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

Acesso com identidade gerenciada

Uma ID Gerenciada do Microsoft Entra é uma identidade que um administrador usa para se autenticar em outros serviços do Azure. A identidade gerenciada usa RBAC 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 você habilitou o provedor do Azure Key Vault para o Driver CSI do Secrets Store em seu Cluster AKS, ele criou uma identidade de usuário.

Configurar identidade gerenciada

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 do clientId, que será usada em etapas posteriores ao criar um SecretProviderClassarquivo .

az aks show -g <resource-group> -n <cluster-name> --query addonProfiles.azureKeyvaultSecretsProvider.identity.objectId -o tsv
az aks show -g <resource-group> -n <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 -g <resource-group> -n <identity-name>
az vmss identity assign -g <resource-group> -n <agent-pool-vmss> --identities <identity-resource-id>
az vm identity assign -g <resource-group> -n <agent-pool-vm> --identities <identity-resource-id>

az identity show -g <resource-group> --name <identity-name> --query 'clientId' -o tsv

Crie uma atribuição de função que conceda à permissão de identidade acesso aos segredos do cofre de chaves, chaves de acesso e certificados usando o az role assignment create comando.

export IDENTITY_OBJECT_ID="$(az identity show -g <resource-group> --name <identity-name> --query 'principalId' -o tsv)"
export KEYVAULT_SCOPE=$(az keyvault show --name <key-vault-name> --query id -o tsv)

az role assignment create --role "Key Vault Administrator" --assignee $IDENTITY_OBJECT_ID --scope $KEYVAULT_SCOPE

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 você usar objectAlias em vez de , certifique-se de objectNameatualizar 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.

Aplique o SecretProviderClass ao cluster usando o kubectl apply comando.
```
kubectl apply -f secretproviderclass.yaml
```

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"

Aplique o pod ao cluster usando o kubectl apply comando.
```
kubectl apply -f pod.yaml
```

Validar segredos do Cofre da Chave

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

Mostrar segredos mantidos no armazenamento de segredos usando o seguinte comando.
```
kubectl exec busybox-secrets-store-inline -- ls /mnt/secrets-store/
```
Exiba um segredo na loja usando o seguinte comando. Este comando de exemplo mostra o segredo ExampleSecretde teste .
```
kubectl exec busybox-secrets-store-inline -- 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 certificado do serviço Cofre de Chaves são projetados para usar recursos de chave e 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 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 a seguir mostra quais objetos são mapeados para os vários recursos associados ao seu certificado:

Object	Valor devolvido	Devolve toda a cadeia de certificados
`key`	A chave pública, no formato PEM (Privacy Enhanced Mail).	N/A
`cert`	O certificado, em formato PEM.	Não
`secret`	A chave privada e o certificado, em formato PEM.	Sim

Desativar o addon em clusters existentes

Nota

Antes de desativar o complemento, verifique se nãoSecretProviderClass está em uso. Tentar desativar o complemento enquanto existe resulta SecretProviderClass em um erro.

Desative o provedor do Azure Key Vault para o recurso de Driver CSI do Secrets Store em um cluster existente usando o az aks disable-addons comando com o complemento azure-keyvault-secrets-provider .
```
az aks disable-addons --addons azure-keyvault-secrets-provider -g myResourceGroup -n myAKSCluster
```

Nota

Quando você desabilita o complemento, as cargas de trabalho existentes não devem ter problemas ou ver atualizações nos segredos montados. Se o pod for reiniciado ou um novo pod for criado como parte do evento de expansão, o pod não será iniciado porque o driver não está mais em execução.

Próximos passos

Neste artigo, você aprendeu como criar e fornecer uma identidade para acessar seu Cofre da Chave do Azure. Se você quiser configurar opções de configuração adicionais ou executar a solução de problemas, continue para o próximo artigo.

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

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

Pré-requisitos para o driver CSI

Acesso com um ID de carga de trabalho do Microsoft Entra

Configurar identidade da carga de trabalho

Acesso com identidade gerenciada

Configurar identidade gerenciada

Validar segredos do Cofre da Chave

Obter certificados e chaves

Desativar o addon em clusters existentes

Próximos passos

Recursos adicionais