Gerenciar certificados em clusters do Service Fabric

Este artigo aborda os aspetos de gerenciamento de certificados usados para proteger a comunicação em clusters do Azure Service Fabric. Ele complementa a introdução à segurança de cluster do Service Fabric e o explicador sobre a autenticação baseada em certificado X.509 no Service Fabric.

Pré-requisitos

Antes de começar, você deve estar familiarizado com os conceitos fundamentais de segurança e os controles que o Service Fabric expõe para configurar a segurança de um cluster.

Exclusão de Responsabilidade

Este artigo combina aspetos teóricos do gerenciamento de certificados com exemplos práticos que abrangem as especificidades de serviços, tecnologias e assim por diante. Como grande parte do público aqui é interno da Microsoft, o artigo se refere a serviços, tecnologias e produtos específicos do Azure. Se determinados detalhes específicos da Microsoft não se aplicarem a si, não hesite em pedir esclarecimentos ou orientações na secção de comentários no final.

Definindo o gerenciamento de certificados

Como você aprende no artigo complementar X.509 Autenticação baseada em certificado em clusters do Service Fabric, um certificado é um objeto criptográfico que essencialmente vincula um par de chaves assimétricas com atributos que descrevem a entidade que ele representa.

No entanto, um certificado também é um objeto perecível , porque sua vida útil é finita e é suscetível a comprometimento. A divulgação acidental ou uma exploração bem-sucedida pode tornar um certificado inútil do ponto de vista da segurança. Esta característica implica a necessidade de alterar os certificados de forma rotineira ou em resposta a um incidente de segurança.

Outro aspeto do gerenciamento de certificados, e um tópico totalmente separado, é a proteção de chaves privadas de certificados ou segredos que protegem as identidades das entidades envolvidas na aquisição e provisionamento de certificados.

Descrevemos o gerenciamento de certificados como os processos e procedimentos usados para obter certificados e transportá-los com segurança para onde são necessários.

Algumas operações de gerenciamento, como registro, definição de política e controles de autorização, estão além do escopo deste artigo. Outras operações, como provisionamento, renovação, rechaveamento ou revogação, estão relacionadas apenas incidentalmente ao Service Fabric. No entanto, o artigo aborda um pouco essas operações, porque entender essas operações pode ajudá-lo a proteger seu cluster corretamente.

Seu objetivo imediato provavelmente será automatizar o gerenciamento de certificados tanto quanto possível para garantir a disponibilidade ininterrupta do cluster. Como o processo é livre de toque do usuário, você também vai querer oferecer garantias de segurança. Com os clusters do Service Fabric, essa meta é alcançável.

O restante do artigo primeiro desconstrói o gerenciamento de certificados e, mais tarde, se concentra em habilitar o autorollover.

Mais especificamente, abrange os seguintes tópicos:

• Pressupostos sobre a separação de atribuições entre proprietário e plataforma
• O longo pipeline desde a emissão do certificado até o consumo
• Rotação de certificados: porquê, como e quando
• O que poderia dar errado?

O artigo não aborda estes tópicos:

• Protegendo e gerenciando nomes de domínio
• Inscrição em certificados
• Configuração de controles de autorização para impor a emissão de certificados.

Para obter informações sobre esses tópicos, consulte a autoridade de registro (RA) do seu serviço favorito de infraestrutura de chave pública (PKI). Se você for um leitor interno da Microsoft, poderá entrar em contato com a Segurança do Azure.

Funções e entidades envolvidas no gerenciamento de certificados

A abordagem de segurança em um cluster do Service Fabric é um caso de "proprietário do cluster declara, o tempo de execução do Service Fabric o impõe". Isso significa que quase nenhum dos certificados, chaves ou outras credenciais de identidades que participam do funcionamento de um cluster vêm do próprio serviço. Todos eles são declarados pelo proprietário do cluster. O proprietário do cluster também é responsável por provisionar os certificados no cluster, renová-los conforme necessário e ajudar a garantir sua segurança em todos os momentos.

Mais especificamente, o proprietário do cluster deve garantir que:

• Os certificados declarados na seção NodeType do manifesto do cluster podem ser encontrados em cada nó desse tipo, de acordo com as regras de apresentação.
• Os certificados declarados como no marcador anterior são instalados com as chaves privadas correspondentes incluídas.
• Os certificados declarados nas regras de apresentação devem passar pelas regras de validação.

O Service Fabric, por sua vez, assume as seguintes responsabilidades:

• Localizando certificados que correspondem às declarações na definição de cluster
• Concessão de acesso às chaves privadas correspondentes a entidades controladas pelo Service Fabric com base na necessidade
• Validação de certificados em estrita conformidade com as práticas recomendadas de segurança estabelecidas e a definição de cluster
• Emissão de alertas sobre expiração iminente de certificados ou falhas na execução das etapas básicas de validação de certificados
• Validando (até certo ponto) que os aspetos relacionados ao certificado da definição de cluster são atendidos pela configuração subjacente dos hosts

Segue-se que a carga de gerenciamento de certificados (como operações ativas) recai exclusivamente sobre o proprietário do cluster. As próximas seções oferecem uma visão mais detalhada de cada uma das operações de gestão, incluindo os mecanismos disponíveis e seu impacto no cluster.

O percurso de um certificado

Vamos descrever rapidamente a progressão de um certificado da emissão para o consumo no contexto de um cluster do Service Fabric:

1. Um proprietário de domínio registra com a RA de uma PKI um domínio ou assunto que deseja associar aos certificados subsequentes. Os certificados, por sua vez, constituem prova de propriedade do domínio ou assunto.

2. O proprietário do domínio também designa no RA as identidades dos solicitantes autorizados, entidades que têm o direito de solicitar o registro de certificados com o domínio ou assunto especificado.

3. Em seguida, um solicitante autorizado se inscreve em um certificado por meio de um serviço de gerenciamento de segredos. No Azure, o serviço de gerenciamento de segredos preferido é o Azure Key Vault, que armazena e permite a recuperação segura de segredos e certificados por entidades autorizadas. O Cofre da Chave também renova e reintroduz o certificado conforme configurado na política de certificado associada. O Key Vault usa o Microsoft Entra ID como o provedor de identidade.

4. Um recuperador autorizado, ou agente de provisionamento, recupera o certificado do cofre de chaves, incluindo sua chave privada, e o instala nas máquinas que hospedam o cluster.

5. O serviço Service Fabric (executado com privilégios elevados em cada nó) concede acesso ao certificado às entidades do Service Fabric permitidas, que são designadas por grupos locais e divididas entre ServiceFabricAdministrators e ServiceFabricAllowedUsers.

6. O tempo de execução do Service Fabric acessa e usa o certificado para estabelecer federação ou autenticar solicitações de entrada de clientes autorizados.

7. O agente de provisionamento monitora o certificado do cofre de chaves e, quando deteta a renovação, dispara o fluxo de provisionamento. Em seguida, o proprietário do cluster atualiza a definição do cluster, se necessário, para indicar a intenção de rolar o certificado.

8. O agente de provisionamento ou o proprietário do cluster também é responsável por limpar e excluir certificados não utilizados.

Para efeitos do presente artigo, os dois primeiros passos da sequência anterior são, na sua maioria, independentes. Sua única conexão é que o nome comum do assunto do certificado é o nome DNS declarado na definição de cluster.

O fluxo de emissão e provisionamento de certificados é ilustrado nos diagramas a seguir:

Para certificados declarados por impressão digital

Para certificados declarados por nome comum de entidade

Inscrição de certificado

O tópico de registro de certificado é abordado em detalhes na documentação do Cofre de Chaves. Uma sinopse é incluída aqui para continuidade e referência mais fácil.

Continuando com o Azure como contexto e usando o Cofre da Chave como o serviço de gerenciamento de segredos, um solicitante de certificado autorizado deve ter pelo menos permissões de gerenciamento de certificado no cofre de chaves, concedidas pelo proprietário do cofre de chaves. Em seguida, o solicitante se inscreve em um certificado da seguinte maneira:

• O solicitante cria uma política de certificado no Cofre da Chave, que especifica o domínio/assunto do certificado, o emissor desejado, o tipo e o comprimento da chave, o uso pretendido da chave e muito mais. Para obter mais informações, consulte Certificados no Cofre da Chave do Azure.

• O solicitante cria um certificado no mesmo cofre com a política especificada na etapa anterior. Isso, por sua vez, gera um par de chaves como objetos do vault e uma solicitação de assinatura de certificado que é assinada com a chave privada, que é então encaminhada para o emissor designado para assinatura.

• Depois que o emissor, ou a autoridade de certificação (CA), responde com o certificado assinado, o resultado é mesclado no cofre de chaves e os dados do certificado ficam disponíveis da seguinte maneira:

  • Em {vaultUri}/certificates/{name}: O certificado, incluindo a chave pública e os metadados
  • Em {vaultUri}/keys/{name}: A chave privada do certificado, disponível para operações criptográficas (encapsular/desempacotar, assinar/verificar)
  • Em {vaultUri}/secrets/{name}: O certificado, incluindo sua chave privada, disponível para download como um arquivo PFX ou PEM desprotegido.

Lembre-se de que um certificado no cofre de chaves contém uma lista cronológica de instâncias de certificado que compartilham uma política. As versões do certificado serão criadas de acordo com os atributos de tempo de vida e renovação desta política. É altamente recomendável que os certificados do vault não compartilhem assuntos, domínios ou nomes DNS, porque pode causar interrupções em um cluster provisionar instâncias de certificado de certificados de cofre diferentes, com assuntos idênticos, mas outros atributos substancialmente diferentes, como emissor, usos de chave e assim por diante. Neste ponto, existe um certificado no cofre de chaves, pronto para consumo. Agora vamos explorar o resto do processo.

Provisionamento de certificados

Mencionamos um agente de provisionamento, que é a entidade que recupera o certificado, incluindo sua chave privada, do cofre de chaves e o instala em cada um dos hosts do cluster. (Lembre-se de que o Service Fabric não fornece certificados.)

No contexto deste artigo, o cluster será hospedado em uma coleção de máquinas virtuais (VMs) do Azure ou conjuntos de escala de máquinas virtuais. No Azure, você pode provisionar um certificado de um cofre para uma VM/VMSS usando os seguintes mecanismos. Isso pressupõe, como antes, que o agente de provisionamento recebeu anteriormente permissões secretas de obtenção no cofre de chaves pelo proprietário do cofre de chaves.

• Ad-hoc: Um operador recupera o certificado do cofre de chaves (como PFX/PKCS #12 ou PEM) e o instala em cada nó.

  O mecanismo ad-hoc não é recomendado, por vários motivos, que vão desde a segurança até a disponibilidade, e não será discutido aqui mais adiante. Para obter mais informações, consulte Perguntas frequentes sobre conjuntos de dimensionamento de máquina virtual do Azure.

• Como segredo do conjunto de dimensionamento de máquina virtual durante a implantação: usando sua identidade de primeira parte em nome do operador, o serviço de computação recupera o certificado de um cofre habilitado para implantação de modelo e o instala em cada nó do conjunto de dimensionamento de máquina virtual, conforme descrito em Perguntas frequentes sobre conjuntos de dimensionamento de máquina virtual do Azure.

  Nota

  Essa abordagem permite o provisionamento apenas de segredos versionados.

• Usando a extensão Key Vault VM. Isso permite provisionar certificados usando declarações sem versão, com atualização periódica dos certificados observados. Nesse caso, espera-se que a VM/VMSS tenha uma identidade gerenciada, uma identidade à qual foi concedido acesso aos cofres de chaves que contêm os certificados observados.

O provisionamento baseado em VMSS/computação apresenta vantagens de segurança e disponibilidade, mas também apresenta restrições. Ele exige, por design, que você declare certificados como segredos versionados. Esse requisito torna o provisionamento baseado em VMSS/computação adequado apenas para clusters protegidos com certificados declarados por impressão digital.

Por outro lado, o provisionamento baseado em extensão de VM do Key Vault sempre instala a versão mais recente de cada certificado observado. o que o torna adequado apenas para clusters protegidos com certificados declarados pelo nome comum do assunto. Para enfatizar, não use um mecanismo de provisionamento de atualização automática (como a extensão VM do Cofre de Chaves) para certificados declarados por instância (ou seja, por impressão digital). O risco de perder disponibilidade é considerável.

Existem outros mecanismos de provisionamento, mas as abordagens mencionadas aqui são as opções atualmente aceitas para clusters do Azure Service Fabric.

Consumo e monitorização de certificados

Como mencionado anteriormente, o tempo de execução do Service Fabric é responsável por localizar e usar os certificados declarados na definição de cluster. O artigo Autenticação baseada em certificado X.509 em clusters do Service Fabric explica em detalhes como o Service Fabric implementa as regras de apresentação e validação e não será revisitado aqui. Este artigo analisará a concessão de acesso e permissão, bem como o monitoramento.

Lembre-se de que os certificados no Service Fabric são usados para uma infinidade de finalidades, desde a autenticação mútua na camada de federação até a autenticação TLS (Transport Layer Security) para os pontos de extremidade de gerenciamento. Isso requer que vários componentes ou serviços do sistema tenham acesso à chave privada do certificado. O tempo de execução do Service Fabric verifica regularmente o armazenamento de certificados, procurando correspondências para cada uma das regras de apresentação conhecidas.

Para cada certificado correspondente, a chave privada correspondente é localizada e sua lista de controle de acesso discricionário é atualizada para incluir permissões (Ler e Executar, normalmente) concedidas à identidade que as exige.

Este processo é informalmente referido como ACLing. O processo é executado em uma cadência de um minuto e também abrange certificados de aplicativo, como aqueles usados para criptografar configurações ou como certificados de ponto de extremidade. A ACLing segue as regras de apresentação, por isso é importante ter em mente que os certificados declarados por impressão digital e que são atualizados automaticamente sem a atualização de configuração de cluster subsequente ficarão inacessíveis.

Rotação de certificados

Nota

A Internet Engineering Task Force (IETF) RFC 3647 define formalmente a renovação como a emissão de um certificado com os mesmos atributos do certificado que está sendo substituído. O emissor, a chave pública do sujeito e as informações são preservados. Re-keying é a emissão de um certificado com um novo par de chaves, sem restrições sobre se o emissor pode mudar. Como a distinção pode ser importante (considere o caso de certificados que são declarados por nome comum de assunto com fixação do emissor), este artigo usa a rotação de termo neutro para cobrir ambos os cenários. Tenha em mente que, quando a renovação é usada informalmente, refere-se à redigitação.

Como mencionado anteriormente, o Key Vault suporta a rotação automática de certificados. Ou seja, a política de certificado associado define o ponto no tempo, seja por dias antes da expiração ou porcentagem do tempo de vida total, quando o certificado é girado no cofre de chaves. O agente de provisionamento deve ser invocado após esse point-in-time, e antes da expiração do certificado agora anterior, para distribuir esse novo certificado para todos os nós do cluster.

O Service Fabric auxilia nesse processo gerando avisos de integridade quando a data de expiração de um certificado, que está atualmente em uso no cluster, ocorre antes de um intervalo predeterminado. Um agente de provisionamento automático, a extensão de VM do Cofre de Chaves, que é configurado para observar o certificado do cofre de chaves, sonda periodicamente o cofre de chaves, deteta a rotação e recupera e instala o novo certificado. O provisionamento que ocorre por meio do recurso de segredos VM/VMSS requer que um operador autorizado atualize o VM/VMSS com o URI do Cofre de Chaves versionado que corresponde ao novo certificado.

O certificado girado agora é provisionado para todos os nós. Agora, supondo que a rotação aplicada ao certificado de cluster foi declarada pelo nome comum do assunto, vamos examinar o que acontece a seguir:

• Para novas conexões dentro e dentro do cluster, o tempo de execução do Service Fabric localiza e seleciona o certificado de correspondência emitido mais recentemente (o maior valor da propriedade NotBefore ). Esta é uma alteração em relação às versões anteriores do tempo de execução do Service Fabric.

• As conexões existentes são mantidas vivas ou podem expirar naturalmente ou terminar de outra forma, e um manipulador interno terá sido notificado de que existe uma nova correspondência.

Nota

Atualmente, a partir da versão 7.2 CU4+, o Service Fabric seleciona o certificado com o maior valor de propriedade NotBefore (emitido mais recentemente). Antes do 7.2 CU4, o Service Fabric escolhia o certificado válido com o maior valor NotAfter (expirando mais tarde).

Isto traduz-se nas seguintes observações importantes:

• A disponibilidade do cluster, ou dos aplicativos hospedados, tem precedência sobre a diretiva para girar o certificado. O cluster convergirá para o novo certificado eventualmente, mas sem garantias de tempo. Daqui resulta que:

  • Pode não ser imediatamente óbvio para um observador que o certificado rotativo substituiu completamente o seu antecessor. A única maneira de forçar a substituição imediata do certificado atualmente em uso é reinicializar as máquinas host. Não é suficiente reiniciar os nós do Service Fabric, porque os componentes do modo kernel que formam conexões de concessão em um cluster não serão afetados. Além disso, reiniciar a VM/VMSS pode causar perda temporária de disponibilidade. Para certificados de aplicativo, é suficiente reiniciar apenas as respetivas instâncias de aplicativo.

  • A introdução de um certificado rechaveado que não atenda às regras de validação pode efetivamente quebrar o cluster. O exemplo mais comum disso é o caso de um emissor inesperado, em que os certificados de cluster são declarados por nome comum de assunto com fixação do emissor, mas o certificado girado foi emitido por um emissor novo ou não declarado.

Limpeza de certificados

No momento, não há provisões no Azure para remoção explícita de certificados. Muitas vezes, é uma tarefa não trivial determinar se um certificado específico está sendo usado em um momento específico. Isso é mais difícil para certificados de aplicativo do que para certificados de cluster. O próprio Service Fabric, não sendo o agente de provisionamento, não excluirá um certificado declarado pelo usuário em nenhuma circunstância. Para os mecanismos normais de aprovisionamento:

• Os certificados declarados como segredos VM/VMSS são provisionados desde que sejam referenciados na definição de VM/VMSS e possam ser recuperados do cofre de chaves. A exclusão de um segredo ou certificado do cofre de chaves falhará nas implantações subsequentes de VM/VMSS. Da mesma forma, desabilitar uma versão secreta no cofre de chaves também falhará nas implantações de VM/VMSS que fazem referência à versão secreta.

• Versões anteriores de certificados que são provisionados por meio da extensão de VM do Cofre da Chave podem ou não estar presentes em um nó VM/VMSS. O agente recupera e instala apenas a versão atual e não remove nenhum certificado. A criação de uma nova imagem de um nó, que normalmente ocorre todos os meses, redefine o armazenamento de certificados para o conteúdo da imagem do sistema operacional e, portanto, as versões anteriores serão implicitamente removidas. Considere, no entanto, que a expansão de um conjunto de escala de máquina virtual resultará na instalação apenas da versão atual dos certificados observados. Não assuma a homogeneidade dos nós em relação aos certificados instalados.

Simplificando o gerenciamento: um exemplo de autorollover

Até agora, este artigo descreveu mecanismos e restrições, delineou regras e definições intrincadas e fez previsões terríveis de interrupções. Agora é hora de configurar o gerenciamento automático de certificados para evitar todas essas preocupações. Vamos fazer isso no contexto de um cluster do Azure Service Fabric em execução em um conjunto de escala de máquina virtual de plataforma como serviço (PaaS) v2, usando o Key Vault para gerenciamento de segredos e aproveitando identidades gerenciadas, da seguinte maneira:

• A validação de certificados é alterada de impressão digital fixada para assunto + fixação do emissor. Qualquer certificado com um assunto específico de um emissor específico é igualmente confiável.
• Os certificados são registrados e obtidos em um armazenamento confiável (Cofre de Chaves) e atualizados por um agente (aqui, a extensão de VM do Cofre de Chaves).
• O provisionamento de certificados é alterado de tempo de implantação e baseado em versão (conforme feito pelo Provedor de Recursos de Computação do Azure) para pós-implantação usando URIs do Cofre de Chaves sem versão.
• O acesso ao cofre de chaves é concedido por meio de identidades gerenciadas atribuídas pelo usuário, que são criadas e atribuídas ao conjunto de dimensionamento da máquina virtual durante a implantação.
• Após a implantação, o agente (a extensão de VM do Cofre da Chave) sonda e atualiza os certificados observados em cada nó do conjunto de escala da máquina virtual. Assim, a rotação de certificados é totalmente automatizada, porque o Service Fabric pega automaticamente o certificado válido mais recente.

A sequência é totalmente programável e automatizada, e permite uma implantação inicial sem toque do usuário de um cluster configurado para autorollover de certificado. As próximas seções fornecem etapas detalhadas, que contêm uma combinação de cmdlets do PowerShell e fragmentos de modelos JSON. A mesma funcionalidade é alcançável com todos os meios suportados de interação com o Azure.

Nota

Este exemplo pressupõe que um certificado já existe no cofre de chaves. Registrar e renovar um certificado gerenciado pelo Cofre de Chaves requer etapas manuais de pré-requisito, conforme descrito anteriormente neste artigo. Para ambientes de produção, use certificados gerenciados pelo Key Vault. Incluímos um script de exemplo específico para uma PKI interna da Microsoft.

Nota

A substituição automática de certificados só faz sentido para certificados emitidos por CA. Usar certificados autoassinados, incluindo aqueles gerados durante a implantação de um cluster do Service Fabric no portal do Azure, não faz sentido, mas ainda é possível para implantações locais ou hospedadas pelo desenvolvedor se você declarar que a impressão digital do emissor é a mesma do certificado folha.

Ponto de partida

Para abreviar, vamos supor o seguinte estado inicial:

• O cluster do Service Fabric existe e é protegido com um certificado emitido pela CA declarado por impressão digital.
• O certificado é armazenado em um cofre de chaves e provisionado como um segredo de conjunto de escala de máquina virtual.
• O mesmo certificado será usado para converter o cluster em declarações de certificado baseadas em nome comum e, portanto, pode ser validado por assunto e emissor. Se esse não for o caso, obtenha o certificado emitido pela autoridade de certificação destinado a essa finalidade e adicione-o à definição de cluster por impressão digital. Esse processo é explicado em Adicionar ou remover certificados para um cluster do Service Fabric no Azure.

Aqui está um trecho JSON de um modelo que corresponde a tal estado. O trecho omite muitas configurações necessárias e ilustra apenas os aspetos relacionados ao certificado.

  "resources": [
    {   ## VMSS definition
      "apiVersion": "[variables('vmssApiVersion')]",
      "type": "Microsoft.Compute/virtualMachineScaleSets",
      "name": "[variables('vmNodeTypeName')]",
      "location": "[variables('computeLocation')]",
      "properties": {
        "virtualMachineProfile": {
          "extensionProfile": {
            "extensions": [
            {
                "name": "[concat('ServiceFabricNodeVmExt','_vmNodeTypeName')]",
                "properties": {
                  "type": "ServiceFabricNode",
                  "autoUpgradeMinorVersion": true,
                  "publisher": "Microsoft.Azure.ServiceFabric",
                  "settings": {
                    "clusterEndpoint": "[reference(parameters('clusterName')).clusterEndpoint]",
                    "nodeTypeRef": "[variables('vmNodeTypeName')]",
                    "dataPath": "D:\\SvcFab",
                    "durabilityLevel": "Bronze",
                    "certificate": {
                        "thumbprint": "[parameters('primaryClusterCertificateTP')]",
                        "x509StoreName": "[parameters('certificateStoreValue')]"
                    }
                  },
                  "typeHandlerVersion": "1.1"
                }
            },}},
          "osProfile": {
            "adminPassword": "[parameters('adminPassword')]",
            "adminUsername": "[parameters('adminUsername')]",
            "secrets": [
            {
                "sourceVault": {
                    "id": "[resourceId('Microsoft.KeyVault/vaults', parameters('keyVaultName'))]"
                },
                "vaultCertificates": [
                {
                    "certificateStore": "[parameters('certificateStoreValue')]",
                    "certificateUrl": "[parameters('clusterCertificateUrlValue')]"
                },
            ]}]
        },
    },
    {   ## cluster definition
        "apiVersion": "[variables('sfrpApiVersion')]",
        "type": "Microsoft.ServiceFabric/clusters",
        "name": "[parameters('clusterName')]",
        "location": "[parameters('clusterLocation')]",
        "certificate": {
            "thumbprint": "[parameters('primaryClusterCertificateTP')]",
            "x509StoreName": "[parameters('certificateStoreValue')]"
        },
    }
  ]

O código anterior diz essencialmente que o certificado com impressão digital e encontrado no URI json [parameters('clusterCertificateUrlValue')] do Cofre da Chave é declarado como o único certificado do cluster, por impressão json [parameters('primaryClusterCertificateTP')] digital.

Em seguida, vamos configurar os recursos adicionais necessários para garantir a substituição automática do certificado.

Configurar os recursos de pré-requisito

Como mencionado anteriormente, um certificado provisionado como um segredo de conjunto de escala de máquina virtual é recuperado do cofre de chaves pelo serviço Microsoft Compute Resource Provider. Ele faz isso usando sua identidade de primeira parte em nome do operador de implantação. Esse processo mudará para o autorollover. Você alternará para usar uma identidade gerenciada atribuída ao conjunto de dimensionamento da máquina virtual e que tenha recebido permissões GET nos segredos desse cofre.

Você deve implantar os próximos trechos ao mesmo tempo. Eles são listados individualmente apenas para análise e explicação play-by-play.

Primeiro, defina uma identidade atribuída pelo usuário (os valores padrão são incluídos como exemplos). Para mais informações, consulte a documentação oficial.

{
  "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "userAssignedIdentityName": {
      "type": "string",
      "defaultValue": "sftstuaicus",
      "metadata": {
        "description": "User-assigned managed identity name"
      }
    },
  },
  "variables": {
      "vmssApiVersion": "2018-06-01",
      "sfrpApiVersion": "2018-02-01",
      "miApiVersion": "2018-11-30",
      "kvApiVersion": "2018-02-14",
      "userAssignedIdentityResourceId": "[resourceId('Microsoft.ManagedIdentity/userAssignedIdentities', parameters('userAssignedIdentityName'))]"
  },    
  "resources": [
    {
      "type": "Microsoft.ManagedIdentity/userAssignedIdentities",
      "name": "[parameters('userAssignedIdentityName')]",
      "apiVersion": "[variables('miApiVersion')]",
      "location": "[resourceGroup().location]"
    },
  ]}

Em seguida, conceda a essa identidade acesso aos segredos do cofre de chaves. Para obter as informações mais atuais, consulte a documentação oficial.

  "resources":
  [{
      "type": "Microsoft.KeyVault/vaults/accessPolicies",
      "name": "[concat(parameters('keyVaultName'), '/add')]",
      "apiVersion": "[variables('kvApiVersion')]",
      "properties": {
        "accessPolicies": [
          {
            "tenantId": "[reference(variables('userAssignedIdentityResourceId'), variables('miApiVersion')).tenantId]",
            "objectId": "[reference(variables('userAssignedIdentityResourceId'), variables('miApiVersion')).principalId]",
            "dependsOn": [
              "[variables('userAssignedIdentityResourceId')]"
            ],
            "permissions": {
              "secrets": [
                "get",
                "list"
              ]}}]}}]

Na próxima etapa, você fará o seguinte:

• Atribua a identidade atribuída pelo usuário ao conjunto de dimensionamento da máquina virtual.
• Declare a dependência do conjunto de escala da máquina virtual na criação da identidade gerenciada e no resultado da concessão de acesso ao cofre de chaves.
• Declare a extensão da VM do Cofre da Chave e exija que ela recupere os certificados observados na inicialização. Para obter mais informações, consulte a documentação oficial da extensão Key Vault VM para Windows .
• Atualize a definição da extensão de VM do Service Fabric para depender da extensão de VM do Cofre da Chave e para converter a declaração de certificado de cluster de impressão digital para nome comum.

Nota

Estas alterações estão a ser feitas como um único passo porque se enquadram no âmbito do mesmo recurso.

  "parameters": {
    "kvvmextPollingInterval": {
      "type": "string",
      "defaultValue": "3600",
      "metadata": {
        "description": "kv vm extension polling interval in seconds"
      }
    },
    "kvvmextLocalStoreName": {
      "type": "string",
      "defaultValue": "MY",
      "metadata": {
        "description": "kv vm extension local store name"
      }
    },
    "kvvmextLocalStoreLocation": {
      "type": "string",
      "defaultValue": "LocalMachine",
      "metadata": {
        "description": "kv vm extension local store location"
      }
    },
    "kvvmextObservedCertificates": {
      "type": "array",
      "defaultValue": [
                "https://sftestcus.vault.azure.net/secrets/sftstcncluster",
                "https://sftestcus.vault.azure.net/secrets/sftstcnserver"
            ],
      "metadata": {
        "description": "kv vm extension observed certificates versionless uri"
      }
    },
    "certificateCommonName": {
      "type": "string",
      "defaultValue": "cus.cluster.sftstcn.system.servicefabric.azure-int",
      "metadata": {
        "description": "Certificate Common name"
      }
    },
  },
  "resources": [
  {
    "apiVersion": "[variables('vmssApiVersion')]",
    "type": "Microsoft.Compute/virtualMachineScaleSets",
    "name": "[variables('vmNodeTypeName')]",
    "location": "[variables('computeLocation')]",
    "dependsOn": [
      "[variables('userAssignedIdentityResourceId')]",
      "[concat('Microsoft.KeyVault/vaults/', concat(parameters('keyVaultName'), '/accessPolicies/add'))]"
    ],
    "identity": {
      "type": "UserAssigned",
      "userAssignedIdentities": {
        "[variables('userAssignedIdentityResourceId')]": {}
      }
    },
    "virtualMachineProfile": {
      "extensionProfile": {
        "extensions": [
        {
          "name": "KVVMExtension",
          "properties": {
            "publisher": "Microsoft.Azure.KeyVault",
            "type": "KeyVaultForWindows",
            "typeHandlerVersion": "1.0",
            "autoUpgradeMinorVersion": true,
            "settings": {
                "secretsManagementSettings": {
                    "pollingIntervalInS": "[parameters('kvvmextPollingInterval')]",
                    "linkOnRenewal": false,
                    "observedCertificates": "[parameters('kvvmextObservedCertificates')]",
                    "requireInitialSync": true
                }
            }
          }
        },
        {
        "name": "[concat('ServiceFabricNodeVmExt','_vmNodeTypeName')]",
        "properties": {
          "type": "ServiceFabricNode",
          "provisionAfterExtensions" : [ "KVVMExtension" ],
          "publisher": "Microsoft.Azure.ServiceFabric",
          "settings": {
            "certificate": {
                "commonNames": [
                    "[parameters('certificateCommonName')]"
                ],
                "x509StoreName": "[parameters('certificateStoreValue')]"
            }
            },
            "typeHandlerVersion": "1.0"
          }
        },
  ] } ## extension profile
  },  ## VM profile
  "osProfile": {
    "adminPassword": "[parameters('adminPassword')]",
    "adminUsername": "[parameters('adminUsername')]",
  } 
  }
  ]

Embora não esteja explicitamente listado no código anterior, observe que a URL do certificado do cofre de chaves foi removida da OsProfile seção do conjunto de escala da máquina virtual.

A etapa final é atualizar a definição de cluster para alterar a declaração de certificado de impressão digital para nome comum. Também estamos fixando as impressões digitais do emissor:

  "parameters": {
    "certificateCommonName": {
      "type": "string",
      "defaultValue": "cus.cluster.sftstcn.system.servicefabric.azure-int",
      "metadata": {
        "description": "Certificate Common name"
      }
    },
    "certificateIssuerThumbprint": {
      "type": "string",
      "defaultValue": "1b45ec255e0668375043ed5fe78a09ff1655844d,d7fe717b5ff3593764f4d90654d86e8362ec26c8,3ac7c3cac8de0dd392c02789c8be97474f456960,96ea05926e2e42cc207e358668be2c316857fb5e",
      "metadata": {
        "description": "Certificate issuer thumbprints separated by comma"
      }
    },
  },
  "resources": [
    {
      "apiVersion": "[variables('sfrpApiVersion')]",
      "type": "Microsoft.ServiceFabric/clusters",
      "name": "[parameters('clusterName')]",
      "location": "[parameters('clusterLocation')]",
      "properties": {
        "certificateCommonNames": {
          "commonNames": [{
              "certificateCommonName": "[parameters('certificateCommonName')]",
              "certificateIssuerThumbprint": "[parameters('certificateIssuerThumbprint')]"
          }],
          "x509StoreName": "[parameters('certificateStoreValue')]"
        },
  ]

Neste ponto, você pode executar as atualizações mencionadas anteriormente em uma única implantação. Por sua vez, o serviço Provedor de Recursos do Service Fabric divide a atualização do cluster em várias etapas, conforme descrito no segmento sobre a conversão de certificados de cluster de impressão digital para nome comum.

Análise e observações

Esta seção é um catch-all para explicar conceitos e processos que foram apresentados ao longo deste artigo, bem como chamar a atenção para alguns outros aspetos importantes.

Sobre o provisionamento de certificados

A extensão da VM do Cofre da Chave, como um agente de provisionamento, é executada continuamente em uma frequência predeterminada. Se ele não conseguir recuperar um certificado observado, ele continua para o próximo na linha e, em seguida, hiberna até o próximo ciclo. A extensão de VM do Service Fabric, como o agente de inicialização do cluster, requer os certificados declarados antes que o cluster possa se formar. Isso, por sua vez, significa que a extensão de VM do Service Fabric pode ser executada somente após a recuperação bem-sucedida dos certificados de cluster, indicados aqui pela cláusula e pela json "provisionAfterExtensions" : [ "KVVMExtension" ]" configuração da extensão de VM do Cofre da json "requireInitialSync": true Chave.

Isso indica à extensão VM do Cofre da Chave que, na primeira execução (após a implantação ou uma reinicialização), ela deve percorrer seus certificados observados até que todos sejam baixados com êxito. Definir esse parâmetro como false, juntamente com uma falha na recuperação dos certificados de cluster, resultaria em uma falha da implantação do cluster. Por outro lado, exigir uma sincronização inicial com uma lista incorreta ou inválida de certificados observados resultaria em uma falha da extensão da VM do Cofre da Chave e, novamente, uma falha na implantação do cluster.

Vinculação de certificados, explicada

Você deve ter notado o sinalizador de extensão linkOnRenewal de VM do Cofre da Chave e o fato de que ele está definido como false. Essa configuração aborda o comportamento controlado por esse sinalizador e suas implicações no funcionamento de um cluster. Esse comportamento é específico do Windows.

De acordo com a sua definição:

"linkOnRenewal": <Only Windows. This feature enables auto-rotation of SSL certificates, without necessitating a re-deployment or binding. e.g.: false>,

Os certificados usados para estabelecer uma conexão TLS são normalmente adquiridos como um identificador por meio do Provedor de Suporte de Segurança do canal S. Ou seja, o cliente não acessa diretamente a chave privada do próprio certificado. O canal S suporta redirecionamento ou vinculação de credenciais na forma de uma extensão de certificado, CERT_RENEWAL_PROP_ID.

Se essa propriedade for definida, seu valor representa a impressão digital do certificado de renovação e, portanto, o canal S tentará carregar o certificado vinculado. De facto, o canal S atravessará esta lista ligada e, esperemos, acíclica até chegar ao certificado final , sem marca de renovação. Esse recurso, quando usado criteriosamente, é uma ótima mitigação contra uma perda de disponibilidade causada, por exemplo, por certificados expirados.

Em outros casos, pode ser a causa de interrupções difíceis de diagnosticar e mitigar. O canal S executa a travessia de certificados em suas propriedades de renovação incondicionalmente, independentemente do assunto, emissores ou quaisquer outros atributos específicos que participam da validação do certificado resultante pelo cliente. É possível que o certificado resultante não tenha nenhuma chave privada associada ou que a chave não tenha sido ACLed para seu potencial consumidor.

Se a vinculação estiver habilitada, a extensão da VM do Cofre da Chave, quando recuperar um certificado observado do cofre de chaves, tentará encontrar certificados existentes correspondentes para vinculá-los por meio da propriedade de extensão de renovação. A correspondência é baseada exclusivamente no nome alternativo da entidade (SAN) e funciona, se houver dois certificados existentes, conforme mostrado nos exemplos a seguir: A: Nome do certificado (CN) = "Acessórios de Alice", SAN = {"alice.universalexports.com"}, renovação = '' B: CN = "Bob's bits", SAN = {"bob.universalexports.com", "bob.universalexports.net"}, renovação = ''

Suponha que um certificado C é recuperado pela extensão Key Vault VM: CN = "malware Mallory", SAN = {"alice.universalexports.com", "bob.universalexports.com", "mallory.universalexports.com"}

A lista de SAN do certificado A está totalmente incluída em C's e, portanto, A.renewal = C.thumbprint. A lista de SAN do certificado B tem uma interseção comum com a de C, mas não está totalmente incluída nela, portanto, B.renewal permanece vazia.

Qualquer tentativa de invocar AcquireCredentialsHandle (canal S) nesse estado no certificado A acaba enviando C para a parte remota. No caso do Service Fabric, o subsistema Transporte de um cluster usa o canal S para autenticação mútua e, portanto, o comportamento descrito anteriormente afeta diretamente a comunicação fundamental do cluster. Continuando com o exemplo anterior e assumindo que A é o certificado de cluster, o que acontece a seguir depende de:

• Se a chave privada de C não for ACLed para a conta como o Service Fabric está sendo executado, você verá falhas ao adquirir a chave privada (SEC_E_UNKNOWN_CREDENTIALS ou similar).
• Se a chave privada de C estiver acessível, você verá falhas de autorização retornadas pelos outros nós (CertificateNotMatched, não autorizado e assim por diante).

Em ambos os casos, o transporte falha e o cluster pode ficar inativo. Os sintomas variam. Para piorar as coisas, a vinculação depende da ordem de renovação, que é ditada pela ordem da lista de certificados observados da extensão de VM do Cofre de Chaves, o cronograma de renovação no cofre de chaves ou até mesmo erros transitórios que alterariam a ordem de recuperação.

Para mitigar tais incidentes, recomendamos o seguinte:

• Não misture os nomes alternativos de assunto de diferentes certificados do vault. Cada certificado de cofre deve servir a uma finalidade distinta, e seu assunto e SAN devem refletir isso com especificidade.

• Inclua o nome comum do assunto na lista SAN (como, literalmente, CN=<subject common name>).

• Se você não tiver certeza sobre como proceder, desative a vinculação na renovação para certificados que são provisionados com a extensão de VM do Cofre da Chave.

  Nota

  A desativação da vinculação é uma propriedade de nível superior da extensão de VM do Cofre da Chave e não pode ser definida para certificados observados individuais.

Por que devo usar uma identidade gerenciada atribuída pelo usuário? Quais são as implicações de usá-lo?

Como ficou evidente nos trechos JSON anteriores, um sequenciamento específico das operações e atualizações é necessário para garantir o sucesso da conversão e manter a disponibilidade do cluster. Especificamente, o recurso de conjunto de escala de máquina virtual declara e usa sua identidade para recuperar segredos em uma única atualização (da perspetiva do usuário).

A extensão de VM do Service Fabric, que inicializa o cluster, depende da conclusão da extensão de VM do Cofre de Chaves, que, por sua vez, depende da recuperação bem-sucedida dos certificados observados.

A extensão de VM do Cofre de Chaves usa a identidade do conjunto de dimensionamento de máquina virtual para acessar o cofre de chaves, o que significa que a política de acesso no cofre de chaves já deve ter sido atualizada antes da implantação do conjunto de dimensionamento de máquina virtual.

Para descartar a criação de uma identidade gerenciada ou atribuí-la a outro recurso, o operador de implantação deve ter a função necessária (ManagedIdentityOperator) na assinatura ou no grupo de recursos, além das funções necessárias para gerenciar os outros recursos referenciados no modelo.

Do ponto de vista da segurança, lembre-se de que o conjunto de escala da máquina virtual é considerado um limite de segurança em relação à sua identidade do Azure. Isso significa que qualquer aplicativo hospedado na VM poderia, em princípio, obter um token de acesso representando a VM. Os tokens de acesso de identidade gerenciada são obtidos do ponto de extremidade não autenticado do Serviço de Metadados de Instância. Se você considerar a VM como um ambiente compartilhado ou multilocatário, esse método de recuperação de certificados de cluster pode não ser indicado. É, no entanto, o único mecanismo de provisionamento adequado para a substituição automática de certificados.

Solução de problemas e perguntas frequentes

P: Como posso me inscrever programaticamente em um certificado gerenciado pelo Cofre de Chaves?

Descubra o nome do emissor na documentação do Cofre da Chave e substitua-o no seguinte script:

  $issuerName=<depends on your PKI of choice>
	$clusterVault="sftestcus"
	$clusterCertVaultName="sftstcncluster"
	$clusterCertCN="cus.cluster.sftstcn.system.servicefabric.azure-int"
	Set-AzKeyVaultCertificateIssuer -VaultName $clusterVault -Name $issuerName -IssuerProvider $issuerName
	$distinguishedName="CN=" + $clusterCertCN
	$policy = New-AzKeyVaultCertificatePolicy `
	    -IssuerName $issuerName `
	    -SubjectName $distinguishedName `
	    -SecretContentType 'application/x-pkcs12' `
	    -Ekus "1.3.6.1.5.5.7.3.1", "1.3.6.1.5.5.7.3.2" `
	    -ValidityInMonths 4 `
	    -KeyType 'RSA' `
	    -RenewAtPercentageLifetime 75        
	Add-AzKeyVaultCertificate -VaultName $clusterVault -Name $clusterCertVaultName -CertificatePolicy $policy
	
	# poll the result of the enrollment
	Get-AzKeyVaultCertificateOperation -VaultName $clusterVault -Name $clusterCertVaultName 

P: O que acontece quando um certificado é emitido por um emissor não declarado ou não especificado? Onde posso obter uma lista exaustiva de emitentes ativos de uma PKI específica?

Se a declaração de certificado especificar impressões digitais do emissor e o emissor direto do certificado não estiver incluído na lista de emissores fixos, o certificado será considerado inválido, independentemente de sua raiz ser confiável ou não pelo cliente. Portanto, é fundamental garantir que a lista de emissores esteja atualizada. A introdução de um novo emissor é um acontecimento raro e deve ser amplamente divulgado antes de começar a emitir certificados.

Em geral, uma PKI publica e mantém uma declaração de prática de certificação, de acordo com IETF RFC 7382. Além de outras informações, a declaração inclui todos os emissores ativos. Recuperar essa lista programaticamente pode diferir de uma PKI para outra.

Para PKIs internas da Microsoft, consulte a documentação interna sobre os pontos de extremidade e SDKs usados para recuperar os emissores autorizados. É responsabilidade do proprietário do cluster revisar essa lista periodicamente para garantir que sua definição de cluster inclua todos os emissores esperados.

P: Várias PKIs são suportadas?

Sim. Você não pode declarar várias entradas CN no manifesto do cluster com o mesmo valor, mas pode listar emissores de várias PKIs que correspondem à mesma CN. Não é uma prática recomendada, e as práticas de transparência de certificados podem impedir que esses certificados sejam emitidos. No entanto, como meio de migrar de uma PKI para outra, este é um mecanismo aceitável.

P: E se o certificado de cluster atual não for emitido pela CA ou não tiver o assunto pretendido?

Obtenha um certificado com o assunto pretendido e adicione-o à definição do cluster como secundário, por impressão digital. Depois que a atualização for concluída com êxito, inicie outra atualização de configuração de cluster para converter a declaração de certificado em nome comum.