Gerenciar certificados em clusters do Service Fabric

Este artigo aborda os aspectos de gerenciamento dos certificados que são usados para proteger a comunicação em clusters Service Fabric do Azure. Ele complementa a introdução à segurança do cluster Service Fabric e ao 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 com os controles que o Service Fabric expões para configurar a segurança de um cluster.

Isenção de responsabilidade

Este artigo emparelha aspectos teóricos do gerenciamento de certificados com exemplos práticos que abordam as especificidades dos serviços, tecnologias e assim por diante. Como grande parte do público-alvo é interno da Microsoft, o artigo refere-se a serviços, tecnologias e produtos específicos do Azure. Se determinados detalhes específicos da Microsoft não se aplicarem a você, fique à vontade para pedir esclarecimentos ou orientações na seção de comentários no final.

Definição do gerenciamento de certificados

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

No entanto, um certificado também é um objeto perecível, pois seu tempo de vida é finito e é suscetível a comprometimento. A divulgação acidental ou uma exploração bem-sucedida podem tornar um certificado inútil do ponto de vista da segurança. Essa característica implica a necessidade de alterar certificados, tanto rotineiramente quanto em resposta a um incidente de segurança.

Outro aspecto do gerenciamento de certificados, que é um tópico separado, é a proteção das chaves privadas do certificado ou dos segredos que protegem as identidades das entidades envolvidas em adquirir e provisionar certificados.

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

Algumas operações de gerenciamento, como registro, configuração de política e controles de autorização, vão além do escopo deste artigo. Outras operações, como provisionamento, renovação, redirecionamento ou revogação, estão relacionadas apenas a Service Fabric. No entanto, o artigo aborda eles um pouco, pois entender essas operações pode ajudar você a proteger seu cluster corretamente.

Sua meta imediata provavelmente será automatizar o gerenciamento de certificados o máximo possível para garantir a disponibilidade ininterrupta do cluster. Como o processo é livre de toque do usuário, você também deseja oferecer garantias de segurança. Com Service Fabric clusters, essa meta é alcançável.

O restante do artigo primeiro desconstrói o gerenciamento de certificados e, depois, se concentra em habilitar o registro automático.

Ele aborda especificamente os seguintes tópicos:

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

O artigo não aborda estes tópicos:

• Proteção e gerenciamento de nomes de domínio
• Registro em certificados
• Configuração de controles de autorização para impor a emissão de certificado.

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

Funções e entidades envolvidas no gerenciamento de certificados

A abordagem de segurança em um cluster Service Fabric é um caso de "proprietário do cluster declara isso, Service Fabric runtime impõe isso". Isso significa que quase nenhum dos certificados, chaves ou outras credenciais de identidades que participam do funcionamento de um cluster vem do próprio serviço. Todos 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 o necessário e ajudar a garantir a segurança deles em todos os momentos.

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

• Os certificados que são 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 que são declarados como no bullet point anterior são instalados com suas chaves privadas correspondentes incluídas.
• Os certificados que são declarados nas regras de apresentação devem seguir as regras de validação.

O Service Fabric, por sua vez, assume as responsabilidades a seguir:

• Localizar certificados que correspondam às declarações na definição do cluster
• Conceder acesso às chaves privadas correspondentes às entidades controladas pelo Service Fabric de acordo com uma base de necessidade
• Validar os certificados de acordo com as melhores práticas de segurança e a definição do cluster estabelecidas
• Gerar alertas de expiração iminente de certificados ou falhas para executar as etapas básicas de validação de certificado
• Validar (em algum grau) que os aspectos relacionados ao certificado da definição do cluster são atendidos pela configuração subjacente dos hosts

Consequentemente, a responsabilidade do gerenciamento de certificados (como operações ativas) recai exclusivamente sobre o proprietário do cluster. Nas próximas sessões examinaremos mais detalhadamente cada operação de gerenciamento, incluindo os mecanismos disponíveis e seu impacto no cluster.

O percurso de um certificado

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

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

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

3. Em seguida, um solicitante autorizado se registra em um certificado por meio de um serviço de gerenciamento de segredo. No Azure, o serviço de gerenciamento de segredo de escolha é o Azure Key Vault, que armazena com segurança e permite a recuperação de segredos e certificados por entidades autorizadas. O Key Vault também renova e recria chaves do certificado conforme configurado na política de certificação associada. Esse tutorial usa o Microsoft Entra ID como 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 nos computadores que hospedam o cluster.

5. O serviço do Service Fabric (com execução privilegiada em cada nó) concede acesso ao certificado para entidades permitidas do Service Fabric; eles são designados por grupos locais e divididos entre ServiceFabricAdministrators e ServiceFabricAllowedUsers.

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

7. O agente de provisionamento monitora o certificado do cofre de chaves e, quando detecta a renovação, dispara o fluxo de provisionamento. O proprietário do cluster então atualiza a definição do cluster, se necessário, para indicar uma intenção de renovar 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 as finalidades deste artigo, as duas primeiras etapas na sequência anterior não estão relacionadas. Sua única conexão é que o assunto comum do certificado é o nome DNS que é declarado na definição do cluster.

O fluxo de emissão e provisionamento de certificado é ilustrado nos seguintes diagramas:

Para certificados declarados por impressão digital

Para certificados declarados pelo nome comum do sujeito

Registro de certificado

O tópico do registro de certificado é abordado detalhadamente na documentação do Key Vault. Uma sinopse está incluída aqui para continuidade e uma referência mais fácil.

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

• O solicitante cria uma política de certificação no Key Vault, que especifica o domínio/entidade do certificado, o emissor desejado, o tipo de chave e o comprimento, o uso de chave pretendido e muito mais. Para saber mais, confira Certificados no Azure Key Vault.

• 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 de cofre e uma solicitação de assinatura de certificado assinada com a chave privada e que, em seguida, é encaminhada para o emissor designado para assinatura.

• Depois que o emissor ou AC (autoridade de certificação) responder com o certificado assinado, o resultado é mesclado no cofre de chaves e os dados do certificado estarão disponíveis como a seguir:

  • 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 de criptografia (encapsular/desencapsular, 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 de renovação desta política. É altamente recomendável que os certificados do cofre não compartilhem entidades ou domínios ou nomes DNS; pois isso pode ser disruptivo em um cluster para provisionar instâncias de certificado de diferentes certificados de cofre, com entidades idênticas, mas com outros atributos bastante diferentes, como emissor, usos de chave etc. Nesse ponto, há um certificado no cofre de chaves, pronto para consumo. Agora vamos explorar o restante do processo.

Provisionamento de certificado

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. (Não esqueça que o Service Fabric não provisiona certificados.)

No contexto deste artigo, o cluster será hospedado em uma coleção de VMs (máquinas virtuais) do Azure ou conjuntos de dimensionamento de máquinas virtuais. No Azure, você pode provisionar um certificado de um cofre para uma VM/VMSS usando os mecanismos a seguir. Isso pressupõe, como antes, que o agente de provisionamento recebeu permissões secretas 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, desde segurança até disponibilidade, e ele não será discutido aqui. Para obter mais informações, confira Perguntas frequentes dos conjuntos de dimensionamento de máquinas virtuais do Azure.

• Como um segredo do conjunto de dimensionamento de máquinas virtuais durante a implantação: usando sua própria identidade de terceiros em nome do operador, o serviço de computação recupera o certificado de um cofre habilitado para a implantação de modelo e o instala em cada nó do conjunto de dimensionamento de máquinas virtuais, como descrito em Perguntas frequentes dos conjuntos de dimensionamento de máquinas virtuais do Azure.

  Observação

  Essa abordagem permite apenas o provisionamento de segredos com versão.

• Usando a extensão da VM do Key Vault. Isso permite provisionar certificados usando declarações sem versão, com atualização periódica de certificados observados. Nesse caso, espera-se que a VM/VMSS tenha uma identidade gerenciada, uma identidade que tenha recebido acesso aos cofres de chaves que contenham os certificados observados.

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

Em comparação, o provisionamento baseado na extensão de VM do Key Vault sempre instala a versão mais recente de cada certificado observado. Isso o torna mais adequado apenas para clusters protegidos por certificados declarados por nome comum do sujeito. Para enfatizar, não use um mecanismo de provisionamento de atualização automática (como a extensão da VM do Key Vault) para certificados declarados pela instância (ou seja, por impressão digital). O risco de perder a disponibilidade é considerável.

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

Consumo e monitoramento de certificado

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

Lembre-se de que os certificados no Service Fabric são usados para várias 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 runtime Service Fabric verifica regularmente o repositório de certificados, procurando correspondências para cada uma das regras de apresentação conhecidas.

Para cada certificado correspondente, a chave privada correspondente está localizada e sua lista de controle de acesso discricionário é atualizada para incluir permissões (leitura e execução, normalmente) que são concedidas à identidade que as exige.

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

Rotação de certificados

Observação

A IEFT (Força-Tarefa de Engenharia da Internet) RFC 3647 define formalmente a renovação como a emissão de um certificado com os mesmos atributos que o certificado que está sendo substituído. O emissor, a chave pública do assunto e as informações são preservados. O redirecionamento é a emissão de um certificado com um novo par de chaves, sem restrições sobre se o emissor pode alterar. Como a distinção pode ser importante (considere o caso de certificados declarados pelo nome comum da entidade com fixação do emissor), este artigo usa termo neutro rotação para cobrir ambos os cenários. Lembre-se de que, quando é usada renovação informalmente, ela se refere ao redirecionamento.

Conforme mencionado anteriormente, Key Vault dá suporte à rotação automática de certificados. Ou seja, a política de certificação associada define o ponto no tempo, seja por dias antes da expiração ou do percentual do tempo de vida total, quando ocorre a rotação de certificado no cofre de chaves. O agente de provisionamento deve ser invocado após esse ponto no tempo e antes da expiração do certificado agora anterior para distribuir esse novo certificado para todos os nós do cluster.

O Service Fabric ajuda neste processo gerando avisos de integridade quando a data de vencimento de um certificado e que está em uso no momento no cluster ocorrer antes de um intervalo predeterminado. Um agente de provisionamento automático, a extensão da VM do Key Vault, que é configurada para observar o certificado do cofre de chaves, pesquisa periodicamente o cofre de chaves, detecta a rotação e recupera e instala o novo certificado. O provisionamento que ocorre por meio do recurso de segredos VM/VMSS requer um operador autorizado para atualizar a VM/VMSS com o URI do Key Vault com versão que corresponde ao novo certificado.

O certificado que passou por rotação agora é provisionado para todos os nós. Supondo que a rotação aplicada ao certificado do cluster foi declarada pelo nome comum da entidade, vamos examinar o que acontece a seguir:

• Para novas conexões internas, bem como no cluster, o runtime do Service Fabric localizará e selecionará o certificado de correspondência emitido mais recentemente (o maior valor da propriedade NotBefore). Essa é uma alteração de versões anteriores do runtime do Service Fabric.

• As conexões existentes serão mantidas ativas ou permitidas até que expirem naturalmente ou se encerrem de outra forma; e um manipulador interno terá sido notificado de que existe uma nova correspondência.

Observação

Atualmente, a partir da versão 7.2 CU4+, Service Fabric seleciona o certificado com o maior (emitido mais recentemente) valor da propriedade NotBefore. Antes da 7.2 CU4, Service Fabric selecionou o certificado válido com o maior (último vencimento) valor NotAfter.

Isso se traduz nas seguintes observações importantes:

• A disponibilidade do cluster, ou das aplicações hospedadas, tem precedência sobre a diretiva de rotação do certificado. O cluster convergirá no novo certificado eventualmente, mas sem garantias de tempo. Como consequência:

  • Pode não ser imediatamente óbvio para um observador que o certificado que passou por rotação substituiu completamente seu predecessor. A única maneira de forçar a substituição imediata do certificado atualmente em uso é reinicializar os computadores host. Reiniciar os nós do Service Fabric não é suficiente, pois os componentes de modo kernel que formam as conexões de concessão em um cluster não serão afetados. A reinicialização da VM/VMSS pode causar perda temporária de disponibilidade. Para certificados de aplicativo, basta reiniciar apenas as respectivas instâncias do aplicativo.

  • A introdução de um certificado com recriação de chave que não atenda às regras de validação pode, efetivamente, interromper o cluster. O exemplo mais comum disso é o caso de um emissor inesperado: os certificados de cluster são declarados pelo nome comum da entidade com fixação do emissor, mas o certificado que passou por rotação foi emitido por um emissor novo e não declarado.

Limpeza de certificado

Neste momento, não há provisões no Azure para a remoção explícita de certificados. Geralmente, trata-se de uma tarefa não trivial determinar se um certificado específico está sendo usado em um momento específico. Isso é mais complicado para certificados de aplicativo do que para certificados de cluster. O Service Fabric em si, não sendo o agente de provisionamento, não excluirá um certificado declarado pelo usuário sob nenhuma circunstância. Para os mecanismos de provisionamento padrão:

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

• Versões anteriores de certificados provisionados por meio da extensão da VM do Key Vault podem ou não estar presentes em um nó VM/VMSS. O agente só recupera e instala a versão atual, não removendo nenhum certificado. A recriação da imagem de um nó, que normalmente ocorre mensalmente, redefine o repositório de certificados para o conteúdo da imagem do sistema operacional e, portanto, as versões anteriores serão removidas implicitamente. No entanto, cogite que escalar verticalmente um conjunto de dimensionamento de máquinas virtuais resultará somente na versão atual dos certificados observados que estão sendo instalados. Não suponha a homogeneidade dos nós em relação aos certificados instalados.

Simplificação do gerenciamento: um exemplo de substituição automática

Até agora, este artigo descreveu mecanismos e restrições, regras e definições complexas e fizemos previsões ruins de interrupções. Agora é hora de configurar o gerenciamento automático de certificados para evitar todas essas preocupações. Estamos fazendo isso no contexto de um cluster do Service Fabric do Azure em execução em um conjunto de dimensionamento de máquinas virtuais v2 de PaaS (plataforma como serviço), usando o Key Vault para o gerenciamento de segredos e aproveitando identidades gerenciadas da seguinte maneira:

• A validação de certificados é alterada de fixação de impressão digital para assunto + fixação de emissor. Qualquer certificado com um assunto específico de um emissor específico é igualmente confiável.
• Os certificados são registrados e obtidos de um repositório confiável (Key Vault) e atualizados por um agente (aqui, a extensão da VM do KeyVault).
• O provisionamento de certificados é alterado do tipo tempo de implantação e baseado em versão (como é feito pelo Compute Resource Provider do Azure) para o tipo pós-implantação e usando URIs de KeyVault sem versão.
• O acesso ao cofre de chaves é concedido por meio de identidades gerenciadas atribuídas pelo usuário; que é criada e atribuída ao conjunto de dimensionamento de máquinas virtuais durante a implantação.
• Após a implantação, o agente (a extensão da VM do Key Vault) pesquisa e atualiza os certificados observados em cada nó do conjunto de dimensionamento de máquinas virtuais. A rotação de certificados é, portanto, totalmente automatizada, porque Service Fabric pega automaticamente o certificado válido mais recente.

A sequência é totalmente programável por script e automatizada e permite uma implantação inicial sem intervenção do usuário de um cluster configurado para a substituição automática do certificado. As próximas seções fornecem etapas detalhadas, que contêm uma combinação de cmdlets e fragmentos do PowerShell de modelos JSON. A mesma funcionalidade pode ser obtida com todos os meios com suporte de interação com o Azure.

Observação

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

Observação

A prolongação automática do certificado faz sentido apenas para certificados emitidos pela AC. O uso de certificados autoassinados, incluindo os gerados durante a implantação de um cluster de 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 inicial

Para resumir, vamos pressupor o seguinte estado inicial:

• O cluster do Service Fabric existe e está protegido com um certificado emitido por uma AC (autoridade de certificação) declarada pela impressão digital.
• O certificado é armazenado em um cofre de chaves e é provisionado como um segredo do conjunto de dimensionamento de máquinas virtuais.
• O mesmo certificado será usado para converter o cluster em declarações comuns de certificado baseadas em nome e, portanto, pode ser validado pela entidade e pelo emissor. Se esse não for o caso, obtenha o certificado emitido pela AC destinado a essa finalidade e adicione-o à definição de cluster por impressão digital. Este 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 esse estado. O trecho omite muitas configurações necessárias e ilustra apenas os aspectos 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')]"
        },
    }
  ]

Basicamente, o código anterior diz que o certificado com impressão digital json [parameters('primaryClusterCertificateTP')] e encontrado no URI do KeyVault json [parameters('clusterCertificateUrlValue')] é declarado como o certificado exclusivo do cluster, por impressão digital.

A seguir, 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 do conjunto de dimensionamento de máquinas virtuais é recuperado do cofre de chaves pelo serviço do provedor de recursos do Microsoft.Compute. Ele faz isso usando sua identidade de primeira parte em nome do operador de implantação. Esse processo será alterado para a sobreposição automática. Você passará a usar uma identidade gerenciada atribuída ao conjunto de dimensionamento de máquinas virtuais e que recebeu permissões GET sobre os segredos nesse cofre.

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

Primeiro, defina uma identidade atribuída pelo usuário (os valores padrão estão incluídos como exemplos). Para obter mais informações, confira 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 para 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:

• Atribuiremos a identidade atribuída ao usuário ao seu conjunto de dimensionamento de máquinas virtuais.
• Declararemos a dependência do conjunto de dimensionamento de máquinas virtuais 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 Key Vault e exija que ele recupere os certificados observados na inicialização. Para obter mais informações, consulte a documentação oficial da Extensão da VM do Key Vault para Windows.
• Atualize a definição da extensão da VM de Service Fabric para depender da extensão da VM do Key Vault e converter a declaração de certificado de cluster de impressão digital em nome comum.

Observação

Essas alterações estão sendo feitas como uma única etapa porque estão dentro do escopo 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 seção OsProfile do conjunto de dimensionamento de máquinas virtuais.

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 momento, você pode executar as atualizações mencionadas anteriormente em uma única implantação. Por sua vez, o serviço do provedor de recursos do Service Fabric dividirá a atualização do cluster em várias etapas, conforme descrito no segmento Como converter certificados de cluster de impressão digital em nome comum.

Análises e observações

Esta seção é um apanhado para explicar conceitos e processos que foram apresentados ao longo deste artigo, além de chamar a atenção para outros determinados aspectos importantes.

Sobre o provisionamento de certificado

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

Isso indica para a extensão da VM do Key Vault 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 ao recuperar os 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 Key Vault e, novamente, uma falha na implantação do cluster.

Vinculação de certificado explicada

Talvez você tenha notado o sinalizador linkOnRenewal da extensão da VM do Key Vault e o fato de ele estar definido como false. Esta 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 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 através 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 dá suporte ao redirecionamento ou à vinculação de credenciais na forma de uma extensão de certificado, CERT_RENEWAL_PROP_ID.

Se esta propriedade for estabelecida, seu valor representará a impressão digital do certificado renovação e, assim, o canal S tentará, em vez disso, carregar o certificado vinculado. Na verdade, o canal S percorrerá essa lista vinculada e, felizmente, acíclica até que ela termine com o certificado final, um sem uma marca de renovação. Esse recurso, quando usado criteriosamente, traz uma grande mitigação contra perda de disponibilidade causada por, por exemplo, certificados expirados.

Em outros casos, pode ser a causa de interrupções de difícil diagnóstico e mitigação. O Canal S executará a passagem de certificados em suas propriedades de renovação incondicionalmente, independentemente da entidade, dos emissores ou de quaisquer outros atributos específicos que participem da validação do certificado resultante pelo cliente. É possível que o certificado resultante não tenha uma chave privada associada a ele ou que a chave não tenha passado por ACLed para o consumidor potencial.

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

Suponha que um certificado C seja recuperado pela extensão da VM do Key Vault: CN = “Mallory's malware”, SAN = {“alice.universalexports.com”, “bob.universalexports.com”, “mallory.universalexports.com”}

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

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

• Caso a chave privada de C não tenha passado por ACLd para a conta em que o Service Fabric esteja sendo executado, você verá falhas para adquirir a chave privada (SEC_E_UNKNOWN_CREDENTIALS ou semelhante).
• Caso a chave privada de C esteja 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 falhará 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 da VM do Key Vault, pelo agendamento de renovação no cofre de chaves ou até mesmo por erros transitórios que alterariam a ordem de recuperação.

Para mitigar esses incidentes, recomenda-se o seguinte:

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

• Incluir o nome comum da entidade na lista da SAN (como, literalmente, CN=<subject common name>).

• Se você não tiver certeza sobre como proceder, desabilite a vinculação de renovação dos certificados provisionados com a extensão da VM do Key Vault.

  Observação

  Desabilitar a vinculação é uma propriedade de nível superior da extensão da VM do Key Vault e não pode ser definida para certificados individuais observados.

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

Como ficou evidente dos trechos JSON anterior, um sequenciamento específico das operações e atualizações é necessário para garantir tanto o sucesso da conversão e para manter a disponibilidade do cluster. Especificamente, o recurso do conjunto de dimensionamento de máquinas virtuais declara e usa sua identidade para recuperar segredos em uma única atualização (sob a perspectiva do usuário).

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

A extensão da VM do Key Vault usa a identidade do conjunto de dimensionamento de máquinas virtuais para acessar o cofre de chaves, o que significa que a política de acesso no cofre de chaves precisa já ter sido atualizada antes da implantação do conjunto de dimensionamento de máquinas virtuais.

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 exigida (ManagedIdentityOperator) na assinatura ou no grupo de recursos, além das funções necessárias para gerenciar os outros recursos referenciados no modelo.

Em relação à segurança, lembre-se de que o conjunto de dimensionamento de máquinas virtuais é considerado um limite de segurança em relação à sua identidade do Azure. Isso significa que qualquer aplicação hospedada 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 do Serviço de Metadados de Instância não autenticada. Caso considere que a VM é um ambiente compartilhado ou de vários locatários, esse método de recuperação de certificados de cluster pode não ser indicado. No entanto, trata-se do único mecanismo de provisionamento adequado para a substituição automática do certificado.

Solução de problemas e perguntas frequentes

P: como se registrar de modo programático em um certificado gerenciado por KeyVault?

Descubra o nome do emissor na documentação do KeyVault 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 a lista completa de emissores ativos de uma específica PKI?

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 fixados, o certificado será considerado inválido, seja sua raiz confiável ou não. Portanto, é essencial garantir que a lista de emissores esteja atualizada. A introdução de um novo emissor é um evento raro e deve ser amplamente divulgada antes de ele começar a emitir certificados.

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

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

P: há suporte para várias PKIs?

Sim. Talvez você não declare várias entradas de CN no manifesto do cluster com o mesmo valor, mas poderá listar os emissores de várias PKIs correspondentes ao mesmo CN. Essa não é uma melhor prática, e as práticas de transparência de certificado podem impedir que esses certificados sejam emitidos. No entanto, esse é um mecanismo aceitável como um meio para migrar de uma PKI para outra.

P: e se o certificado de cluster atual não for emitido pela AC ou não tiver a entidade planejada?

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