Compartilhar via

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)

  • Artigo

O Driver da CSI (Interface de Armazenamento de Contêiner) do Repositório de Segredos no AKS (Serviço de Kubernetes do Azure) fornece vários métodos de acesso baseado em identidade ao seu Azure Key Vault. Este artigo descreve esses métodos e melhores práticas para quando usar os modelos de segurança do RBAC (controle de acesso baseado em função) ou do OIDC (OpenID Connect) para acessar o cofre de chaves e o cluster do AKS.

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

  • Conector de Serviço com identidade gerenciada
  • ID de carga de trabalho
  • Identidade gerenciada atribuída pelo usuário

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:

  • Crie um cluster do AKS e um Azure Key Vault.
  • Crie uma conexão entre o cluster do AKS e o Azure Key Vault com o Conector de Serviço.
  • Crie um CRD SecretProviderClass e um Pod que consuma o provedor de CSI para testar a conexão.
  • Limpe os recursos.

Importante

As versões prévias do recurso AKS estão disponíveis em uma base de autoatendimento e aceitação. As visualizações são fornecidas "como estão" e "conforme disponíveis" e estão excluídas dos acordos de nível de serviço e da garantia limitada. As versões prévias do AKS são parcialmente cobertas pelo suporte ao cliente em uma base de melhor esforço. Dessa forma, esses recursos não são destinados ao uso em produção. Para obter mais informações, consulte os seguintes artigos:

Pré-requisitos

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 recursos do Azure

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

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

  2. Crie um cluster do AKS usando o comando az aks create. O exemplo a seguir cria um cluster do AKS de nó único com a 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 comando az aks get-credentials.

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

  4. Crie um Azure Key Vault usando o comando az keyvault create.

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

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

    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 (versão prévia)

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

  1. No portal do Azure, navegue até o recurso do cluster do AKS.

  2. No menu de serviço, em Configurações, selecione Conector de Serviço (Versão Prévia)>Criar.

  3. Na página Criar conexão, defina as seguintes configurações na guia Noções básicas:

    • Namespace do Kubernetes: selecione padrão.
    • Tipo de serviço: selecione Key Vault e marque a caixa de seleção para habilitar o Provedor de CSI do Azure Key Vault.
    • Nome da conexão: insira um nome para a conexão.
    • Assinatura: selecione a assinatura que contém o cofre de chaves.
    • Cofre de chaves: selecione o cofre de chaves que você criou.
    • Tipo de cliente: selecione Nenhum.

  4. Selecione Revisar + criar e, em seguida, selecione Criar para criar a conexão.

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 de 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 do Driver da CSI

Acesso com uma 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 se autenticar em outros serviços do Azure, como cargas de trabalho no software. O Driver da CSI do Repositório de Segredos se integra aos recursos nativos do Kubernetes para federar com provedores de identidade externos.

Nesse modelo de segurança, o cluster do AKS atua como emissor de token. Em seguida, o Microsoft Entra ID usa o OIDC para descobrir as 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 sua carga de trabalho trocar um token de conta de serviço projetado para o seu volume por um token do Microsoft Entra, você precisa da biblioteca de clientes do Azure Identity no SDK do Azure ou da MSAL (Biblioteca de Autenticação da Microsoft)

Observação

  • Esse método de autenticação substitui a identidade gerenciada por pod do Microsoft Entra (versão prévia). A identidade gerenciada por pod do Microsoft Entra de software livre (versão prévia) no Serviço de Kubernetes do Azure foi preterida a partir de 24/10/2022.
  • A ID de Carga de Trabalho do Microsoft Entra dá suporte a clusters do Windows e do Linux.

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 você não a tiver habilitada, confira Habilitar a identidade de 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 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, as chaves de acesso e os certificados, utilizando o comando az role assignment create.

    Importante

    • Se o seu cofre de chaves estiver definido com --enable-rbac-authorization e você estiver usando o tipo key ou certificate, atribua a função Key Vault Certificate User para conceder 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 --object-id $IDENTITY_OBJECT_ID

    export KEYVAULT_SCOPE=$(az keyvault show --name $KEYVAULT_NAME --query id -o tsv)

# Example command for key vault with RBAC enabled using `key` type
az role assignment create --role "Key Vault Certificate 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 você não o tiver habilitado, 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. Estabeleça uma credencial de identidade federada entre o aplicativo do Microsoft Entra, o emissor da conta de serviço e o assunto. Obtenha a ID de objeto de aplicativo do Microsoft Entra usando os comandos a seguir. Atualize os valores de serviceAccountName e serviceAccountNamespace com o nome e o namespace da conta de serviço do Kubernetes.

    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.

    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

    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.

  8. 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
  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 do Driver da CSI

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 o RBAC para federar com provedores de identidade externos.

Neste modelo de segurança, você pode conceder acesso aos recursos do cluster para locatários ou membros da equipe compartilhando uma função gerenciada. 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 da CSI do Repositório de Segredos no cluster do AKS, ele criou uma identidade de usuário.

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ê usará em etapas posteriores ao criar 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 identidade gerenciada e atribuí-la ao conjunto de dimensionamento de VMs (máquinas virtuais) ou a cada instância de VM do 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 à 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 o seu cofre de chaves estiver definido com --enable-rbac-authorization e você estiver usando o tipo key ou certificate, 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 --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 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 os seus próprios valores de userAssignedIdentityID, keyvaultName e tenantId e 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

    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 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 cluster usando o comando kubectl apply.

    kubectl apply -f pod.yaml

Validar segredos do Key Vault

Depois que o pod é iniciado, o conteúdo montado no caminho do 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.

  1. Mostre os 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 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 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 seguinte tabela mostra os objetos que são mapeados para os vários recursos associados ao seu certificado:

Objeto Valor retornado Retorna toda a cadeia de certificados
key A chave pública, no formato Privacy Enhanced Mail (PEM). N/D
cert O certificado, no formato PEM. Não
secret A chave privada e o certificado, no formato PEM. Sim

Desabilitar o complemento em clusters existentes

Observação

Antes de desabilitar o complemento, verifique se nenhum SecretProviderClass esteja em uso. Tentar desativar o complemento enquanto um SecretProviderClass existe resulta em um erro.

  • 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

Observação

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 pod for criado como parte do evento da escala vertical, o pod não será reiniciado porque o driver não está mais em execução.

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.