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

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 os modelos de segurança de controle de acesso baseado em função do Azure (Azure RBAC) ou OpenID Connect (OIDC) para acessar seu cofre de chaves e cluster AKS.

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

  • Conector de serviço com identidade gerenciada
  • ID da carga de trabalho
  • Identidade gerida atribuída pelo utilizador

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:

  • Registe os fornecedores de recursos Azure necessários.
  • Crie uma conexão entre o cluster AKS e o Cofre de Chaves do Azure com o Service Connector.
  • Crie um SecretProviderClass CRD e um Pod que consuma o provedor CSI para testar a conexão.
  • Verifica se o pod consegue aceder ao segredo do cofre de chaves.

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

    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 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.

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

  2. No menu de serviço, em Definições, selecione Conector de Serviço>Criar.

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

    • Kubernetes namespace: Selecione padrão.
    • Tipo de serviço: Selecione Cofre da Chave e marque a caixa de seleção para habilitar o Provedor CSI do Cofre da Chave do Azure.
    • 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 Rever + criar e, em seguida, selecione Criar para criar a ligação.

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 de cliente de identidade do azureKeyvaultSecretsProvider add-on.
    • 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 CSI Driver com identidade de carga de trabalho

Acesso com um ID de carga de trabalho do Microsoft Entra

Um ID de carga de trabalho Microsoft Entra é uma identidade que uma aplicação ou serviço utiliza para se autenticar contra outros serviços do Azure, como cargas de trabalho em software. O Secrets Store CSI Driver integra-se com capacidades nativas do Kubernetes para federar com fornecedores de identidade externos.

Neste modelo de segurança, o cluster AKS atua como o emissor do token. Quando o Secrets Store CSI Driver monta o volume, solicita um token de conta de serviço Kubernetes, e o fornecedor do Azure Key Vault troca esse token por um token Microsoft Entra. A aplicação lê os ficheiros montados e não necessita da biblioteca cliente Azure Identity nem da Biblioteca de Autenticação da Microsoft (MSAL) para este fluxo montado em volume. Se a aplicação solicitar de forma independente tokens Microsoft Entra para chamar APIs protegidas, use o Azure Identity ou MSAL na aplicação.

Nota

  • Este método de autenticação substitui a identidade gerenciada pelo pod do Microsoft Entra (visualização). A identidade gerida por pod do Microsoft Entra de código aberto (visualização) no Serviço Kubernetes do Azure foi descontinuada em 24 de outubro de 2022.
  • O ID de carga de trabalho Microsoft Entra suporta clusters Windows e Linux.

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 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, chaves de acesso e certificados usando o az role assignment create comando.

    Importante

    • Se definires o teu key vault com --enable-rbac-authorization e estiveres a usar key ou cert escreveres, atribui o Key Vault Certificate User papel para dar 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 --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 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. Crie uma conta de serviço Kubernetes para a carga de trabalho. Atualize os valores para SERVICE_ACCOUNT_NAME e SERVICE_ACCOUNT_NAMESPACE com o nome da conta do serviço Kubernetes e o 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.

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

  • usePodIdentity: Definido para "false" quando se usa a identidade da carga de trabalho.

  • clientID: Defina para ${USER_ASSIGNED_CLIENT_ID}, o ID do cliente da identidade gerida atribuída pelo utilizador usada para a identidade da carga de trabalho.

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

  • objectType: Definido para o tipo de objeto Key Vault para montar. Os valores válidos são secret, keye cert.

  • tenantId: Definido para o ID do inquilino 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

    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.

  1. 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
  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 segredos do Key Vault com identidade de carga de trabalho

Depois de o pod começar, o conteúdo montado em /mnt/secrets-store fica 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 --namespace $SERVICE_ACCOUNT_NAMESPACE busybox-secrets-store-inline-wi -- ls /mnt/secrets-store/

  2. Exiba um segredo na loja usando o seguinte comando. 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 CSI Driver com identidade gerida

Acesso com identidade gerenciada

Este método utiliza a identidade gerida atribuída pelo utilizador que o AKS cria automaticamente quando ativa o fornecedor Azure Key Vault para o Secrets Store CSI Driver. A identidade chama-se azurekeyvaultsecretsprovider-xxxxx, é armazenada no grupo de recursos de nós e é atribuída ao conjunto de escalas da máquina virtual.

Uma identidade gerida Microsoft Entra permite que um recurso ou carga de trabalho Azure autentique serviços que suportam autenticação Microsoft Entra sem armazenar credenciais em código. Conceda a esta identidade as permissões apropriadas do plano de dados do Key Vault através do Azure RBAC ou políticas de acesso, e depois utilize-a nos passos seguintes.

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.

    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)

    Em alternativa, pode criar uma nova identidade gerida e atribuí-la ao conjunto de escalas da sua máquina virtual (VM) ou a cada instância de VM no 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 baseado em conjunto de escalas de VM, atribui a identidade ao conjunto de escalas da VM.

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

    Para um cluster baseado em conjuntos de disponibilidade, atribui 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 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 definires o teu key vault com --enable-rbac-authorization e estiveres a usar key ou cert escreveres, atribui o Key Vault Certificate User papel.
    • 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 --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 de cliente de identidade. Certifica-te de usar os teus próprios valores para os objetos a recolher do teu cofre de chaves.

    Os seguintes parâmetros configuram o acesso à identidade gerida atribuída pelo utilizador:

    • usePodIdentity: Definir para "false" ao usar identidade gerida.
    • useVMManagedIdentity: Definir para "true" ativar o modo de identidade gerida.
    • userAssignedIdentityID: Definido para o ID do cliente da identidade gerida atribuída pelo utilizador.
    • tenantId: Definido para o ID do inquilino 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

    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 manifesto pod nomeado pod.yaml usando o seguinte comando.

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

    kubectl apply -f pod.yaml

Validar segredos do Key Vault com identidade gerida

Depois de o pod começar, o conteúdo montado em /mnt/secrets-store fica 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 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 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 os objectType valores que pode especificar para SecretProviderClass obter diferentes componentes de um certificado de cofre de chave e o que cada valor retorna:

objectType valor 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

Desative o complemento nos clusters existentes

Nota

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

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

Nota

Quando se desativa a extensão, não se prevê que as cargas de trabalho existentes tenham problemas ou hajam 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. 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.

  • Last updated on