Gestion des secrets

Configuration et démarrage de l’orchestrateur

Gestion des secrets

Pour connecter des systèmes d’accès, il est nécessaire d’inclure des comptes de service, des informations d’identification administratives, des clés API et d’autres éléments secrets dans vos configurations. Par exemple, un connecteur LDAP aura besoin d’un compte administrateur et d’un justificatif d’identité pour pouvoir vérifier les utilisateurs ou rechercher des attributs, un connecteur Azure AD nécessitera un identifiant client et un secret, et votre configuration tls peut nécessiter des certificats et des clés qui ne sont pas conservés sur le système de fichiers local.

Maverics s’intègre à diverses solutions de gestion des secrets, qui stockent les secrets que les instances de la plate-forme d’orchestration chargent au démarrage. Les intégrations actuelles sont les suivantes :

HashiCorp Vault
AWS Secrets Manager
Azure Key Vault
CyberArk Conjur
CyberArk CCP
Delinea Secret Server
Fichier YAML (par exemple, secrets.yaml)

Si aucune solution de gestion des secrets n’est spécifiée, Maverics chargera par défaut les secrets spécifiés en texte clair dans le fichier de configuration maverics.yaml par défaut ou dans le fichier de configuration de base que vous avez spécifié (par exemple, my-maverics.yaml).

connectors:
   - name: ldap
     type: ldap
     serviceAccountPassword: ldapServiceAccountPassword
     serviceAccountUsername: uid=mycorpadmin,ou=Admins,o=MyCorp,c=US
     # ...

Si les configurations des connecteurs sont séparées et incorporées à l’aide de la fonction « include », les secrets doivent être définis dans des fichiers spécifiques aux connecteurs (par exemple, myAzureADconnector.yaml).

Chaque connecteur nécessite des informations d’identification, des secrets et des clés qui lui sont propres. Consultez le document de référence relatif aux connecteurs pour obtenir des précisions sur les éléments que vous devrez collecter et stocker dans votre solution de gestion des secrets.

Pour déclarer une valeur comme étant un secret dans un fichier de configuration maverics.yaml, il suffit de la placer entre des crochets :

connectors:
  - name: okta
    type: okta
    apiToken: <oktaAPIToken>
    oauthClientID: <oktaOAuthClientID>
    oauthClientSecret: <oktaOAuthClientSecret>

Les secrets peuvent être utilisés à la place des chemins d’accès aux fichiers pour les certificats et les clés dans la section tls.

tls:
  maverics:
    certFile: <example.com.crt>
    keyFile: <example.com.key>

ℹ️

Si la connexion à votre fournisseur de secrets implique de passer par un proxy de réseau, veuillez consulter la documentation relative au proxy de réseau.

HashiCorp Vault

Maverics prend en charge des outils tiers qui permettent de stocker et de gérer en toute sécurité des secrets, des informations d’identification et des clés. Dans cette section, nous verrons comment utiliser HashiCorp Vault en tant que fournisseur de secrets.

Déployer HashiCorp Vault

Pour commencer, il vous faudra d’abord télécharger et installer HashiCorp Vault.

Après avoir configuré une instance HashiCorp Vault, renseignez les secrets et configurez l’authentification pour Maverics.

L’orchestrateur Maverics permet actuellement de charger des secrets à partir d’AppRoles ou de jetons, les autorisations AppRoles sont cependant préconisées.

Chargement de secrets à partir de HashiCorp Vault à l’aide d’AppRole auth

Pour activer AppRole auth, spécifiez les attributs role_id et secret_id qui sont utilisés pour récupérer un jeton d’accès au coffre-fort. La valeur secret_id n’est pas nécessaire si la liaison secrète est désactivée dans la configuration AppRole.

Pour charger les secrets depuis HashiCorp Vault en utilisant HTTPS, définissez la variable d’environnement MAVERICS_SECRET_PROVIDER dans le fichier /etc/maverics/maverics.env, en utilisant le motif suivant :

MAVERICS_SECRET_PROVIDER='hashivault://<URL OF INSTANCE>/secret/data/maverics?role_id=$ROLE_ID&secret_id=$SECRET_ID'

Maverics chargera les secrets nécessaires à partir du coffre-fort et les rendra accessibles au moteur d’exécution.

Chargement de secrets à partir de HashiCorp Vault à l’aide de Token auth

Pour activer l’authentification par jeton, spécifiez l’attribut du jeton afin de spécifier le jeton d’authentification utilisé aux fins de communication avec le coffre-fort.

MAVERICS_SECRET_PROVIDER='hashivault://<URL OF INSTANCE>/secret/data/maverics?token=$ACCESS_TOKEN'

Maverics chargera les secrets nécessaires à partir du coffre-fort et les rendra accessibles au moteur d’exécution.

Chargement des secrets d’un espace de noms spécifique dans HashiCorp Vault

Pour les secrets stockés dans des espaces de noms, spécifiez l’attribut de l’espace de noms en tant que paramètre d’interrogation de l’adresse HashiCorp Vault. Veuillez noter qu’à l’heure où nous écrivons ces lignes, l’espace de noms n’est pris en charge qu’avec l’édition Vault Enterprise.

MAVERICS_SECRET_PROVIDER='hashivault://<URL OF INSTANCE>/secret/data/maverics?role_id=$ROLE_ID&secret_id=$SECRET_ID&namespace=admin/my-namespace'

AWS Secrets Manager

Maverics peut s’intégrer à AWS pour injecter des secrets stockés dans AWS Secrets Manager dans les flux utilisateurs de Maverics afin de protéger les ressources de l’application. Maverics peut également déchiffrer les secrets chiffrés par KMS stockés dans Secrets Manager.

Prérequis

Pour utiliser Secrets Manager avec Maverics, vous aurez besoin des éléments suivants :

Un nouvel utilisateur IAM
Autorisations appropriées pour votre nouvel utilisateur IAM, telles que définies dans la configuration AWS IAM ci-dessous.
AWS AccessKey, Secret Access Key et Region correspondant à l’utilisateur IAM associé à Secrets Manager
Secrets Maverics dans Secrets Manager (texte clair ou clé/valeur)

Pour plus de détails, voir la documentation liée à chaque entrée.

Mettez à jour votre configuration Maverics avec les secrets AWS

AWS Secrets Manager prend en charge les secrets structurés en texte clair et en clé/valeur JSON. La configuration de Maverics doit être revue en fonction des références aux secrets dans AWS. Pour plus d’informations, reportez-vous à la section Créer et gérer des secrets avec AWS Secrets Manager.

Secrets en texte clair

Utilisez l’ID du secret ou le nom du secret comme paramètre fictif pour tous les secrets ou mots de passe à plusieurs lignes.

apps:
  - name: exampleSAMLApp
    type: saml
    audience: https://app.enterprise.com
    consumerServiceURL: https://app.enterprise.com/acs
    requestVerification:
      certificate: <dev/exampleSAMLApp/signingCertificate>
     # ...

Secrets clé/valeur JSON

Utilisez le format <secret ID:secret key> en tant que paramètre fictif pour tous les secrets ou mots de passe.

connectors:
   - name: azure
     type: azure
     oauthClientID: <dev/app100:clientID>
     oauthClientSecret: <dev/app100:clientSecret>
     # ...

Si une clé secrète est fournie, la valeur de la clé de l’objet JSON est renvoyée. Si seul l’ID du secret est fourni, l’intégralité du secret JSON est renvoyée.

Configuration AWS IAM

Les paramètres de la politique de Secrets Manager ne doivent autoriser que ce dont Maverics a besoin pour récupérer les valeurs secrètes.

Consultez la documentation AWS pour plus d’informations : https://docs.aws.amazon.com/secretsmanager/latest/userguide/auth-and-access_examples.html

Politique de ressources AWS IAM

L’exemple suivant est une politique basée sur les ressources que vous pouvez associer à un secret. Cet exemple est pertinent lorsque vous souhaitez autoriser l’accès à un même secret à plusieurs utilisateurs ou rôles.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::AccountId:role/EC2RoleToAccessSecrets"
      },
      "Action": "secretsmanager:GetSecretValue",
      "Resource": "*"
    }
  ]
}

Politique d’autorisations utilisateur AWS IAM

Permet de créer des clés d’accès pour un utilisateur AWS IAM disposant de droits d’accès restreints. Le fichier JSON suivant représente une politique appropriée pour un utilisateur IAM disposant des droits d’accès minimaux requis pour l’extraction de secrets :

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Action": [
      "secretsmanager:GetSecretValue"
    ],
    "Resource": "*"
  }
}

Politique relative aux clés gérées par le client AWS Decrypt

Si un secret est chiffré à l’aide d’une clé gérée par le client, vous devez autoriser l’accès au décryptage du secret en associant la politique suivante à une identité.

Attachez la politique à l’identité IAM soit en ajoutant/modifiant les autorisations, soit en créant une politique en ligne.
Définissez la ressource pour l’action kms:Decrypt en tant que KMSkey ARN.

Pour plus d’informations, reportez-vous à la section Associer une politique d’autorisations à une identité.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "secretsmanager:GetSecretValue",
      "Resource": "SecretARN"
    },
    {
      "Effect": "Allow",
      "Action": "kms:Decrypt",
      "Resource": "KMSKeyARN"
    }
  ]
}

Configuration de Maverics

Pour charger les secrets à partir d’AWS Secrets Manager, définissez la variable d’environnement MAVERICS_SECRET_PROVIDER à l’aide du motif suivant :

MAVERICS_SECRET_PROVIDER='awssecretsmanager://amazonaws.com'

ℹ️

Par défaut, Maverics utilise la configuration de l’environnement AWS.

Pour remplacer la configuration de l’environnement AWS, les valeurs accessKeyID, secretAccessKey et region peuvent être spécifiées sur la chaîne de connexion. Assurez-vous que les champs sont correctement encodés au format URL.

MAVERICS_SECRET_PROVIDER='awssecretsmanager://amazonaws.com?accessKeyID=aws-access-key-id&secretAccessKey=aws-secret-access-key&region=us-east-2'

./maverics_darwin_amd64 -secretProvider "awssecretsmanager://amazonaws.com" -config maverics.json

En cas de référencement des variables d’environnement :

source ./maverics.env && ./maverics_darwin_amd64

ℹ️

Nous prenons également en charge les sources de configuration AWS, telles que ~/.aws/config et ~/.aws/credentials.

Azure Key Vault

Pour charger les secrets depuis Azure Key Vault, définissez la variable d’environnement MAVERICS_SECRET_PROVIDER dans le fichier /etc/maverics/maverics.env avec les informations d’identification liées à votre application de compte de service, en utilisant le motif suivant :

MAVERICS_SECRET_PROVIDER='azurekeyvault://<KEYVAULT NAME>.vault.azure.net?clientID=<APP_CLIENT_ID>&clientSecret=<APP_CLIENT_SECRET>&tenantID=<TENANT_ID>'

Dans le fichier de configuration de l’orchestrateur, utilisez le nom de la ressource dans Key Vault en tant qu’espace réservé aux secrets.

Les certificats Azure Key Vault sont également pris en charge, mais le certificat et la clé doivent être codés en PEM et le fichier doit être au format suivant :

-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
-----BEGIN PRIVATE KEY-----
-----END PRIVATE KEY-----

ℹ️

Depuis février 2024, Azure ne permet plus de charger un fichier de clé PKCS1 .pem. Si vous disposez d’un fichier de clé PKCS1 .pem, il doit être converti en PKCS8 avant d’être combiné avec le certificat. Il est possible de convertir les PKCS1 en PKCS8 à l’aide de la commande suivante : openssl pkcs8 -topk8 -inform PEM -outform PEM -in rsa-private-key.pem -out pkcs8-private-key.pem -nocrypt

Le fichier doit être importé dans la section certificats, pas en tant que secret. Pour plus d’informations, reportez-vous au tutoriel : Importer un certificat dans Azure Key Vault.

Dans la configuration de l’orchestrateur, utilisez le même nom de certificat de Key Vault pour les champs certFile et keyFile. Par exemple :

tls:
  maverics:
    certFile: <exampleCertPair>
    keyFile: <exampleCertPair>

connectors:
   - name: azure
     type: azure
     authType: oauth
     oauthClientID: <exampleClientID>
     oauthClientSecret: <exampleClientSecret>
     # ...

CyberArk Conjur

L’orchestrateur Maverics peut récupérer des secrets de CyberArk Conjur (à la fois dans Conjur Secrets Manager Enterprise et Conjur Open Source) à l’aide de l’API REST de Conjur.

Pour charger les secrets d’un serveur Conjur, définissez la variable d’environnement MAVERICS_SECRET_PROVIDER, à l’aide du motif suivant :

MAVERICS_SECRET_PROVIDER="conjur://"

Par défaut, Maverics utilise la configuration d’environnement Cyberark Conjur. Par exemple, les variables d’environnement Conjur CONJUR_* ou CONJURRC.

Pour remplacer la configuration de l’environnement Cyberark Conjur, les champs account, hostID ou login, et apikey peuvent être spécifiés dans la chaîne de connexion. Assurez-vous que les champs sont correctement encodés au format URL.

MAVERICS_SECRET_PROVIDER="conjur://<CONJUR_HOST>/<account>/<hostID | login>/?apikey=some-api-key"

Exemple avec un hostID de host/mycompany/myapp :

MAVERICS_SECRET_PROVIDER="conjur://secrets.mydomain.com/myConjurAccount/host%2Fmycompany%2Fmyapp/?apikey=some-api-key"

Exemple avec un login de alice@devops :

MAVERICS_SECRET_PROVIDER="conjur://secrets.mydomain.com/myConjurAccount/alice%40devops/?apikey=some-api-key"

Autorisations

Assurez-vous que la clé API ou toute autre méthode d’authentification dispose des autorisations de lecture minimales pour accéder aux secrets référencés dans la configuration.

Utilisation des secrets dans la configuration

Dans maverics.yaml, utilisez le nom du secret Conjur comme paramètre fictif pour tous les secrets ou mots de passe. Par exemple :

connectors:
   - name: azure
     type: azure
     oauthClientID: <apps/clientID>
     oauthClientSecret: <mycompany/secret>
     # ...

Les identifiants de variables peuvent également être référencés au format suivant :

connectors:
  - name: azure
    type: azure
    oauthClientID: <myConjurAccount:variable:apps/clientID>
    oauthClientSecret: <myConjurAccount:variable:mycompany/secret>
    # ...

CyberArk CCP

L’orchestrateur Maverics peut récupérer des secrets de CyberArk CCP.

CyberArk CCP utilise la méthode d’authentification par certificat, il vous faut donc fournir le chemin d’accès à l’autorité de certification racine, au certificat du client et à la clé du client. Pour charger les secrets à partir de CCP, définissez la variable d’environnement MAVERICS_SECRET_PROVIDER dans le fichier /etc/maverics/maverics.env

MAVERICS_SECRET_PROVIDER="cyberarkccp://secrets.mydomain.com?appID=some-app-id&safe=some-safe&caFile=rootCA.crt&certFile=client.crt&keyFile=client.pem"

Il est également possible de spécifier des paramètres de dossier.

MAVERICS_SECRET_PROVIDER="cyberarkccp://secrets.mydomain.com?appID=some-app-id&folder=my-folder&safe=some-safe&caFile=rootCA.crt&certFile=client.crt&keyFile=client.pem"

Pour une description plus détaillée des paramètres, veuillez vous référer à la documentation CyberArk CCP.

ℹ️

Si les chemins d’accès à vos fichiers de certificats contiennent des caractères spéciaux ou des espaces, ils doivent être encodés dans l’URL, de la même manière que vous le feriez pour d’autres paramètres de requête URL.Par exemple, si votre fichier de clés se trouve dans /etc/my keys/the key.pem, le paramètre keyFile doit être le suivant :

keyFile=%2Fetc%2Fmy%20certs%2Fthe%20key.pem

Chargement des certificats à partir du Windows Store

Si vous souhaitez charger un certificat à partir du Windows Store, vous pouvez utiliser l’empreinte ou le sujet d’un certificat d’authentification ou d’une autorité de certification racine de votre choix. Pour un certificat d’authentification, utilisez les paramètres winCertThumbprint ou winCertSubject. Pour l’autorité de certification racine, utilisez les paramètres winRootCAThumbprint ou winRootCASubject. Si vous utilisez l’empreinte de l’autorité de certification racine et que vous ne fournissez pas le sujet ou le fichier, les certificats système par défaut seront chargés.

Exemple avec empreinte :

MAVERICS_SECRET_PROVIDER="cyberarkccp://secrets.mydomain.com?appID=some-app-id&safe=some-safe&winCertThumbprint=1234567890ABCDEF1234567890ABCDEF12345678&winRootCAThumbprint=1234567890ABCDEF1234567890ABCDEF12345678"

Exemple avec sujet :

MAVERICS_SECRET_PROVIDER="cyberarkccp://secrets.mydomain.com?appID=some-app-id&safe=some-safe&winCertSubject=cert.example.com&winRootCASubject=ca.example.com"

Utilisation des secrets dans la configuration

Pour déclarer une valeur comme étant un secret dans un fichier de configuration maverics.yaml, placez le secret (nom de l’objet) entre des crochets :

connectors:
  - name: okta
    type: okta
    apiToken: <oktaAPIToken>
    oauthClientID: <oktaOAuthClientID>
    oauthClientSecret: <oktaOAuthClientSecret>

ℹ️

Le fournisseur de secrets CyberArk CCP n’est capable de renvoyer des secrets que sous la forme d’une chaîne de caractères d’une seule ligne.

Delinea Secret Server

L’orchestrateur Maverics est en mesure de récupérer des secrets à partir de Delinea Secret Server en utilisant l’API REST.Tous les secrets doivent être co-localisés dans un seul dossier qui doit être spécifié dans l’URL de connexion.

Pour charger les secrets à partir d’un serveur Delinea, définissez la variable d’environnement MAVERICS_SECRET_PROVIDER dans le fichier /etc/maverics/maverics.env.

Utilisez le motif suivant :

MAVERICS_SECRET_PROVIDER="delinea://<DELINEA_HOST>?username=yourUser&password=yourPassword&folder=\\some\\folder"

Exemple avec un DELINEA_HOST de yourAccount.secretservercloud.com :

MAVERICS_SECRET_PROVIDER="delinea://yourAccount.secretservercloud.com?username=yourUser&password=yourPassword&folder=\\maverics"

Pour prendre en charge les mots de passe ou les dossiers contenant des caractères spéciaux, ils doivent être encodés en URI. Par exemple, pour un utilisateur dont le mot de passe serait « ()Pass1234&^% », la chaîne de connexion ressemblerait à ceci :

MAVERICS_SECRET_PROVIDER="delinea://yourAccount.secretservercloud.com?username=yourUser&password=%27%28%29Pass1234%26%5E%25%22&folder=\\maverics"

Dans maverics.yaml, utilisez le champ slug du secret Delinea et son chemin d’accès sous la forme <secretName.slug>, en tant qu’espace réservé pour les champs que vous souhaitez remplir à partir du serveur de secret.Vérifiez le modèle du secret pour trouver la valeur de l’identifiant URL du champ. Vous trouverez ci-dessous un exemple de configuration :

connectors:
   - name: azure
     type: azure
     oidcWellKnownURL: <secretName.wellKnown>
     oauthClientID: <secretName.client-id>
     oauthClientSecret: <secretName.client-secret>
     # ...

Configuration Delinea pour l’utilisateur du fournisseur de secrets

L’utilisateur désigné pour obtenir les secrets doit disposer des autorisations suivantes :

Accès au dossier où les secrets sont stockés
Autorisation View Secret
Autorisation Administer Secret Templates

Pour une configuration correcte de l’utilisateur Maverics Secrets Provider, il convient de procéder comme suit :

Créez un groupe maverics-api-users
Modifiez les autorisations du dossier pour permettre l’accès au groupe maverics-api-users
Créez un rôle maverics-secret-provider avec les autorisations suivantes :
- View Secret
- Administer Secret Templates
Attribuez le rôle maverics-secret-provider au groupe maverics-api-users
Créez un utilisateur maverics-secrets-user et assignez-le au groupe maverics-api-users

Fichier de secrets

ℹ️

Strata recommande vivement d’utiliser un coffre-fort en tant que fournisseur de secrets, ne serait-ce que pour les instances d’évaluation ou de test. Les options basées sur les fichiers ne sont proposées que par souci de commodité.

Pour charger les secrets depuis un fichier, définissez la variable d’environnement MAVERICS_SECRET_PROVIDER dans le fichier /etc/maverics/maverics.env, en utilisant le motif suivant :

MAVERICS_SECRET_PROVIDER=secretfile:////etc/maverics/secrets.yaml

Sous Windows, la variable d’environnement utiliserait le motif suivant :

MAVERICS_SECRET_PROVIDER=C:\Program Files\Strata Identity\Maverics\secrets.yaml

Pour charger des secrets à partir d’un fichier à l’aide de l’indicateur de ligne de commande, utilisez le motif suivant :

maverics -secretProvider secretfile:////etc/maverics/secrets.yaml

Le contenu du fichier peut être rempli avec autant de secrets que nécessaire :

secrets:
  oktaAPIToken: aReallyGoodToken
  oktaOAuthClientID: aReallyUniqueID
  oktaOAuthClientSecret: aReallyGoodSecret
  samlSigningCert: |+ # Multi-line values require |+.
    -----BEGIN CERTIFICATE-----
    ...
    -----END CERTIFICATE-----
  saml-signing-key: |+
    -----BEGIN PRIVATE KEY-----
    ...
    -----END PRIVATE KEY-----    

Configuration à distance et rechargement automatique Variables d’environnement