Partager via

Prise en charge de KeyVaultReference pour les applications Service Fabric déployées dans Azure

  • Article

Lors de la création d’applications cloud, il est souvent difficile de déterminer comment distribuer et gérer les secrets de manière sécurisée dans vos applications. Le support de Service Fabric KeyVaultReference facilite les choses. Une fois configuré, vous pouvez référencer l’URL du secret stocké dans Key Vault dans votre définition d’application et Service Fabric gère l’extraction de ce secret et l’activation de votre application avec celle-ci. Lorsque vous utilisez la version « managée par SF » de la fonctionnalité, Service Fabric pouvez également surveiller votre Key Vault et déclencher automatiquement des mises à niveau de paramètres d’application propagées lorsque vos secrets pivotent dans le coffre.

Options de remise de secrets aux applications dans Service Fabric

Auparavant, le moyen de fournir des secrets à une application Service Fabric était de déclarer des paramètres chiffrés. Cela implique le chiffrement des secrets par rapport à un certificat de chiffrement et le passage de ces secrets chiffrés à votre application. Cette méthode présente quelques inconvénients : nécessité de gérer le certificat de chiffrement, exposition des secrets dans le pipeline de déploiement et manque de visibilité sur les métadonnées des secrets attachés à une application déployée. De même, la rotation des secrets nécessite un déploiement d’application. Sauf si vous exécutez un cluster autonome, il est déconseillé d’utiliser des paramètres chiffrés.

Une autre option consiste à l’utilisation des références du magasin des secrets. Cette expérience permet la gestion centralisée de vos secrets d’application, une meilleure visibilité des métadonnées des secrets déployés et permet une gestion centralisée du certificat de chiffrement. Certaines personnes peuvent préférer ce style de gestion des secrets lors de l’exécution de clusters Service Fabric autonomes.

Aujourd’hui, la recommandation consiste à réduire l’utilisation des secrets dans la mesure du possible en utilisant des identités managées pour applications Service Fabric. Les identités managées peuvent être utilisées pour s’authentifier directement auprès de stockage Azure, d’Azure SQL et bien plus encore. Cela signifie qu’il n’est pas nécessaire de gérer des informations d’identification distinctes lors de l’accès aux services Azure qui prennent en charge l’authentification Microsoft Entra.

Quand il n’est pas possible d’utiliser Managed Identity en tant que client, nous vous recommandons d’utiliser KeyVaultReferences. Vous devez utiliser KeyVaultReferences plutôt que d’utiliser Managed Identity pour accéder directement à Key Vault. KeyVaultReferences permet d’augmenter la disponibilité de votre application, car elle applique que les modifications de secret se produisent pendant les mises à niveau propagées. Il s’adapte également mieux à mesure que les secrets sont mis en cache et servis à partir du cluster. Si votre application utilise des paramètres chiffrés aujourd’hui, il n’existe que des modifications minimales nécessaires dans votre code d’application pour utiliser KeyVaultReferences. Votre application peut continuer à s’attendre à ce qu’il y ait un seul secret, et que ce secret soit le même pendant toute la durée du processus.

Prérequis

  • Identité managée pour applications Service Fabric

    La prise en charge de Service Fabric KeyVaultReference utilise l’identité gérée d’une application pour extraire les secrets pour le compte de l’application. Vous devez déployer votre application via ARM et l’affecter à une identité managée. Suivez cet document pour activer l’identité managée pour votre application.

  • Banque de secrets centrale (CSS, Central Secrets Store).

    Central Secrets Store (CSS) est le cache de secrets local chiffré de Service Fabric. Cette fonctionnalité utilise CSS pour protéger et conserver les secrets une fois qu’ils ont été extraits de Key Vault. L’activation de ce service système est nécessaire pour utiliser KeyVaultReferences. Consultez ce document pour activer et configurer CSS.

  • Accordez l’autorisation d’accès avec identité managée de l’application au coffre de clés Azure Key Vault

    Pour voir comment accorder un accès avec identité managée à Key Vault, reportez-vous à ce document. Notez également que, si vous utilisez une identité managée affectée par le système, l’identité managée est créée uniquement après le déploiement de l’application. Cela peut créer des conditions de concurrence lorsque l’application tente d’accéder au secret avant que l’identité ne soit autorisée à accéder au coffre. Le nom de l’identité affectée par le système sera {cluster name}/{application name}/{service name}.

KeyVaultReferences et KeyVaultReferences managée

L’idée de base de KeyVaultReferences est qu’au lieu de définir la valeur de votre paramètre d’application en tant que clé secrète, vous définissiez KeyVaultReferences sur l’URL de Key Vault, qui sera ensuite associée à la valeur de la clé secrète lors de l’activation de votre application. Dans Key Vault, une seule clé secrète, par exemple, https://my.vault.azure.net/secrets/MySecret/ peut avoir plusieurs versions, par exemple https://my.vault.azure.net/secrets/MySecret/<oid1> et <oid2>. Lorsque vous utilisez une clé KeyVaultReference, la valeur doit être une référence versionnée (https://my.vault.azure.net/secrets/MySecret/<oid1>). Si vous faites pivoter ce secret dans le coffre, par exemple, <oid2>vous devez déclencher une mise à niveau d’application vers la nouvelle référence. Lorsque vous utilisez une référence ManagedKeyVaultReference, la valeur doit être une référence sans version (https://my.vault.azure.net/secrets/MySecret/). Service Fabric résout la dernière instance <oid1> et active l’application avec ce secret. Si vous faites pivoter le secret dans le coffre<oid2>, Service Fabric déclenche automatiquement une mise à niveau de paramètre d’application pour passer à <oid2> en votre nom.

Notes

La prise en charge de KeyVaultReference (clés secrètes avec version) pour les applications Service Fabric est en disponibilité générale à partir de Service Fabric version 7.2 CU5. Il est recommandé d’effectuer la mise à niveau vers cette version avant d’utiliser cette fonctionnalité.

Notes

La prise en charge de Managed KeyVaultReference (clés secrètes sans version) pour les applications Service Fabric est en disponibilité générale à partir de Service Fabric version 9.0.

Utiliser KeyVaultReferences dans votre application

KeyVaultReferences peut être utilisé

En tant que variable d'environnement

<EnvironmentVariables>
      <EnvironmentVariable Name="MySecret" Type="KeyVaultReference" Value="<KeyVaultURL>"/>
</EnvironmentVariables>

string secret =  Environment.GetEnvironmentVariable("MySecret");

Monté en tant que fichier dans votre conteneur

  • Ajoutez une section à settings.xml

    Définissez le paramètre MySecret avec le type KeyVaultReference et la valeur <KeyVaultURL>

    <Section Name="MySecrets">
    <Parameter Name="MySecret" Type="KeyVaultReference" Value="<KeyVaultURL>"/>
</Section>

  • Référencez la nouvelle section du fichier ApplicationManifest.xml dans <ConfigPackagePolicies>

    <ServiceManifestImport>
    <Policies>
    <IdentityBindingPolicy ServiceIdentityRef="MyServiceMI" ApplicationIdentityRef="MyApplicationMI" />
    <ConfigPackagePolicies CodePackageRef="Code">
        <!--Linux container example-->
        <ConfigPackage Name="Config" SectionName="MySecrets" EnvironmentVariableName="SecretPath" MountPoint="/var/secrets"/>
        <!--Windows container example-->
        <!-- <ConfigPackage Name="Config" SectionName="dbsecrets" EnvironmentVariableName="SecretPath" MountPoint="C:\secrets"/> -->
    </ConfigPackagePolicies>
    </Policies>
</ServiceManifestImport>

  • Consommer les secrets à partir du code de service

    Chaque paramètre répertorié sous <Section Name=MySecrets> sera un fichier dans le dossier sur lequel pointe EnvironmentVariable SecretPath. L’extrait de code C# ci-dessous montre comment lire MySecret à partir de votre application.

    string secretPath = Environment.GetEnvironmentVariable("SecretPath");
using (StreamReader sr = new StreamReader(Path.Combine(secretPath, "MySecret"))) 
{
    string secret =  sr.ReadToEnd();
}

    Notes

    MountPoint contrôle le dossier dans lequel les fichiers contenant des valeurs secrètes seront montés.

Comme référence à un mot de passe de référentiel de conteneur

 <Policies>
      <ContainerHostPolicies CodePackageRef="Code">
        <RepositoryCredentials AccountName="MyACRUser" Type="KeyVaultReference" Password="<KeyVaultURL>"/>
      </ContainerHostPolicies>

Utiliser KeyVaultReferences managé dans votre application

Tout d’abord, vous devez activer la surveillance des secrets, en mettant à niveau la définition de votre cluster, pour ajouter le paramètre EnableSecretMonitoring, en plus des autres configurations CSS requises :

"fabricSettings": [
    {
        "name": "CentralSecretService",     
        "parameters": [
            {
                "name": "EnableSecretMonitoring",
                "value": "true"
            },
            {
                "name":  "DeployedState",
                "value":  "enabled"
            },
            {
                "name" : "EncryptionCertificateThumbprint",
                "value": "<thumbprint>"
            },
            {
                "name":  "MinReplicaSetSize",
                "value":  "<size>"
            },
            {
                "name":  "TargetReplicaSetSize",
                "value":  "<size>"
            }
        ]
    }
],

Remarque

La valeur par défaut pourrait devenir true à l’avenir

Une fois la mise à niveau du cluster terminée, votre application utilisateur peut être mise à niveau. Partout où une KeyVaultReference peut être utilisée, une ManagedKeyVaultReference peut également être utilisée, par exemple,

    <Section Name="MySecrets">
        <Parameter Name="MySecret" Type="ManagedKeyVaultReference" Value="[MySecretReference]"/>
    </Section>

La principale différence avec les ManagedKeyVaultReferences c’est qu’elles ne peuvent pas être codées en dur dans le manifeste de type d’application. Elles doivent être déclarées en tant que paramètres au niveau de l’application, et elles doivent être remplacées dans votre définition d’application ARM.

Voici un extrait d’un manifeste bien formé

<?xml version="1.0" encoding="utf-8"?>
<ApplicationManifest ApplicationTypeName="MyAppType" ApplicationTypeVersion="1.0.0">
  <Parameters>
    <Parameter Name="MySecretReference" DefaultValue="" />
  </Parameters>
  <ServiceManifestImport>
    <EnvironmentOverrides CodePackageRef="Code">
      <EnvironmentVariable Name="MySecret" Value="[MySecretReference]" Type="ManagedKeyVaultReference" />
    </EnvironmentOverrides>
    <Policies>
      <IdentityBindingPolicy ServiceIdentityRef="MySvcIdentity" ApplicationIdentityRef="MyAppIdentity" />
    </Policies>
  </ServiceManifestImport>
  <Principals>
    <ManagedIdentities>
      <ManagedIdentity Name="MyAppIdentity" />
    </ManagedIdentities>
  </Principals>
</ApplicationManifest>

et un extrait de la définition de ressource d’application :

{
    "type": "Microsoft.ServiceFabric/clusters/applications",
    "name": "MyApp",
    "identity": {
        "type" : "userAssigned",
        "userAssignedIdentities": {
            "[variables('userAssignedIdentityResourceId')]": {}
        }
    },
    "properties": {
        "parameters": {
            "MySecretReference": "https://my.vault.azure.net/secrets/MySecret/"
        },
        "managedIdentities": [
            {
            "name" : "MyAppIdentity",
            "principalId" : "<guid>"
            }
        ]
    }
}

La déclaration de ManagedKeyVaultReference en tant que paramètre d’application, ainsi que la substitution de ce paramètre au moment du déploiement est nécessaire pour Service Fabric afin de gérer correctement le cycle de vie du secret déployé.

Étapes suivantes