Compartilhar via


Conectar certificados de AC para complemento de malha de serviço baseado no Istio no Serviço de Kubernetes do Azure

No complemento de malha de serviço baseado no Istio para Serviço de Kubernetes do Azure, por padrão, a autoridade de certificação (AC) do Istio gera um certificado raiz autoassinado e uma chave e os usa para assinar os certificados de carga de trabalho. Para proteger a chave de AC raiz, você deve usar uma AC raiz, que é executada em um computador seguro offline. Você pode usar a AC raiz para emitir certificados intermediários para as CAs do Istio executadas em cada cluster. Uma AC do Istio pode assinar certificados de carga de trabalho usando o certificado e a chave especificados pelo administrador e distribuir um certificado raiz especificado pelo administrador para as cargas de trabalho como a raiz de confiança. Este artigo aborda como trazer seus próprios certificados e chaves para a AC do Istio no complemento de malha de serviço baseado em Istio para Serviço de Kubernetes do Azure.

Diagrama que mostra a AC raiz e intermediária com o Istio.

Este artigo aborda como você pode configurar a autoridade de certificação do Istio com um certificado raiz, um certificado de autenticação e uma chave fornecida como entradas usando o Azure Key Vault para o complemento de malha de serviço baseado em Istio.

Antes de começar

Verificar a versão da CLI do Azure

O complemento exige a CLI do Azure versão 2.57.0 ou posterior instalada. Execute az --version para verificar a versão. Se você precisar instalar ou atualizar, consulte [Instalar a CLI do Azure][azure-cli-install].

Configurar o Azure Key Vault

  1. Você precisa de um recurso do Azure Key Vault para fornecer o certificado e as principais entradas para o complemento do Istio.

  2. Você precisa gerar certificado raiz, certificados intermediários, chave intermediária e a cadeia de certificados offline. As etapas 1 a 3 de aqui tem um exemplo de como gerar esses arquivos.

  3. Crie segredos no Azure Key Vault usando os certificados e a chave:

    az keyvault secret set --vault-name $AKV_NAME --name root-cert --file <path-to-folder/root-cert.pem>
    az keyvault secret set --vault-name $AKV_NAME --name ca-cert --file <path-to-folder/ca-cert.pem>
    az keyvault secret set --vault-name $AKV_NAME --name ca-key --file <path-to-folder/ca-key.pem>
    az keyvault secret set --vault-name $AKV_NAME --name cert-chain --file <path-to-folder/cert-chain.pem>
    
  4. Habilite o provedor do Azure Key Vault para o Driver CSI do Repositório Secreto para seu cluster:

    az aks enable-addons --addons azure-keyvault-secrets-provider --resource-group $RESOURCE_GROUP --name $CLUSTER
    

    Observação

    Ao rotacionar certificados, para controlar a rapidez com que os segredos são sincronizados com o cluster, você poderá usar o parâmetro --rotation-poll-interval do complemento Provedor de Segredos do Azure Key Vault. Por exemplo: az aks addon update --resource-group $RESOURCE_GROUP --name $CLUSTER --addon azure-keyvault-secrets-provider --enable-secret-rotation --rotation-poll-interval 20s

  5. Autorize a identidade gerenciada atribuída pelo usuário do complemento para ter acesso ao recurso do Azure Key Vault:

    OBJECT_ID=$(az aks show --resource-group $RESOURCE_GROUP --name $CLUSTER --query 'addonProfiles.azureKeyvaultSecretsProvider.identity.objectId' -o tsv)
    
    az keyvault set-policy --name $AKV_NAME --object-id $OBJECT_ID --secret-permissions get list
    

    Observação

    Se você criou o Key Vault com a Autorização de RBAC do Azure para o modelo de permissão em vez da Política de Acesso do Cofre, siga as instruções aqui, para criar permissões para a identidade gerenciada. Adicione uma atribuição de função do Azure para Key Vault Reader, para a identidade gerenciada atribuída pelo usuário do complemento.

Configurar o complemento de malha de serviço baseado em Istio com certificados de AC de plug-in

  1. Habilite o complemento de malha de serviço do Istio para o cluster do AKS existente enquanto faz referência aos segredos do Azure Key Vault que foram criados anteriormente:

    az aks mesh enable --resource-group $RESOURCE_GROUP --name $CLUSTER \
    --root-cert-object-name root-cert \
    --ca-cert-object-name ca-cert \
    --ca-key-object-name ca-key \
    --cert-chain-object-name cert-chain \
    --key-vault-id /subscriptions/$SUBSCRIPTION/resourceGroups/$RESOURCE_GROUP/providers/Microsoft.KeyVault/vaults/$AKV_NAME
    

    Observação

    Para os clusters existentes com o complemento do Istio que usam certificado raiz autoassinado gerado pela AC do Istio, a mudança para a CA do plug-in não é suportada. Você precisa primeiro desabilitar a malha nesses clusters e depois habilitá-la novamente usando o comando acima para passar pelas entradas da AC do plugin.

  2. Verifique se o cacerts é criado no cluster:

    kubectl get secret -n aks-istio-system
    

    Saída esperada:

    NAME                                                         TYPE                 DATA   AGE
    cacerts                                                      opaque               4      13h
    sh.helm.release.v1.azure-service-mesh-istio-discovery.v380   helm.sh/release.v1   1      2m15s
    sh.helm.release.v1.azure-service-mesh-istio-discovery.v381   helm.sh/release.v1   1      8s    
    
  3. Verifique se o painel de controle do Istio selecionou a autoridade de certificação personalizada:

    kubectl logs deploy/istiod-asm-1-17 -c discovery -n aks-istio-system | grep -v validationController | grep x509
    

    A saída esperada deve ser semelhante a:

    2023-11-06T15:49:15.493732Z     info    x509 cert - Issuer: "CN=Intermediate CA - A1,O=Istio,L=cluster-A1", Subject: "", SN: e191d220af347c7e164ec418d75ed19e, NotBefore: "2023-11-06T15:47:15Z", NotAfter: "2033-11-03T15:49:15Z"
    2023-11-06T15:49:15.493764Z     info    x509 cert - Issuer: "CN=Root A,O=Istio", Subject: "CN=Intermediate CA - A1,O=Istio,L=cluster-A1", SN: 885034cba2894f61036f2956fd9d0ed337dc636, NotBefore: "2023-11-04T01:40:02Z", NotAfter: "2033-11-01T01:40:02Z"
    2023-11-06T15:49:15.493795Z     info    x509 cert - Issuer: "CN=Root A,O=Istio", Subject: "CN=Root A,O=Istio", SN: 18e2ee4089c5a7363ec306627d21d9bb212bed3e, NotBefore: "2023-11-04T01:38:27Z", NotAfter: "2033-11-01T01:38:27Z"
    

Rotação da autoridade de certificação

Talvez seja necessário rotacionar periodicamente as autoridades de certificação por motivos de segurança ou política. Esta seção orienta você sobre como lidar com cenários de rotação de AC intermediária e AC raiz.

Rotação de autoridade de certificação intermediária

  1. Você pode girar a AC intermediária enquanto mantém a mesma AC raiz. Atualize os segredos no recurso do Azure Key Vault com os novos arquivos de certificado e chave:

    az keyvault secret set --vault-name $AKV_NAME --name root-cert --file <path-to-folder/root-cert.pem>
    az keyvault secret set --vault-name $AKV_NAME --name ca-cert --file <path-to-folder/ca-cert.pem>
    az keyvault secret set --vault-name $AKV_NAME --name ca-key --file <path-to-folder/ca-key.pem>
    az keyvault secret set --vault-name $AKV_NAME --name cert-chain --file <path/cert-chain.pem>
    
  2. Aguarde a duração do tempo de --rotation-poll-interval. Verifique se o segredo cacerts foi atualizado no cluster com base na nova AC intermediária que foi atualizada no recurso do Azure Key Vault:

    kubectl logs deploy/istiod-asm-1-17 -c discovery -n aks-istio-system | grep -v validationController
    

    A saída esperada deve ser semelhante a:

    2023-11-07T06:16:21.091844Z     info    Update Istiod cacerts
    2023-11-07T06:16:21.091901Z     info    Using istiod file format for signing ca files
    2023-11-07T06:16:21.354423Z     info    Istiod has detected the newly added intermediate CA and updated its key and certs accordingly
    2023-11-07T06:16:21.354910Z     info    x509 cert - Issuer: "CN=Intermediate CA - A2,O=Istio,L=cluster-A2", Subject: "", SN: b2753c6a23b54d8364e780bf664672ce, NotBefore: "2023-11-07T06:14:21Z", NotAfter: "2033-11-04T06:16:21Z"
    2023-11-07T06:16:21.354967Z     info    x509 cert - Issuer: "CN=Root A,O=Istio", Subject: "CN=Intermediate CA - A2,O=Istio,L=cluster-A2", SN: 17f36ace6496ac2df88e15878610a0725bcf8ae9, NotBefore: "2023-11-04T01:40:22Z", NotAfter: "2033-11-01T01:40:22Z"
    2023-11-07T06:16:21.355007Z     info    x509 cert - Issuer: "CN=Root A,O=Istio", Subject: "CN=Root A,O=Istio", SN: 18e2ee4089c5a7363ec306627d21d9bb212bed3e, NotBefore: "2023-11-04T01:38:27Z", NotAfter: "2033-11-01T01:38:27Z"
    2023-11-07T06:16:21.355012Z     info    Istiod certificates are reloaded
    
  3. As cargas de trabalho recebem certificados do painel de controle do Istio válidos por 24 horas por padrão. Se você não reiniciar os pods, todas as cargas de trabalho obterão novos certificados folha com base na nova AC intermediária em 24 horas. Se quiser forçar todas essas cargas de trabalho a obter novos certificados folha imediatamente da nova AC intermediária, será necessário reiniciar as cargas de trabalho.

    kubectl rollout restart deployment <deployment name> -n <deployment namespace>
    

Rotação de autoridade de certificação raiz

  1. Você precisa atualizar os segredos do Azure Key Vault com o arquivo de certificado raiz tendo a concatenação dos certificados raiz antigos e novos:

    az keyvault secret set --vault-name $AKV_NAME --name root-cert --file <path-to-folder/root-cert.pem>
    az keyvault secret set --vault-name $AKV_NAME --name ca-cert --file <path-to-folder/ca-cert.pem>
    az keyvault secret set --vault-name $AKV_NAME --name ca-key --file <path-to-folder/ca-key.pem>
    az keyvault secret set --vault-name $AKV_NAME --name cert-chain --file <path/cert-chain.pem>
    

    O conteúdo de root-cert.pem segue este formato:

    -----BEGIN CERTIFICATE-----
    <contents of old root certificate>
    -----END CERTIFICATE-----
    -----BEGIN CERTIFICATE-----
    <contents of new root certificate>
    -----END CERTIFICATE-----
    

    O complemento inclui uma execução de CronJob a cada dez minutos no cluster para verificar se há atualizações no certificado raiz. Se detectar uma atualização, ele reiniciará o painel de controle do Istio (istiod implantação) para obter as atualizações. Você pode verificar seus logs para confirmar se a atualização do certificado raiz foi detectada e se o painel de controle do Istio foi reiniciado:

    kubectl logs -n aks-istio-system $(kubectl get pods -n aks-istio-system | grep 'istio-cert-validator-cronjob-' | sort -k8 | tail -n 1 | awk '{print $1}')
    

    Saída esperada:

    Root certificate update detected. Restarting deployment...
    deployment.apps/istiod-asm-1-17 restarted
    Deployment istiod-asm-1-17 restarted.
    

    Após a reinicialização do istiod, ele deverá indicar que dois certificados foram adicionados ao domínio confiável:

    kubectl logs deploy/istiod-asm-1-17 -c discovery -n aks-istio-system 
    

    Saída esperada:

    2023-11-07T06:42:00.287916Z     info    Using istiod file format for signing ca files
    2023-11-07T06:42:00.287928Z     info    Use plugged-in cert at etc/cacerts/ca-key.pem
    2023-11-07T06:42:00.288254Z     info    x509 cert - Issuer: "CN=Intermediate CA - A2,O=Istio,L=cluster-A2", Subject: "", SN: 286451ca8ff7bf9e6696f56bef829d42, NotBefore: "2023-11-07T06:40:00Z", NotAfter: "2033-11-04T06:42:00Z"
    2023-11-07T06:42:00.288279Z     info    x509 cert - Issuer: "CN=Root A,O=Istio", Subject: "CN=Intermediate CA - A2,O=Istio,L=cluster-A2", SN: 17f36ace6496ac2df88e15878610a0725bcf8ae9, NotBefore: "2023-11-04T01:40:22Z", NotAfter: "2033-11-01T01:40:22Z"
    2023-11-07T06:42:00.288298Z     info    x509 cert - Issuer: "CN=Root A,O=Istio", Subject: "CN=Root A,O=Istio", SN: 18e2ee4089c5a7363ec306627d21d9bb212bed3e, NotBefore: "2023-11-04T01:38:27Z", NotAfter: "2033-11-01T01:38:27Z"
    2023-11-07T06:42:00.288303Z     info    Istiod certificates are reloaded
    2023-11-07T06:42:00.288365Z     info    spiffe  Added 2 certs to trust domain cluster.local in peer cert verifier
    
  2. Você precisa aguardar 24 horas (o tempo padrão para a validade do certificado folha) ou forçar a reinicialização de todas as cargas de trabalho. Dessa forma, todas as cargas de trabalho reconhecem as autoridades de certificação antigas e novas para verificação mTLS.

    kubectl rollout restart deployment <deployment name> -n <deployment namespace>
    
  3. Agora você pode atualizar os segredos do Azure Key Vault somente com a nova AC (sem a AC antiga):

    az keyvault secret set --vault-name $AKV_NAME --name root-cert --file <path-to-folder/root-cert.pem>
    az keyvault secret set --vault-name $AKV_NAME --name ca-cert --file <path-to-folder/ca-cert.pem>
    az keyvault secret set --vault-name $AKV_NAME --name ca-key --file <path-to-folder/ca-key.pem>
    az keyvault secret set --vault-name $AKV_NAME --name cert-chain --file <path/cert-chain.pem>
    

    Verifique os logs do CronJob para confirmar a detecção da atualização do certificado raiz e a reinicialização do istiod:

    kubectl logs -n aks-istio-system $(kubectl get pods -n aks-istio-system | grep 'istio-cert-validator-cronjob-' | sort -k8 | tail -n 1 | awk '{print $1}')
    

    Saída esperada:

    Root certificate update detected. Restarting deployment...
    deployment.apps/istiod-asm-1-17 restarted
    Deployment istiod-asm-1-17 restarted.
    

    Após a atualização do istiod, ele deverá apenas confirmar o uso da nova AC raiz:

    kubectl logs deploy/istiod-asm-1-17 -c discovery -n aks-istio-system | grep -v validationController
    

    Saída esperada:

    2023-11-07T08:01:17.780299Z     info    x509 cert - Issuer: "CN=Intermediate CA - B1,O=Istio,L=cluster-B1", Subject: "", SN: 1159747c72cc7ac7a54880cd49b8df0a, NotBefore: "2023-11-07T07:59:17Z", NotAfter: "2033-11-04T08:01:17Z"
    2023-11-07T08:01:17.780330Z     info    x509 cert - Issuer: "CN=Root B,O=Istio", Subject: "CN=Intermediate CA - B1,O=Istio,L=cluster-B1", SN: 2aba0c438652a1f9beae4249457023013948c7e2, NotBefore: "2023-11-04T01:42:12Z", NotAfter: "2033-11-01T01:42:12Z"
    2023-11-07T08:01:17.780345Z     info    x509 cert - Issuer: "CN=Root B,O=Istio", Subject: "CN=Root B,O=Istio", SN: 3f9da6ddc4cb03749c3f43243a4b701ce5eb4e96, NotBefore: "2023-11-04T01:41:54Z", NotAfter: "2033-11-01T01:41:54Z"
    

    Nas saídas de exemplo mostradas neste artigo, você pode observar que mudamos da Raiz A (usada ao habilitar o complemento) para a Raiz B.

  4. Você pode aguardar novamente por 24 horas ou forçar uma reinicialização de todas as cargas de trabalho. Forçar uma reinicialização faz com que as cargas de trabalho obtenham novos certificados folha da nova AC raiz imediatamente.

    kubectl rollout restart deployment <deployment name> -n <deployment namespace>