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 aide à 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 cross-tenant

Configuration

Pour configurer GGScout afin qu'il fonctionne 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 Azure subscription ID	Oui
mode	Mode d'intégration (parmi : « read », « write », « read/write »)	Non	"read"
env	Libellé d'environnement pour catégoriser les secrets (par ex. « production », « staging », « development »)	Non
owner	Propriétaire de cette source (un e-mail, généralement d'un employé ou d'une équipe)	Non
[[sources.<name>.include]]	Table de motifs de resource_id à inclure (voir ci-dessous)	Non
[[sources.<name>.exclude]]	Table de motifs de resource_id à exclure (voir ci-dessous)	Non

Note :

• Utilisez les tables [[sources.<name>.include]] et [[sources.<name>.exclude]] pour spécifier plusieurs règles d'inclusion/exclusion. Chaque table doit comporter un tableau resource_ids.
• Les motifs prennent en charge les wildcards (*) uniquement à la fin pour la correspondance par préfixe. Pour des correspondances exactes, indiquez le nom complet sans wildcards.

Authentification

GGScout utilise DefaultAzureCredential pour l'authentification, qui tente d'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. Vous devez fournir les variables d'environnement nécessaires à la méthode d'authentification choisie.

Variables d'environnement

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

• AZURE_SUBSCRIPTION_ID : votre Azure subscription ID
• AZURE_TENANT_ID : votre Azure tenant ID
• AZURE_CLIENT_ID : le client ID de votre service principal
• AZURE_CLIENT_SECRET : le client secret de votre service principal

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

Permissions Azure requises

Pour récupérer des 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 posséder au moins l'un des rôles intégrés suivants attribués 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 gérer les secrets
3. Key Vault Administrator (Key Vault Administrator) : accès complet au Key Vault

Pour un contrôle plus fin, 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 (modèle ancien)

Si votre Key Vault utilise l'ancien modèle Access Policy au lieu du RBAC, l'identité doit avoir les 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 cela offre un contrôle plus fin et une meilleure intégration avec la gestion d'identités d'Azure.

Bonnes pratiques

1. Utilisez Managed Identity lors d'une 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 dans vos secrets au fil du temps
4. Faites tourner régulièrement les identifiants de service principal
5. Utilisez des Key Vaults distincts pour chaque environnement