Grundlagen der Azure-Bicep-Sicherheit

Dieser Beitrag wurde von Snyk Ambassador Mark Johnson (@tazmainiandevil) verfasst. Erhalten Sie exklusiven Zugang zu Snyk, indem Sie sich als Snyk Ambassador anmelden.

Azure Bicep wird immer beliebter und entwickelt sich rasch zum Nachfolger von Azure Resource Manager (ARM)-Vorlagen. In diesem Beitrag gehe ich auf einige grundlegende Sicherheitsaspekte bei der Verwendung von Bicep ein. Wenn Sie Bicep noch nicht kennen, empfehle ich Ihnen, einen Blick in die Dokumentation zu Microsoft Learn zu werfen, um mehr zu erfahren.

Halten Sie Secrets aus der Versionsverwaltung heraus

Wir alle wissen, dass Secrets nicht in die Versionsverwaltung gehören. Trotzdem können sie leicht versehentlich in Dateien landen – insbesondere, wenn Sie Ihre Bicep-Konfigurationen lokal testen.

So vermeiden Sie, Secrets mitzucommitten:

• Übergeben Sie Parameter über die Befehlszeile.

• Verwenden Sie eine JSON-Parameterdatei, die von der Versionsverwaltung ignoriert wird. Fügen Sie die Datei beispielsweise zu Ihrer .gitignore-Datei hinzu, wenn Sie Git verwenden.

Eingaben schützen

Parameter von außen zu übergeben ist das eine. Doch wie stellen Sie sicher, dass Secrets geschützt sind und nicht in Ausgaben erscheinen? Bicep stellt für Parameter vom Typ String und Object den Decorator @secure bereit. Zum Beispiel:

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

Vorsicht bei Ausgaben

Ausgaben zu Ihren Bicep-Modulen hinzuzufügen, ist sehr nützlich. Dabei gibt es jedoch einiges zu beachten. Wenn Sie eine Ausgabe festlegen, die wie ein Secret aussieht, weist Bicep Sie mit einer Warnung darauf hin, dass Sie möglicherweise Secrets offenlegen. Die folgende Ausgabe für eine Verbindungszeichenfolge zu einem Speicherkonto würde eine solche Warnung auslösen:

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

Wenn der Wert jedoch zunächst einer Variable zugewiesen und erst danach als Ausgabe festgelegt wird, erscheint keine Warnung – das Problem kann dann leicht übersehen werden.

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

Sehen wir uns nun an, was passiert, wenn eine Speicherkontoressource mit der folgenden Konfiguration in Azure bereitgestellt wird:

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

Alle in Bicep definierten Ausgaben finden Sie unter Bereitstellungen für die Ressourcengruppe, in der die Ressourcen bereitgestellt wurden:

Bei den Ausgaben von StorageDeploy sehen wir, dass die Verbindungszeichenfolge den Kontoschlüssel im Klartext enthält:

Das bedeutet, dass jede Person mit Zugriff auf die Ressourcen im Azure-Portal diese Ausgaben sehen kann. Um eine gute Sicherheitslage zu gewährleisten, sollten Sie in Bicep keine Secrets als Ausgaben zurückgeben.

Hoffentlich unterstützt Bicep künftig den Decorator @secure für Ausgaben, damit Secrets sicher zurückgegeben werden können.

Secrets aus Ressourcen

Wenn es problematisch ist, Secrets aus Bicep zurückzugeben, wie lassen sich Secrets dann von einem Modul an ein anderes übergeben? Eine Möglichkeit besteht darin, mit dem Schlüsselwort existing auf eine vorhandene Ressource zuzugreifen. Zum Beispiel:

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}'

Diese Verbindungszeichenfolge kann dann als Eingabe für eine andere Ressource verwendet werden.

Secrets aus Key Vault

Vorhandene Ressourcen abzurufen, ist eine Möglichkeit, an Secrets zu gelangen. Es gibt aber auch Unterstützung dafür, Secrets aus einem Key Vault abzurufen.

Hinweis: Stellen Sie sicher, dass die Key-Vault-Zugriffskonfiguration den Zugriff über „Azure Resource Manager für die Vorlagenbereitstellung“ zulässt.

Der Zugriff auf Key Vaults erfolgt wie im vorherigen Abschnitt über das Schlüsselwort existing. Beachten Sie jedoch, dass die Methode getSecret nur verwendet werden kann, wenn Sie einem Modulparameter mit dem Decorator @secure einen Wert zuweisen:

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}

Bicep auf Sicherheitsprobleme scannen

Das Scannen von Infrastructure as Code (IaC) wird immer beliebter. Es ist erfreulich, dass Sicherheitsprobleme möglichst früh erkannt werden sollen. Snyk bietet eine kostenlose CLI, mit der Sie lokal IaC-Scans durchführen und Ihre Konfigurationen anhand von Sicherheits- und Compliance-Standards prüfen können. Bicep wird zwar nicht direkt unterstützt, aber ARM-Vorlagen, in die Bicep kompiliert wird, lassen sich scannen.

Um Bicep in ARM zu kompilieren, müssen Sie die Bicep-CLI installieren. Für den Einstieg mit der Snyk CLI erstellen Sie ein kostenloses Konto und installieren anschließend die Snyk CLI mit npm. Wenn Node.js lokal installiert ist, können Sie die CLI mit folgendem Befehl installieren:

1npm install snyk@latest -g

Nach der Installation und Einrichtung können Sie folgenden Befehl ausführen:

1az bicep build -f {file_name}.bicep

Dadurch wird eine JSON-Datei mit demselben Namen wie die Bicep-Datei erstellt. Anschließend können Sie den Snyk-Scan mit folgendem Befehl ausführen:

1snyk iac test {file_name}.json

Abschließende Gedanken

Sicherheit müssen wir alle berücksichtigen. Auch wenn sie sich ständig verändert, können wir mit zunehmendem Wissen mehr tun, um unsere Ressourcen zu schützen. Ich hoffe, dieser Beitrag war informativ und hat Ihnen einige Einblicke gegeben, wie Sie Ihre Bicep-Konfigurationen absichern können.