Les fondamentaux de la sécurité d’Azure Bicep

Cet article a été rédigé par l’ambassadeur Snyk Mark Johnson (@tazmainiandevil). Découvrez Snyk de l’intérieur en devenant ambassadeur Snyk.

Azure Bicep gagne chaque jour en popularité et devient rapidement le remplaçant des modèles Azure Resource Manager (ARM). Dans cet article, je vais passer en revue quelques fondamentaux de sécurité liés à l’utilisation de Bicep. Si vous ne connaissez pas Bicep, je vous recommande de consulter la documentation Microsoft Learn pour en savoir plus.

Ne stockez pas de secrets dans le code source

Nous savons tous qu’il faut éviter de stocker des secrets dans le code source, mais il est très facile d’en laisser accidentellement dans des fichiers, surtout lorsque vous testez vos configurations Bicep en local.

Voici quelques moyens d’éviter de valider des secrets dans le code source :

• Transmettez les paramètres en ligne de commande.

• Utilisez un fichier JSON de paramètres ignoré par le système de contrôle de version. Par exemple, ajoutez-le à votre fichier .gitignore si vous utilisez Git.

Sécurisez les entrées

Transmettre des paramètres de l’extérieur, c’est une chose, mais comment s’assurer que les secrets sont protégés et ne s’affichent pas dans les sorties ? Bicep fournit un décorateur @secure pour les paramètres de type String et Object. Par exemple :

1@secure()
2param adminPassword string
3
4@secure()
5param adminCredentials object

Attention aux sorties

Ajouter des sorties à vos modules Bicep est très utile, mais il y a quelques points à prendre en compte. Si vous définissez une sortie qui ressemble à un secret, Bicep vous avertit que vous exposez potentiellement des secrets. La sortie suivante, qui contient une chaîne de connexion à un compte de stockage, déclencherait cet avertissement :

1output connection string = 'DefaultEndpointsProtocol=https;AccountName=${storageaccount.name};EndpointSuffix=${environment().suffixes.storage};AccountKey=${listKeys(storageaccount.id, storageaccount.apiVersion).keys[0].value}'

Cependant, si la valeur était d’abord affectée à une variable avant d’être attribuée à la sortie, aucun avertissement ne s’afficherait et il serait facile de ne pas le remarquer.

1var connectionString = 'DefaultEndpointsProtocol=https;AccountName=${storageaccount.name};EndpointSuffix=${environment().suffixes.storage};AccountKey=${listKeys(storageaccount.id, storageaccount.apiVersion).keys[0].value}'
2
3output connection string = connectionString

Voyons maintenant ce qui se passe lorsqu’une ressource de compte de stockage est déployée sur Azure avec la configuration suivante :

1deploy.bicep
2param location string = resourceGroup().location
3param tags object = {}
4param storageName string = 'stsecureteststore'
5param sku string = 'Standard_LRS'
6
7module storageModule 'modules/storage.bicep' = {
8  name: 'StorageDeploy'
9  params: {
10    location: location
11    storageName: storageName
12    tags: tags
13    sku: sku
14  }
15}
16
17modules/storage.bicep
18
19@description('The storage account name')
20@minLength(3)
21@maxLength(24)
22param storageName string
23@description('The storage account location')
24param location string
25@description('The tags for the storage account')
26param tags object
27@description('The storage account sku') 
28@allowed([ 'Standard_LRS', 'Standard_GRS', 'Standard_GZRS', 'Standard_RAGRS', 'Standard_RAGZRS', 'Standard_ZRS', 'Premium_LRS', 'Premium_ZRS' ])
29param sku string = 'Standard_LRS'
30@description('The access tier for the blob services') 
31@allowed([ 'Hot', 'Cool' ]) 
32param accessTier string = 'Hot' 
33@description('Allow public access to blobs') 
34param allowBlobPublicAccess bool = false 
35
36resource storageaccount 'Microsoft.Storage/storageAccounts@2022-05-01' = {
37  name: storageName
38  location: location
39  kind: 'StorageV2'
40  tags: tags
41  sku: {
42    name: sku
43  }
44  properties: {
45    supportsHttpsTrafficOnly: true
46    minimumTlsVersion: 'TLS1_2'
47    accessTier: accessTier
48    allowBlobPublicAccess: allowBlobPublicAccess
49  }
50}
51
52var connectionString = 'DefaultEndpointsProtocol=https;AccountName=${storageaccount.name};EndpointSuffix=${environment().suffixes.storage};AccountKey=${listKeys(storageaccount.id, storageaccount.apiVersion).keys[0].value}'
53output connection string = connectionString

Toutes les sorties définies dans Bicep sont visibles sous Déploiements pour le groupe de ressources dans lequel les ressources ont été déployées :

En examinant les sorties de StorageDeploy, nous constatons que la chaîne de connexion affiche la clé du compte en texte brut :

Cela signifie que toute personne autorisée à consulter les ressources dans le portail Azure peut voir ces sorties. Pour maintenir une bonne posture de sécurité, il est recommandé de ne pas renvoyer de secrets dans les sorties Bicep.

Espérons que Bicep prendra en charge à l’avenir le décorateur @secure pour les sorties, afin de permettre de renvoyer des secrets en toute sécurité.

Secrets provenant de ressources

Si renvoyer des secrets depuis Bicep pose problème, comment récupérer des secrets d’un module à l’autre ? Une option consiste à accéder à une ressource existante à l’aide du mot-clé existing. Par exemple :

1param storageName string
2
3resource storageaccount 'Microsoft.Storage/storageAccounts@2022-05-01' existing = {
4  name: storageName  
5}
6
7var connectionString = 'DefaultEndpointsProtocol=https;AccountName=${storageName};EndpointSuffix=${environment().suffixes.storage};AccountKey=${listKeys(storageaccount.id, storageaccount.apiVersion).keys[0].value}'

Cette chaîne de connexion pourrait ensuite être utilisée comme entrée pour une autre ressource.

Secrets provenant de Key Vault

Récupérer des ressources existantes est une façon d’obtenir des secrets, mais il est également possible d’utiliser Key Vault pour les récupérer.

Remarque : assurez-vous que la configuration d’accès à Key Vault autorise l’accès via « Azure Resource Manager pour le déploiement de modèles ».

Les coffres Key Vault sont accessibles comme dans la section précédente, à l’aide du mot-clé existing. Notez toutefois que la méthode getSecret ne peut être utilisée que pour affecter une valeur à un paramètre de module doté du décorateur @secure :

1deploy.bicep
2param location string = resourceGroup().location
3param tags object
4param sqlServerName string
5param keyVaultName string
6param keyVaultResourceGroupName string
7param subscriptionId string = subscription().subscriptionId
8
9resource vaultResource 'Microsoft.KeyVault/vaults@2022-07-01' existing = {
10  name: keyVaultName 
11  scope: resourceGroup(subscriptionId, keyVaultResourceGroupName  )
12}
13
14module sqlModule 'modules/sql.bicep' = {
15  name: 'SqlDeploy'
16  params: {
17    location: location
18    tags: tags
19    sqlServerName: sqlServerName
20    administratorLogin: vaultResource.getSecret('sqlUser')
21    administratorLoginPassword: vaultResource.getSecret('sqlPassword')
22  }  
23}
24
25modules/sql.bicep
26@description('The resource location')
27param location string
28@description('The tags for the resources')
29param tags object
30@description('The name for the SQL Server')
31param sqlServerName string
32@secure()
33@description('The SQL Administrator Login')
34param administratorLogin string
35@secure()
36@description('The SQL Administrator password')
37param administratorLoginPassword string
38
39resource sqlServerResource 'Microsoft.Sql/servers@2022-05-01-preview' = {
40  name: sqlServerName
41  location: location
42  tags:tags
43  properties: {
44    administratorLogin: administratorLogin
45    administratorLoginPassword: administratorLoginPassword
46  }
47}

Analyser la sécurité de Bicep

L’analyse de l’infrastructure as code (IaC) gagne en popularité, et il est réjouissant de constater que l’on cherche à détecter les problèmes de sécurité le plus tôt possible. Snyk propose une CLI gratuite qui permet d’effectuer des analyses IaC en local, selon des normes de sécurité et de conformité. Elle ne prend pas directement en charge le format Bicep, mais permet d’analyser les modèles ARM vers lesquels Bicep est compilé.

Pour compiler Bicep en ARM, vous devez avoir installé la CLI Bicep. Pour commencer à utiliser la CLI Snyk, créez un compte gratuit, puis installez la CLI Snyk avec npm. Si Node.js est installé en local, vous pouvez l’installer en exécutant la commande suivante :

1npm install snyk@latest -g

Une fois l’installation et la configuration terminées, vous pouvez exécuter la commande suivante :

1az bicep build -f {file_name}.bicep

Cette commande génère un fichier JSON portant le même nom que le fichier Bicep. Vous pouvez ensuite lancer l’analyse Snyk avec la commande suivante :

1snyk iac test {file_name}.json

Pour conclure

La sécurité est un enjeu auquel nous devons tous penser. Même si la cible évolue constamment, plus nous apprenons, plus nous pouvons contribuer à protéger nos ressources. J’espère que cet article vous a été utile et vous a apporté des pistes pour sécuriser vos configurations Bicep.