Intégration Azure Key Vault

GGScout prend en charge l'intégration avec Azure Key Vault pour collecter et surveiller vos secrets. Ce guide vous aidera à mettre en place et configurer l'intégration.

Fonctionnalités prises en charge

• Collecte de plusieurs versions de secrets
• Authentification DefaultAzureCredential
• Authentification Managed Identity
• Authentification Service Principal
• Accès inter-locataires

Configuration

Pour configurer GGScout afin de fonctionner avec Azure Key Vault, ajoutez la configuration suivante à votre fichier ggscout.toml :

[sources.azure-source-playground]
type = "azurekeyvault"
fetch_all_versions = true
subscription_id = "${AZURE_SUBSCRIPTION_ID}"
mode = "read"
env = "production"
owner = "devops-team@example.com"

[[sources.azure-source-playground.include]]
resource_ids = ["app-*", "database-*", "api-key"]

[[sources.azure-source-playground.exclude]]
resource_ids = ["test-*", "temp-*", "old-secret"]

Paramètres de configuration

Paramètre	Description	Requis	Valeur par défaut
type	Doit être défini sur "azurekeyvault"	Oui
fetch_all_versions	Indique s'il faut collecter toutes les versions des secrets	Oui
subscription_id	Votre ID d'abonnement Azure	Oui
mode	Mode d'intégration (l'un de : "read", "write", "read/write")	Non	"read"
env	Environnement par défaut des secrets de cette source. GitGuardian déduit un environnement par secret et se rabat sur cette valeur	Non
owner	Propriétaire de cette source (un e-mail, généralement celui d'un employé ou d'une équipe)	Non
[[sources.<name>.include]]	Table de motifs resource_id à inclure (voir ci-dessous)	Non
[[sources.<name>.exclude]]	Table de motifs resource_id à exclure (voir ci-dessous)	Non

Remarque :

• Utilisez les tables [[sources.<name>.include]] et [[sources.<name>.exclude]] pour spécifier plusieurs règles d'inclusion/exclusion. Chaque table doit avoir un tableau resource_ids.
• Les motifs prennent en charge les jokers (*) uniquement à la fin pour la correspondance par préfixe. Pour des correspondances exactes, spécifiez le nom complet sans jokers.
• Depuis ggscout 0.33.0, les tags des secrets sont envoyés à GitGuardian, qui déduit l'environnement de chaque secret à partir de tags tels que env ou environment, et utilise le env au niveau de la source uniquement lorsqu'aucun n'en nomme un. Le nom du vault et le nom du secret ne sont pas lus.

Authentification

GGScout utilise DefaultAzureCredential pour l'authentification, qui tente de s'authentifier en utilisant les méthodes suivantes dans l'ordre :

1. Variables d'environnement
2. Workload Identity
3. Managed Identity
4. Shared Token Cache
5. Visual Studio
6. Azure CLI
7. Azure PowerShell
8. Azure Developer CLI
9. Interactive Browser

remarque

Les méthodes d'authentification ne peuvent pas être configurées directement dans le fichier TOML. À la place, vous devez fournir les variables d'environnement nécessaires pour la méthode d'authentification que vous avez choisie.

Variables d'environnement

Pour l'authentification Service Principal, vous devez définir les variables d'environnement suivantes :

• AZURE_SUBSCRIPTION_ID : Votre ID d'abonnement Azure
• AZURE_TENANT_ID : Votre ID de locataire Azure
• AZURE_CLIENT_ID : L'ID client de votre service principal
• AZURE_CLIENT_SECRET : Le secret client de votre service principal

Pour les autres méthodes d'authentification, consultez la documentation Azure Identity pour connaître les variables d'environnement requises.

Permissions Azure requises

Pour récupérer les secrets depuis Azure Key Vault, l'identité utilisée par GGScout (qu'il s'agisse d'une Managed Identity, d'un Service Principal ou d'un compte utilisateur) doit disposer des permissions appropriées.

Permissions RBAC

L'identité doit avoir au moins l'un des rôles intégrés suivants attribué au Key Vault :

1. Key Vault Secrets User (Key Vault Secrets User) : Permet de lire les valeurs des secrets
2. Key Vault Secrets Officer (Key Vault Secrets Officer) : Permet de lire et de gérer les secrets
3. Key Vault Administrator (Key Vault Administrator) : Accès complet au Key Vault

Pour un contrôle plus granulaire, vous pouvez créer un rôle personnalisé avec les permissions suivantes :

{
  "Name": "GGScout Key Vault Reader",
  "Description": "Allows GGScout to read secrets from Key Vault",
  "Actions": [
    "Microsoft.KeyVault/vaults/secrets/read",
    "Microsoft.KeyVault/vaults/secrets/versions/read",
    "Microsoft.KeyVault/vaults/secrets/list"
  ],
  "NotActions": [],
  "DataActions": [],
  "NotDataActions": [],
  "AssignableScopes": [
    "/subscriptions/{subscription-id}/resourceGroups/{resource-group}/providers/Microsoft.KeyVault/vaults/{vault-name}"
  ]
}

Access Policy (hérité)

Si votre Key Vault utilise l'ancien modèle Access Policy au lieu de RBAC, l'identité doit disposer des permissions suivantes :

• Permissions Get et List pour les secrets

astuce

Pour les environnements de production, il est recommandé d'utiliser RBAC pour la gestion des accès au Key Vault, car il offre un contrôle plus granulaire et une meilleure intégration avec la gestion des identités d'Azure.

Bonnes pratiques

1. Utilisez Managed Identity lors de l'exécution sur l'infrastructure Azure
2. Suivez le principe du moindre privilège pour l'attribution des rôles
3. Activez fetch_all_versions pour suivre les changements de vos secrets au fil du temps
4. Effectuez une rotation régulière des identifiants du service principal
5. Utilisez des Key Vaults distincts pour différents environnements