Partilhar via

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

  • Artigo

No complemento de malha de serviço baseado em Istio para o Serviço Kubernetes do Azure, por padrão, a autoridade de certificação (CA) do Istio gera um certificado raiz e uma chave autoassinados e os usa para assinar os certificados de carga de trabalho. Para proteger a chave de autoridade de certificação raiz, você deve usar uma autoridade de certificação raiz, que é executada em uma máquina segura offline. Você pode usar a autoridade de certificação raiz para emitir certificados intermediários para as autoridades de certificação do Istio que são executadas em cada cluster. Uma autoridade de certificação 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 da confiança. Este artigo aborda como trazer seus próprios certificados e chaves para a CA do Istio no complemento de malha de serviço baseado em Istio para o Serviço 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, certificado de assinatura e chave fornecidos como entradas usando o Cofre de Chaves do Azure 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 requer a CLI do Azure versão 2.57.0 ou posterior instalada. Você pode executar az --version para verificar a versão. Para 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 entradas de chave para o complemento Istio.

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

  3. Crie segredos no Cofre da Chave do Azure 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

    Nota

    Ao girar certificados, para controlar a rapidez com que os segredos são sincronizados com o cluster, você pode usar o --rotation-poll-interval parâmetro do complemento Provedor de Segredos do Cofre de Chaves do Azure. 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 a ter acesso ao recurso do Cofre de Chaves do Azure:

    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

    Nota

    Se você criou seu Cofre da Chave com a Autorização RBAC do Azure para seu modelo de permissão em vez da Política de Acesso ao Vault, 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 a identidade gerenciada atribuída pelo usuário do complemento.

Configurar addon de malha de serviço baseado em Istio com certificados de CA de plug-in

  1. Habilite o complemento de malha de serviço Istio para seu cluster AKS existente enquanto faz referência aos segredos do Cofre de Chaves do Azure 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

    Nota

    Para clusters existentes com addon Istio usando certificado raiz auto-assinado gerado pela CA do Istio, não há suporte para a CA do plug-in. Você precisa desativar a malha nesses clusters primeiro e, em seguida, habilitá-la novamente usando o comando acima para passar pelas entradas de CA do plugin.

  2. Verifique se o cacerts é criado no cluster:

    kubectl get secret -n aks-istio-system

    Resultado esperado:

    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 plano de controle do Istio pegou 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

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

Rotação intermédia da autoridade de certificação

  1. Você pode girar a autoridade de certificação intermediária enquanto mantém a autoridade de certificação raiz a mesma. Atualize os segredos no recurso Cofre de Chaves do Azure com o novo certificado e arquivos de 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 --rotation-poll-interval. Verifique se o cacerts segredo foi atualizado no cluster com base na nova autoridade de certificação intermediária que foi atualizada no recurso Cofre de Chaves do Azure:

    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 plano de controle do Istio que são 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 CA intermediária em 24 horas. Se você quiser forçar todas essas cargas de trabalho a obter novos certificados folha imediatamente da nova autoridade de certificação intermediária, precisará reiniciar as cargas de trabalho.

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

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

  1. Você precisa atualizar os segredos do Cofre da Chave do Azure com o arquivo de certificado raiz com a concatenação dos certificados raiz antigo e novo:

    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>

    Conteúdo de root-cert.pem seguir este formato:

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

    O complemento inclui uma CronJob execução a cada dez minutos no cluster para verificar se há atualizações no certificado raiz. Se detetar uma atualização, ele reinicia o plano de controle do Istio (istiod implantação) para pegar as atualizações. Você pode verificar seus logs para confirmar que a atualização do certificado raiz foi detetada e que o plano 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}')

    Resultado esperado:

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

    Depois de istiod reiniciado, ele deve indicar que dois certificados foram adicionados ao domínio de confiança:

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

    Resultado esperado:

    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 uma 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 de mTLS.

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

  3. Agora você pode atualizar os segredos do Cofre da Chave do Azure apenas com a nova autoridade de certificação (sem a autoridade de certificação 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 para confirmar a CronJob deteção de atualização de certificado raiz e a reinicialização de 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}')

    Resultado esperado:

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

    Depois istiod de atualizado, ele só deve confirmar o uso da nova autoridade de certificação raiz:

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

    Resultado esperado:

    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"

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

  4. Você pode esperar 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 autoridade de certificação raiz imediatamente.

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