Partager via

Gérer les certificats dans les clusters Service Fabric

  • Article

Cet article traite des aspects de la gestion des certificats utilisés pour sécuriser la communication dans les clusters Azure Service Fabric. Il complète l’introduction à la sécurité des clusters Service Fabric et l’explication sur l’authentification basée sur un certificat X.509 dans Service Fabric.

Prérequis

Avant de commencer, vous devez vous familiariser avec les concepts fondamentaux en matière de sécurité et avec les contrôles que Service Fabric propose pour configurer la sécurité d’un cluster.

Clause d'exclusion de responsabilité

Cet article associe les aspects théoriques de la gestion des certificats à des exemples pratiques qui couvrent les spécificités des services, des technologies, etc. Étant donné que cet article s’adresse majoritairement au personnel interne de Microsoft, il fait référence à des services, technologies et produits spécifiques à Azure. Si certains détails spécifiques à Microsoft ne s’appliquent pas à vous, n’hésitez pas à demander des éclaircissements ou des conseils dans la section des commentaires à la fin de l’article.

Définition de la gestion des certificats

Comme l’explique l’article complémentaire Authentification basée sur un certificat X.509 dans des clusters Service Fabric, un certificat est un objet de chiffrement qui lie une paire de clés asymétriques à des attributs décrivant l’entité qu’il représente.

Il s’agit cependant d’un objet périssable, dans la mesure où sa durée de vie est limitée et où il présente des vulnérabilités. En effet, une divulgation accidentelle ou une attaque réussie peuvent rendre un certificat inutile du point de vue de la sécurité. Cette caractéristique implique la nécessité de changer les certificats soit systématiquement, soit en réponse à un incident de sécurité.

Autre aspect de la gestion des certificats, qui constitue un sujet bien distinct : la sauvegarde des clés privées ou des secrets des certificats protégeant l’identité des entités impliquées dans l’obtention et l’approvisionnement des certificats.

La gestion des certificats englobe les processus et procédures mis en œuvre pour obtenir des certificats et les délivrer sans encombre et en toute sécurité là où ils sont nécessaires.

Certaines opérations de gestion, comme l’inscription, la définition de stratégies et les contrôles d’autorisation, dépassent le cadre de cet article. D’autres opérations, telles que l’approvisionnement, le renouvellement, la régénération des clés ou la révocation, ne sont liées qu’accessoirement à Service Fabric. Néanmoins, l’article les traite succinctement, car la compréhension de ces opérations peut vous aider à sécuriser correctement votre cluster.

Dans un premier temps, votre objectif sera probablement d’automatiser autant que possible la gestion des certificats afin de garantir une disponibilité ininterrompue du cluster. Étant donné que le processus s’effectue sans intervention de l’utilisateur, vous souhaiterez également offrir des garanties de sécurité. Grâce aux clusters Service Fabric, cet objectif peut être atteint.

Le reste de l’article déconstruit d’abord la gestion des certificats, puis se concentre sur l’activation de la substitution automatique.

Plus précisément, il couvre les sujets suivants :

  • Postulats relatifs au cloisonnement des attributions entre propriétaire et plateforme
  • Long pipeline entre l’émission des certificats et leur utilisation
  • Rotation des certificats : pourquoi, comment et quand
  • Risques potentiels liés à la gestion des certificats

L’article ne traite pas des sujets suivants :

  • Sécurisation et gestion des noms de domaine
  • Inscription à des certificats
  • Configuration des contrôles d’autorisation pour l’émission des certificats

Pour plus d’informations sur ces sujets, consultez l’autorité d’inscription de votre service d’infrastructure à clé publique de prédilection. Si vous opérez au sein de Microsoft, vous pouvez contacter Azure Security Center.

Rôles et entités impliqués dans la gestion des certificats

En vertu de l’approche de la sécurité dans un cluster Service Fabric, le propriétaire déclare et le runtime Service Fabric applique. Cela signifie que pratiquement aucun des certificats, clés ou autres informations d’identification des identités contribuant au fonctionnement d’un cluster ne proviennent du service proprement dit. Tous sont déclarés par le propriétaire du cluster. Le propriétaire du cluster est également responsable de l’approvisionnement des certificats dans le cluster, de leur renouvellement en fonction des besoins, et de la garantie de leur sécurité à tout moment.

Plus précisément, le propriétaire du cluster doit s’assurer que les conditions suivantes sont réunies :

  • Les certificats déclarés dans la section NodeType du manifeste de cluster se trouvent sur chaque nœud de ce type, conformément aux règles de présentation.
  • Les certificats déclarés au point précédent sont installés avec leurs clés privées correspondantes.
  • Les certificats déclarés dans les règles de présentation doivent être conformes aux règles de validation.

Service Fabric assume pour sa part les responsabilités suivantes :

  • Localisation de certificats correspondant aux déclarations figurant dans la définition du cluster
  • Octroi aux entités contrôlées par Service Fabric de l’accès aux clés privées correspondantes en fonction des besoins
  • Validation des certificats dans le strict respect des bonnes pratiques de sécurité établies et de la définition du cluster
  • Lancement d’alertes concernant l’expiration imminente des certificats ou l’échec d’exécution des étapes de base de validation des certificats
  • Validation (dans une certaine mesure) du fait que la configuration sous-jacente des hôtes respecte les aspects liés au certificat de la définition du cluster

Il s’ensuit que la charge de gestion des certificats (en tant qu’opérations actives) incombe uniquement au propriétaire du cluster. Les sections suivantes examinent de plus près chacune des opérations de gestion, ainsi que les mécanismes disponibles et leur impact sur le cluster.

Parcours d’un certificat

Examinons rapidement sur la progression d’un certificat, de son émission à son utilisation, dans le contexte d’un cluster Service Fabric :

  1. Le propriétaire d’un domaine inscrit auprès de l’autorité d’inscription d’une infrastructure à clé publique un domaine ou objet qu’il souhaite associer à l’émission de certificats qui en découlent. Ceux-ci constituent à leur tour des preuves de la propriété du domaine ou de l’objet.

  2. Le propriétaire du domaine désigne également à l’autorité d’inscription les identités des demandeurs autorisés, qui sont habilitées à demander l’inscription de certificats auprès du domaine ou de l’objet spécifiés.

  3. Un demandeur autorisé s’inscrit ensuite dans un certificat via un service de gestion des secrets. Dans Azure, il s’agit du service Azure Key Vault qui stocke les secrets/certificats de façon sécurisée, et permet leur récupération par les entités autorisées. Key Vault renouvelle et recrée également le certificat tel que configuré dans la stratégie de certificat associée. Key Vault utilise Microsoft Entra ID comme fournisseur d’identité.

  4. Un récupérateur autorisé, ou agent d’approvisionnement, récupère le certificat à partir du coffre de clés, avec sa clé privée, et l’installe sur les machines qui hébergent le cluster.

  5. La plateforme Service Fabric (exécuté avec élévation de privilèges sur chaque nœud) accorde l’accès au certificat aux entités Service Fabric autorisées, qui sont désignées par des groupes locaux et réparties entre ServiceFabricAdministrators et ServiceFabricAllowedUsers.

  6. Le runtime Service Fabric accède au certificat et l’utilise pour établir une fédération ou pour s’authentifier auprès de demandes entrantes de clients autorisés.

  7. L’agent d’approvisionnement surveille le certificat du coffre et déclenche le flux d’approvisionnement dès qu’il détecte le renouvellement. Le propriétaire du cluster met alors à jour la définition du cluster, si nécessaire, pour indiquer son intention de reconduire le certificat.

  8. L’agent d’approvisionnement ou le propriétaire du cluster sont également responsables du nettoyage et de la suppression des certificats inutilisés.

Pour les besoins de cet article, les deux premières étapes de la séquence précédente sont en grande partie indépendantes. Leur seul lien est que le nom commun de l’objet du certificat est le nom DNS déclaré dans la définition du cluster.

Les flux d’émission et de provisionnement de certificats sont illustrés dans les diagrammes suivants :

Pour les certificats déclarés par empreinte

Diagramme de provisionnement des certificats déclarés par empreinte.

Pour les certificats déclarés par nom commun d’objet

Diagramme de provisionnement des certificats déclarés par nom commun de sujet.

Inscription de certificat

Le sujet de l’inscription des certificats est traité en détail dans la documentation Key Vault. Un synopsis est inclus ici pour assurer la continuité et vous permettre de vous y référer facilement.

Toujours avec Azure comme contexte, et en utilisant Key Vault comme service de gestion des secrets, un demandeur de certificat autorisé doit au moins disposer d’autorisations de gestion des certificats sur le coffre de clés, accordées par le propriétaire de celui-ci. Le demandeur s’inscrit ensuite à un certificat comme suit :

  • Le demandeur crée dans Key Vault une stratégie de certificat qui spécifie le domaine ou l’objet du certificat, l’émetteur souhaité, le type et la longueur de la clé, l’utilisation prévue de la clé, etc. Pour plus d’informations, consultez Certificats dans Azure Key Vault.

  • Le demandeur crée un certificat dans le même coffre avec la stratégie spécifiée à l’étape précédente, ce qui a pour effet de générer une paire de clés en tant qu’objets de coffre, ainsi qu’une demande de signature de certificat signée avec la clé privée, qui est ensuite transmise à l’émetteur désigné pour signature.

  • Une fois que l’émetteur ou l’autorité de certification a répondu avec le certificat signé, le résultat est fusionné dans le coffre de clés et les données du certificat sont disponibles comme suit :

    • Sous {vaultUri}/certificates/{name} : le certificat comprenant la clé publique et les métadonnées
    • Sous {vaultUri}/keys/{name} : la clé privée du certificat, disponible pour les opérations de chiffrement (envelopper/désenvelopper, signer/vérifier)
    • Sous {vaultUri}/secrets/{name} : le certificat avec sa clé privée, disponible pour le téléchargement en tant que fichier PFX ou PEM non protégé.

Rappelez-vous qu’un certificat figurant dans le coffre de clés contient une liste chronologique d’instances de certificat qui partagent une stratégie. Les versions des certificats sont créées en fonction des attributs de durée de vie et de renouvellement de cette stratégie. Nous vous recommandons vivement de veiller à ce que les certificats de coffre ne partagent pas des objets, domaines ou noms DNS. Dans un cluster, il peut être perturbant d’approvisionner des instances de certificat à partir de différents certificats de coffre, avec des objets identiques mais d’autres attributs sensiblement différents, tels que l’émetteur, les utilisations de clés, et ainsi de suite. À ce stade, le coffre de clés contient un certificat prêt à être utilisé. Examinons maintenant le reste du processus.

Approvisionnement du certificat

Nous avons évoqué un agent d’approvisionnement, qui est l’entité qui récupère le certificat dans le coffre de clés, avec sa clé privée, et l’installe sur chacun des hôtes du cluster (n’oubliez pas que Service Fabric ne fournit pas de certificats).

Dans le contexte de cet article, le cluster sera hébergé sur une collection de machines virtuelles Azure ou dans des groupes de machines virtuelles identiques. Dans Azure, vous pouvez approvisionner un certificat d’un coffre vers une machine virtuelle ou un groupe de machines virtuelles identiques en utilisant les mécanismes suivants. Cela dit, le propriétaire du coffre de clés doit avoir préalablement accordé à l’agent d’approvisionnement des autorisations d’obtention de secret sur le coffre de clés.

  • Mécanisme ad hoc : un opérateur récupère le certificat dans le coffre de clés (comme PFX/PKCS n°12 ou PEM), et l’installe sur chaque nœud.

    Le mécanisme ad-hoc n’étant pas recommandé, pour diverses raisons allant de la sécurité à la disponibilité, nous n’en dirons pas davantage ici. Pour plus d’informations, consultez FAQ sur les groupes de machines virtuelles identiques Azure.

  • En tant que secret du groupe de machines virtuelles identiques lors du déploiement : en utilisant son identité interne pour le compte de l’opérateur, le service de calcul récupère le certificat à partir d’un coffre activé pour le déploiement de modèle, et l’installe sur chaque nœud du groupe de machines virtuelles identiques, comme décrit dans FAQ sur les groupes de machines virtuelles identiques Azure.

    Notes

    Cette approche autorise uniquement l’approvisionnement des secrets avec version.

  • En utilisant l’extension de machine virtuelle de Key Vault. Cela vous permet d’approvisionner les certificats à l’aide de déclarations sans version, avec une actualisation périodique des certificats observés. Dans ce cas, la machine virtuelle ou le groupe de machines virtuelles identiques doit avoir une identité managée, c’est-à-dire une identité autorisée à accéder aux coffres de clés contenant les certificats observés.

Si l’approvisionnement basé sur groupe de machines virtuelles identiques/calcul présente des avantages en termes de sécurité et de disponibilité, il s’accompagne également de restrictions. Sa conception vous impose de déclarer les certificats en tant que secrets versionnés. Compte tenu de cette obligation, le provisionnement VMSS/basé sur le calcul convient uniquement pour les clusters sécurisés avec des certificats déclarés par empreinte.

En revanche, le provisionnement basé sur l’extension de machine virtuelle Key Vault installe systématiquement la dernière version de chaque certificat observé. De ce fait, il convient uniquement pour les clusters sécurisés avec des certificats déclarés par nom commun de sujet. Évitez absolument d’utiliser un mécanisme d’approvisionnement par actualisation automatique (comme l’extension de machine virtuelle de Key Vault) pour les certificats déclarés par une instance (c’est-à-dire, par empreinte). Cela vous exposerait à un risque de perte de disponibilité considérable.

D’autres mécanismes d’approvisionnement existent, mais les approches mentionnées correspondent aux options actuellement acceptées pour les clusters Azure Service Fabric.

Utilisation et surveillance des certificats

Comme mentionné précédemment, le runtime Service Fabric est responsable de la localisation et de l’utilisation des certificats déclarés dans la définition du cluster. L’article Authentification basée sur un certificat X.509 dans des clusters Service Fabric explique en détail comment Service Fabric implémente les règles de présentation et de validation. Nous n’y reviendrons pas ici. Cet article traite de l’octroi des accès et des autorisations, ainsi que de la surveillance.

Rappelez-vous que dans Service Fabric les certificats sont utilisés à de multiples fins, de l’authentification mutuelle dans la couche de fédération à l’authentification TLS (Transport Layer Security) pour les points de terminaison de gestion. À cet effet, différents composants ou services système doivent avoir accès à la clé privée des certificats. Le runtime Service Fabric analyse régulièrement le magasin de certificats, à la recherche de correspondances pour chacune des règles de présentation connues.

Pour chaque certificat épinglé, la clé privée correspondante est localisée et sa liste de contrôle d’accès discrétionnaire est mise à jour pour inclure les autorisations (généralement de lecture et d’exécution) qui sont accordées à l’identité qui les requiert.

Ce processus est familièrement appelé mise en liste ACL. Le processus s’exécute à une cadence d’une fois par minute et couvre également les certificats d’application, tels que ceux utilisés pour chiffrer des paramètres ou en tant que certificats de point de terminaison. Dans la mesure où la liste ACL suit les règles de présentation, il est important de garder à l’esprit que les certificats déclarés par empreinte et actualisés automatiquement sans mise à jour de la configuration de cluster qui en résulte seront inaccessibles.

Rotation des certificats

Notes

La norme RFC 3647 de l’IETF (Internet Engineering Task Force) définit officiellement le renouvellement comme l’émission d’un certificat doté des mêmes attributs que le certificat remplacé. L’émetteur, la clé publique de l’objet et les informations sont conservées. Le terme régénération des clés désigne l’émission d’un certificat avec une nouvelle paire de clés, sans restriction quant au changement d’émetteur. Étant donné que cette distinction peut avoir de l’importance (par exemple, dans le cas de certificats déclarés par nom commun de l’objet avec épinglage de l’émetteur), cet article emploie le terme neutre de rotation pour couvrir les deux scénarios. Gardez à l’esprit qu’employé de manière informelle, le terme renouvellement désigne en réalité une régénération des clés.

Comme mentionné précédemment, Key Vault prend en charge la rotation automatique des certificats. Autrement dit, la stratégie de certificat associée définit le moment (point dans le temps exprimé en jours avant l’expiration du certificat ou en pourcentage de la durée de vie totale de celui-ci) auquel a lieu la rotation du certificat dans le coffre de clés. L’agent d’approvisionnement doit être appelé après ce point dans le temps et avant l’expiration du certificat désormais précédent, afin de distribuer ce nouveau certificat à tous les nœuds du cluster.

Service Fabric accompagne ce processus en déclenchant un avertissement d’intégrité lorsque la date d’expiration d’un certificat en cours d’utilisation dans le cluster est antérieure à la fin d’un intervalle prédéterminé. Un agent d’approvisionnement automatique (en l’occurrence l’extension de machine virtuelle de KeyVault) configuré pour observer le certificat du coffre de clés, interroge périodiquement celui-ci, détecte la rotation, puis récupère et installe le nouveau certificat. L’approvisionnement effectué via la fonctionnalité secrets de la machine virtuelle ou du groupe de machines virtuelles identiques nécessite qu’un opérateur autorisé mette à jour la machine ou le groupe en question avec l’URI de Key Vault (version gérée) correspondant au nouveau certificat.

Le certificat qui a fait l’objet de la rotation est désormais approvisionné sur tous les nœuds. Maintenant, en partant du principe que la rotation appliquée au certificat de cluster a été déclarée par nom commun d’objet, examinons ce qui se passe ensuite :

  • Pour les nouvelles connexions qui s’y trouvent, ainsi que dans le cluster, le runtime Service Fabric recherche et sélectionne le certificat correspondant émis le plus récemment (valeur de la propriété NotBefore la plus élevée). Il s’agit d’une modification par rapport aux versions précédentes du runtime Service Fabric.

  • Les connexions existantes sont maintenues en vie, ou autorisées à expirer naturellement ou à prendre fin d’une autre manière, et un gestionnaire interne est informé de l’existence d’une nouvelle correspondance.

Notes

Actuellement, à compter de la version 7.2 CU4+, Service Fabric sélectionne le certificat affichant la valeur la plus élevée (dont l’émission est la plus récente) pour la propriété NotBefore. Avant la version 7.2 CU4, Service Fabric choisissait le certificat valide affichant la valeur NotAfter la plus élevée (date d’expiration la plus éloignée).

Cela se traduit par les observations importantes suivantes :

  • La disponibilité du cluster ou des applications hébergées prend le pas sur la directive de rotation du certificat. Le cluster finit par converger sur le nouveau certificat, mais sans garantie de timing. Résultat :

    • Il peut ne pas être immédiatement évident pour l’observateur que le certificat après rotation a complètement remplacé son prédécesseur. La seule façon de forcer le remplacement immédiat du certificat en cours d’utilisation est de redémarrer les machines hôtes. Il ne suffit pas de redémarrer les nœuds Service Fabric, car les composants en mode noyau qui forment des connexions de bail dans un cluster ne seront pas affectés. De plus, le redémarrage de la machine virtuelle ou du groupe de machines virtuelles identiques peut entraîner une perte temporaire de disponibilité. Pour les certificats d’application, il suffit juste de redémarrer les instances d’application respectives.

    • L’introduction d’un certificat avec clé régénérée qui ne respecte pas les règles de validation peut effectivement anéantir le cluster. L’exemple le plus courant est le cas d’un émetteur inattendu où les certificats de cluster sont déclarés par nom commun de l’objet avec épinglage de l’émetteur, mais le certificat après rotation a été émis par un émetteur nouveau ou non déclaré.

Nettoyage de certificat

À l’heure actuelle, il n’existe aucune disposition dans Azure pour la suppression explicite des certificats. Il est souvent difficile de déterminer si un certificat spécifique est utilisé à un moment donné. Cela est plus difficile pour les certificats d’application que pour les certificats de cluster. Comme Service Fabric n’est pas l’agent d’approvisionnement, il ne peut pas supprimer un certificat qui a été déclaré par l’utilisateur. Pour les mécanismes d’approvisionnement standard :

  • Les certificats déclarés en tant que secrets de machine virtuelle ou de groupe de machines virtuelles identiques sont approvisionnés tant qu’ils sont référencés dans la définition correspondante et qu’ils peuvent être récupérés à partir du coffre de clés. La suppression d’un secret ou d’un certificat de coffre de clés entraînera l’échec des déploiements de machines virtuelles ou de groupes de machines virtuelles identiques suivants. De même, la désactivation d’une version secrète dans le coffre de clés entraînera également l’échec des déploiements de machines virtuelles ou de groupes de machines virtuelles identiques qui font référence à la version du secret.

  • Les versions antérieures des certificats approvisionnés via l’extension de machine virtuelle de Key Vault peuvent ou non être présentes sur un nœud de machines virtuelles/groupes de machines virtuelles identiques. L’agent récupère et installe uniquement la version actuelle, et ne supprime aucun certificat. Le réimageage d’un nœud, qui se produit généralement tous les mois, entraîne la réinitialisation du magasin de certificats avec le contenu de l’image du système d’exploitation, et la suppression implicite des versions précédentes. Sachez cependant que tout scale-up d’un groupe de machines virtuelles identiques a pour effet de n’installer que la version actuelle des certificats observés. Il ne permet nullement de supposer que les nœuds sont homogènes en ce qui concerne les certificats installés.

Simplification de la gestion : un exemple de substitution automatique

Jusqu’à présent, cet article a décrit les mécanismes et restrictions, présenté des règles et définitions complexes, et prédit des pannes calamiteuses. Il est maintenant temps de configurer la gestion automatique des certificats pour éliminer tous ces soucis. Faisons-le dans le contexte d’un cluster Azure Service Fabric exécuté sur un groupe de machines virtuelles identiques v2 de type PaaS, en utilisant Key Vault pour la gestion des secrets et en tirant parti des identités managées comme suit :

  • La validation des certificats passe de l’épinglage d’empreinte à l’épinglage d’objet + émetteur. Tout certificat comportant un objet donné provenant d’un émetteur spécifique est approuvé de la même manière.
  • Les certificats sont inscrits dans un magasin de confiance (Key Vault) et obtenus à partir de celui-ci, ainsi qu’actualisés par un agent (en l’occurrence, l’extension de machine virtuelle de KeyVault).
  • L’approvisionnement des certificats passe d’un système basé sur l’heure de déploiement et la version (comme pour Azure Compute Resource Provider) à un post-déploiement en utilisant les URI de KeyVault sans gestion des versions.
  • L’accès au coffre de clés est accordé par le biais d’identités managées affectées par l’utilisateur, qui sont créées et attribuées au groupe de machines virtuelles identiques lors du déploiement.
  • Après le déploiement, l’agent (l’extension de machine virtuelle de Key Vault) interroge et actualise les certificats observés sur chacun des nœuds du groupe de machines virtuelles identiques. La rotation des certificats est donc entièrement automatisée, car Service Fabric récupère automatiquement le dernier certificat valide.

La séquence, qui peut être entièrement consignée dans un script et automatisée, permet un déploiement initial sans intervention de l’utilisateur d’un cluster configuré pour la substitution automatique des certificats. Les sections suivantes présentent les étapes détaillées, avec un mélange de cmdlets PowerShell et de fragments de modèles JSON. Il est possible d’obtenir la même fonctionnalité avec tous les moyens pris en charge d’interaction avec Azure.

Notes

Cet exemple part du principe qu’il existe déjà un certificat dans votre coffre de clés. L’inscription et le renouvellement d’un certificat géré par Key Vault nécessitent l’exécution des étapes manuelles préalables décrites plus haut dans cet article. Pour les environnements de production, utilisez des certificats gérés par Key Vault. Nous avons inclus un exemple de script spécifique à une infrastructure à clé publique interne à Microsoft.

Notes

La substitution automatique de certificat n’a de sens que pour les certificats émis par une autorité de certification. L’utilisation de certificats auto-signés, y compris de ceux générés lors du déploiement d’un cluster Service Fabric sur le portail Azure, est dénuée de sens, mais toujours possible pour des déploiements locaux ou hébergés par un développeur si vous déclarez que l’empreinte de l’émetteur est la même que celle du certificat feuille.

Point de départ

Par souci de concision, partons du principe que l’état de départ est le suivant :

  • Le cluster Service Fabric existe et est sécurisé avec un certificat émis par une autorité de certification et déclaré par empreinte.
  • Le certificat est stocké dans un coffre de clés et approvisionné en tant que secret de groupe de machines virtuelles identiques.
  • Le même certificat sera utilisé pour convertir le cluster en déclarations de certificat basées sur un nom commun. Il pourra ainsi être validé par objet et émetteur. Si ce n’est pas le cas, procurez-vous le certificat émis par l’autorité de certification et destiné à cet usage, et ajoutez-le à la définition du cluster par empreinte. Ce processus est expliqué dans Ajouter ou supprimer des certificats pour un cluster Service Fabric dans Azure.

Voici un extrait JSON d’un modèle qui correspond à un tel état. L’extrait omet de nombreux paramètres requis et illustre uniquement les aspects liés au certificat.

  "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')]"
        },
    }
  ]

Le code précédent indique essentiellement que le certificat avec empreinte json [parameters('primaryClusterCertificateTP')] et qui se trouve à l’URI de KeyVault json [parameters('clusterCertificateUrlValue')] est déclaré par empreinte comme l’unique certificat du cluster.

Configurons maintenant les ressources supplémentaires nécessaires pour garantir la substitution automatique du certificat.

Configurer les ressources requises

Comme mentionné précédemment, un certificat provisionné en tant que secret de groupe de machines virtuelles identiques est récupéré dans le coffre de clés par le service Microsoft Compute Resource Provider. en utilisant son identité interne pour le compte de l’opérateur de déploiement. Ce processus changera pour la substitution automatique. Vous passerez à l’utilisation d’une identité managée attribuée au groupe de machines virtuelles identiques et ayant reçu des autorisations GET sur les secrets de ce coffre.

Vous devez déployer les extraits suivants en même temps. Ceux-ci sont répertoriés individuellement uniquement pour l’analyse et l’explication de type « play-by-play ».

Commencez par définir une identité attribuée par l’utilisateur (les valeurs par défaut sont incluses à titre d’exemples). Pour plus d’informations, consultez la documentation officielle.

{
  "$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]"
    },
  ]}

Ensuite, accordez à cette identité l’accès aux secrets du coffre de clés. Pour obtenir les informations les plus récentes, consultez la documentation officielle.

  "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"
              ]}}]}}]

À l’étape suivante, vous allez devoir :

  • attribuer l’identité affectée par l’utilisateur au groupe de machines virtuelles identiques ;
  • déclarer la dépendance du groupe de machines virtuelles identiques à la création de l’identité managée et au résultat de l’octroi de l’accès au coffre de clés ;
  • déclarer l’extension de machine virtuelle de Key Vault et exiger qu’elle récupère les certificats observés au démarrage. Pour plus d’informations, consultez la documentation officielle Extension de machine virtuelle Key Vault pour Windows ;
  • mettre à jour la définition de l’extension de machine virtuelle de Service Fabric pour qu’elle dépende de l’extension de machine virtuelle de Key Vault et convertisse la déclaration du certificat de cluster d’empreinte en nom commun.

Notes

Ces modifications sont effectuées en une seule étape, car elles relèvent de l’étendue de la même ressource.

  "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')]",
  } 
  }
  ]

Bien que cela ne soit pas explicitement répertorié dans le code précédent, notez que l’URL du certificat du coffre de clés a été supprimée de la section OsProfile du groupe de machines virtuelles identiques.

La dernière étape consiste à mettre à jour la définition du cluster afin de convertir la déclaration du certificat d’empreinte en nom commun. Nous épinglons également les empreintes de l’émetteur :

  "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')]"
        },
  ]

À ce stade, vous pouvez exécuter les mises à jour mentionnées précédemment en un seul déploiement. De son côté, Service Fabric Resource Provider fractionne la mise à niveau du cluster en plusieurs étapes, comme décrit dans le segment consacré à la conversion des certificats de cluster d’empreinte en nom commun.

Analyse et observations

Cette section explique les concepts et processus présentés tout au long de cet article, et attire l’attention sur certains autres aspects importants.

À propos de l’approvisionnement des certificats

L’extension de machine virtuelle de Key Vault, en tant qu’agent d’approvisionnement, s’exécute en continu à une fréquence prédéterminée. Si elle ne parvient pas à récupérer un certificat observé, elle passe au suivant dans la file, puis se met en veille prolongée jusqu’au cycle suivant. L’extension de machine virtuelle de Service Fabric, en tant qu’agent de démarrage du cluster, exige les certificats déclarés avant que le cluster puisse se former. Cela signifie que l’extension de machine virtuelle de Service Fabric ne peut s’exécuter qu’après la récupération effective des certificats de cluster, indiquée ici par la clause json "provisionAfterExtensions" : [ "KVVMExtension" ]" et par le paramètre json "requireInitialSync": true de l’extension de machine virtuelle de Key Vault.

Cela indique à l’extension de machine virtuelle de Key Vault que, lors de la première exécution (après déploiement ou redémarrage), elle doit parcourir ses certificats observés jusqu’à ce que tous soient correctement téléchargés. La définition de ce paramètre sur false, associée à un échec de récupération des certificats de cluster, entraînerait un échec de déploiement du cluster. Inversement, exiger une synchronisation initiale avec une liste incorrecte ou non valide de certificats observés entraînerait un échec de l’extension de machine virtuelle de Key Vault, et donc, une fois de plus, un échec de déploiement du cluster.

Explication du lien de certificat

Vous avez peut-être remarqué l’indicateur linkOnRenewal de l’extension de machine virtuelle de Key Vault, et le fait qu’il est défini sur false. Ce paramètre agit sur le comportement contrôlé par cet indicateur et ses conséquences sur le fonctionnement d’un cluster. Ce comportement est spécifique de Windows.

En fonction de sa définition :

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

Les certificats utilisés pour établir une connexion TLS sont généralement acquis en tant que descripteur via le fournisseur SSP (Security Support Provider) du canal S. Autrement dit, le client n’accède pas directement à la clé privée du certificat proprement dit. Le canal S prend en charge la redirection (liaison) des informations d’identification sous la forme d’une extension de certificat, CERT_RENEWAL_PROP_ID.

Si cette propriété est définie, sa valeur représente l’empreinte du certificat de renouvellement, de sorte que le canal S tente plutôt de charger le certificat lié. En fait, le canal S parcourt cette liste liée et, espérons-le, acyclique jusqu’à ce qu’il se retrouve avec le certificat final, sans marque de renouvellement. Utilisée judicieusement, cette fonctionnalité limite efficacement la perte de disponibilité causée, par exemple, par l’expiration des certificats.

Dans d’autres cas, elle peut occasionner des pannes difficiles à diagnostiquer et à atténuer. Le canal S exécute le balayage des certificats sur leurs propriétés de renouvellement de façon inconditionnelle, sans tenir compte de l’objet, des émetteurs ou de tout autre attribut spécifique participant à la validation du certificat obtenu par le client. Il est possible que le certificat obtenu n’ait pas de clé privée associée, ou que la clé n’ait pas été mise en liste ACL pour son utilisateur potentiel.

Si la liaison est activée, l’extension de machine virtuelle de Key Vault, lorsqu’elle récupère un certificat observé à partir du coffre de clés, tente de trouver des certificats existants correspondants pour les lier via la propriété d’extension de renouvellement. La correspondance repose exclusivement sur l’autre nom de l’objet (SAN) et fonctionne, en présence de deux certificats existants, comme illustré dans les exemples suivants : A : Certificate name (CN) = « Alice’s accessories », SAN = {« alice.universalexports.com »}, renewal = « » B : CN = « Bob’s bits », SAN = {« bob.universalexports.com », « bob.universalexports.net »}, renewal = « »

Supposons qu’un certificat C soit récupéré par l’extension de machine virtuelle de Key Vault : CN = « Mallory’s malware », SAN = {« alice.universalexports.com », « bob.universalexports.com », « mallory.universalexports.com »}

La liste SAN du certificat A est entièrement incluse dans celle de C, de sorte que A.renewal = C.thumbprint. La liste SAN du certificat B présente une intersection avec celle de C, mais n’y est pas entièrement incluse, de sorte que B.renewal reste vide.

Toute tentative d’invoquer AcquireCredentialsHandle (canal S) dans cet état sur le certificat A aboutit en réalité à l’envoi de C à la partie distante. Dans le cas de Service Fabric, le Sous-système de transport d’un cluster utilise le canal S pour l’authentification mutuelle. Par conséquent, le comportement décrit précédemment affecte directement la communication fondamentale du cluster. Toujours sur la base de l’exemple précédent, en supposant que A est le certificat de cluster, ce qui se passe ensuite dépend des circonstances :

  • Si la clé privée de C ne figure pas dans la liste ACL pour le compte sous l’identité duquel Service Fabric s’exécute, des échecs se produisent en lien avec l’acquisition de la clé privée (SEC_E_UNKNOWN_CREDENTIALS ou similaires).
  • Si la clé privée de C est accessible, des échecs d’autorisation sont renvoyés par les autres nœuds (CertificateNotMatched, non autorisé, etc.).

Dans les deux cas, le transport échoue et le cluster peut cesser de fonctionner. Les symptômes varient. Pour aggraver les choses, la liaison dépend de l’ordre de renouvellement, qui est dicté par l’ordre de la liste des certificats observés de l’extension de machine virtuelle de Key Vault, par le calendrier de renouvellement dans le coffre de clés, voire par des erreurs transitoires qui modifieraient l’ordre de récupération.

Pour minimiser de tels incidents, suivez les recommandons suivantes :

  • Ne mélangez pas les SAN de différents certificats de coffre. Chaque certificat de coffre doit avoir un objectif propre, et son objet ainsi que son SAN doivent refléter cela de façon spécifique.

  • Incluez le nom commun de l’objet dans la liste SAN (littéralement, sous la forme CN=<subject common name>).

  • Si vous ne savez pas comment procéder, désactivez la liaison lors du renouvellement des certificats approvisionnés avec l’extension de machine virtuelle de Key Vault.

    Notes

    La désactivation de la liaison est une propriété de niveau supérieur de l’extension de machine virtuelle de Key Vault qui ne peut pas être définie pour les certificats observés individuellement.

Pourquoi utiliser une identité managée affectée par l’utilisateur ? Quelles sont les implications de son utilisation ?

Comme le montrent les extraits de code JSON précédents, un séquencement spécifique des opérations et des mises à jour est nécessaire pour garantir le succès de la conversion et maintenir la disponibilité du cluster. Plus précisément, la ressource de groupe de machines virtuelles identiques déclare et utilise son identité pour récupérer des secrets en une seule mise à jour (du point de vue de l’utilisateur).

L’extension de machine virtuelle de Service Fabric, qui démarre le cluster, dépend de l’exécution de l’extension de machine virtuelle de Key Vault, qui à son tour dépend du succès de la récupération des certificats observés.

L’extension de machine virtuelle de Key Vault utilise l’identité du groupe de machines virtuelles identiques pour accéder au coffre de clés, ce qui signifie que la stratégie d’accès sur le coffre de clés doit avoir déjà été mise à jour avant le déploiement du groupe de machines virtuelles identiques.

Pour disposer de la création d’une identité managée, ou pour l’affecter à une autre ressource, l’opérateur de déploiement doit avoir le rôle requis (ManagedIdentityOperator) dans l’abonnement ou le groupe de ressources, en plus des rôles requis pour gérer les autres ressources référencées dans le modèle.

Du point de vue de la sécurité, rappelez-vous que le groupe de machines virtuelles identiques est considéré comme une limite de sécurité en lien avec son identité Azure. Cela signifie que toute application hébergée sur la machine virtuelle pourrait, en principe, obtenir un jeton d’accès représentant la machine virtuelle. Les jetons d’accès d’identité managée sont obtenus à partir du point de terminaison Instance Metadata Service non authentifié. Si vous considérez la machine virtuelle comme un environnement partagé ou mutualisé, cette méthode de récupération des certificats de cluster n’est peut-être pas indiquée. Il s’agit, cependant, du seul mécanisme d’approvisionnement adéquat pour le renouvellement automatique de certificat.

Résolution des problèmes et foire aux questions

Q : Comment s’inscrire par programme à un certificat géré par Key Vault ?

Découvrez le nom de l’émetteur dans la documentation Key Vault, puis remplacez-le dans le script suivant :

  $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

Q : Que se passe-t-il quand un certificat est émis par un émetteur non déclaré ou non spécifié ? Où puis-je obtenir la liste exhaustive des émetteurs actifs d’une infrastructure à clé publique spécifique ?

Si la déclaration de certificat spécifie les empreintes de l’émetteur, et si l’émetteur direct du certificat n’est pas inclus dans la liste des émetteurs épinglés, le certificat est considéré comme non valide, que sa racine soit approuvée ou non par le client. Il est donc indispensable de s’assurer que la liste des émetteurs est à jour. L’introduction d’un nouvel émetteur est un événement rare, qui doit faire l’objet d’une large publicité avant qu’il ne commence à émettre des certificats.

En général, une infrastructure à clé publique publie et conserve une déclaration de pratique de certification, conformément à la norme RFC 7382 de l’IETF. Entre autres informations, la déclaration inclut tous les émetteurs actifs. La récupération de cette liste par programme peut différer d’une infrastructure à clé publique à l’autre.

Pour les infrastructures à clé publique internes à Microsoft, veillez à consulter la documentation interne sur les points de terminaison et les kits de développement logiciel (SDK) utilisés pour récupérer les émetteurs autorisés. Il incombe au propriétaire du cluster de revoir régulièrement cette liste pour s’assurer que la définition de son cluster inclut tous les émetteurs attendus.

Q : Plusieurs infrastructures à clé publique sont-elles prises en charge ?

Oui. Vous ne pouvez pas déclarer dans le manifeste de cluster plusieurs entrées de nom commun qui ont la même valeur, mais vous pouvez répertorier les émetteurs de plusieurs infrastructures à clé publique correspondant au même nom commun. Cette pratique n’est pas recommandée et les pratiques de transparence des certificats peuvent empêcher l’émission de tels certificats. Il s’agit cependant d’un mécanisme acceptable comme moyen de migrer d’une infrastructure à clé publique vers une autre.

Q : Que se passe-t-il si le certificat de cluster actuel n’est pas émis par une autorité de certification ou ne comporte pas l’objet souhaité ?

Obtenez un certificat avec l’objet souhaité et ajoutez-le par empreinte à la définition du cluster en tant que certificat secondaire. Une fois la mise à niveau accomplie, lancez une autre mise à niveau de la configuration du cluster pour convertir la déclaration de certificat en nom commun.