Partilhar via

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.

Declaração de exoneraçã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 se aprende no artigo complementar Autenticação baseada em certificado X.509 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 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 de certificado, substituição de chave ou revogação, estão relacionadas apenas de forma incidental 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, foca-se em ativar o autorollover.

Mais especificamente, abrange os seguintes tópicos:

  • Pressupostos sobre a separação de atribuições entre proprietário e plataforma
  • O longo processo desde a emissão do certificado até ao 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 suas 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 Key Vault também renova e altera a chave do certificado conforme configurado pela 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 permitidas do Service Fabric, que são designadas por grupos locais e divididas entre os "ServiceFabricAdministrators" e os "ServiceFabricAllowedUsers".

  6. O runtime do Service Fabric acede 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 alterar 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

Diagrama de certificados de provisionamento declarados por impressão digital.

Para certificados declarados por nome comum de entidade

Diagrama de certificados de provisionamento que são declarados pelo nome comum da 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 gera, por sua vez, um par de chaves como objetos do Vault e uma solicitação de assinatura de certificado assinada com a chave privada, que é então encaminhada ao emissor designado para ser assinada.

  • Depois que o emissor, ou 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. Recomendamos vivamente que os certificados de cofre não partilhem assuntos, domínios ou nomes DNS, porque pode provocar interrupções num cluster ao provisionar instâncias de certificado a partir de diferentes certificados de cofre, com assuntos idênticos mas outros atributos substancialmente diferentes, como o emissor, o uso de chave, e assim por diante. Neste ponto, existe um certificado no cofre de chaves, pronto para utilização. 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 tenha recebido anteriormente permissões de obtenção de segredos 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áquinas virtuais do Azure.

  • Durante a implantação, como um segredo do conjunto de dimensionamento de máquina virtual: usando a 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 instala-o em cada nó do conjunto de dimensionamento de máquina virtual, conforme descrito em Perguntas frequentes sobre conjuntos de dimensionamento de máquinas virtuais do Azure.

    Observação

    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 runtime do Service Fabric analisa 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

Observação

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 quanto à possibilidade de alteração do emissor. Como a distinção pode ser importante (considere o caso de certificados que são declarados pelo nome comum do sujeito com fixação do emissor), este artigo usa o termo neutro rotação para cobrir ambos os cenários. Tenha em mente que, quando a renovação é usada informalmente, refere-se ao termo reautenticaçã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 momento, seja em dias antes da expiração ou como uma percentagem do tempo de vida total, em que o certificado é renovado no cofre de chaves. O agente de provisionamento deve ser invocado após este momento, e antes da expiração do anterior certificado, para distribuir este novo certificado por todos os nós do cluster.

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

O certificado renovado 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 para o cluster, a runtime do Service Fabric localiza e seleciona o certificado correspondente 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.

Observação

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

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.

    • Introduzir um certificado rechaveado que não cumpre as regras de validação pode efetivamente comprometer 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 fará com que as implantações subsequentes de VM/VMSS falhem. 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 via a extensão de VM do Key Vault 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 a gestão: um exemplo de renovação automática

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 Cofre de Chaves 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 da Chave) e atualizados por um agente (aqui, a extensão VM do Cofre da Chave).
  • O provisionamento de certificados é alterado de baseado em tempo de implantação e 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.

Observação

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.

Observação

A substituição automática de certificados só faz sentido para certificados emitidos por uma Autoridade Certificadora (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 uma maior brevidade, 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 num cofre de chaves criptográficas e provisionado como um segredo de conjunto de dimensionamento de máquinas virtuais.
  • O mesmo certificado será utilizado para converter o cluster em declarações de certificado baseadas no nome comum, permitindo assim a sua validação pelo sujeito e pela autoridade emissora. Se isto não for o caso, obtenha o certificado emitido pela autoridade de certificação destinado a essa finalidade e adicione-o à configuração do 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 json [parameters('primaryClusterCertificateTP')] e encontrado no URI do Cofre de Chaves json [parameters('clusterCertificateUrlValue')] é declarado como o único certificado do cluster, por impressão digital.

Em seguida, vamos configurar os recursos adicionais necessários para garantir a renovaçã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ê passará a usar uma identidade gerida atribuída ao conjunto de escalonamento de máquinas virtuais 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 uma análise e explicação detalhada, passo a passo.

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 escalas de máquinas virtuais.
  • 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.

Observação

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 do cluster para mudar a declaração do 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 continuará para o próximo na fila e, em seguida, hibernará 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 json "provisionAfterExtensions" : [ "KVVMExtension" ]" cláusula e pela configuração da extensão de VM do Cofre da json "requireInitialSync": true Chave.

Isso indica à extensão Key Vault VM 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 na 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 de VM do Cofre de Chaves e, novamente, em 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, a S-channel 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 realiza a verificação dos certificados com base nas suas propriedades de renovação incondicionalmente, independentemente do sujeito, emissores ou quaisquer outros atributos específicos que possam participar na validação do certificado resultante pelo cliente. É possível que o certificado resultante não tenha uma chave privada associada ou que a chave não tenha sido configurada com permissões ACL para o seu utilizador alvo.

Se a vinculação estiver habilitada, a extensão de 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 quando há dois certificados existentes, como mostrado nos exemplos seguintes: 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 estiver incluída na lista de controle de acesso (ACL) da conta sob a qual o Service Fabric está a ser executado, ocorrerão falhas ao tentar adquirir a chave privada (SEC_E_UNKNOWN_CREDENTIALS ou similar).
  • Se a chave privada de C estiver acessível, verá erros de autorização retornados 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 da VM do Cofre da Chave, do cronograma de renovação no cofre de chaves ou até mesmo de 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.

    Observação

    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 dimensionamento de máquinas virtuais declara e usa a sua identidade para recuperar segredos numa única atualização (do ponto de vista do utilizador).

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 dispor sobre a criação de uma identidade gerida, ou atribuí-la a outro recurso, o operador de implementação deve ter a função necessária (ManagedIdentityOperator) na subscrição ou no grupo de recursos, além das funções necessárias para gerir os outros recursos referenciados no modelo.

Do ponto de vista da segurança, lembre-se de que o conjunto de dimensionamento de máquinas virtuais é considerado uma fronteira de segurança em relação à identidade que possui no 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 inscrever-me programaticamente num certificado gerido pelo Key Vault?

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.

  • Last updated on