Fundamentos de seguridad de Azure Bicep

Esta publicación fue escrita por el embajador de Snyk, Mark Johnson (@tazmainiandevil). Obtén acceso interno a Snyk al registrarte para convertirte en embajador de Snyk.

Azure Bicep gana popularidad día a día y rápidamente se está convirtiendo en el reemplazo de las plantillas de Azure Resource Manager (ARM). En esta publicación, voy a repasar algunos fundamentos de seguridad para usar Bicep. Si no conoces Bicep, te recomiendo consultar la documentación de Microsoft Learn para obtener más información.

Mantén los secretos fuera del control de código fuente

Todos sabemos que queremos mantener nuestros secretos fuera del control de código fuente, pero es muy fácil dejar secretos en los archivos por accidente, sobre todo al probar las configuraciones de Bicep de forma local.

Algunas formas de evitar confirmar secretos son:

• Pasa los parámetros mediante la línea de comandos.

• Usa un archivo JSON de parámetros excluido del control de código fuente. Por ejemplo, agrégalos a tu archivo .gitignore si usas Git.

Protege las entradas

Pasar parámetros desde el exterior es una cosa, pero ¿cómo puedes asegurarte de que los secretos estén protegidos y no aparezcan en las salidas? Bicep ofrece un decorador @secure para los parámetros de tipo String y Object. Por ejemplo:

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

Ten cuidado con las salidas

Agregar salidas a tus módulos de Bicep es muy útil, pero hay algunas cosas que debes tener en cuenta. Si configuras una salida que parece un secreto, Bicep te advertirá que estás exponiendo posibles secretos. La siguiente salida para una cadena de conexión a una cuenta de almacenamiento generaría esa advertencia:

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

Sin embargo, si el valor se agrega a una variable antes de asignarlo a la salida, no se mostraría ninguna advertencia y sería fácil no detectarlo.

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

Ahora, veamos qué sucede si se implementa un recurso de cuenta de almacenamiento en Azure con la siguiente configuración:

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

Todas las salidas definidas en Bicep se pueden ver en Implementaciones del grupo de recursos en el que se implementaron los recursos:

Al revisar las salidas de StorageDeploy, vemos que la conexión muestra la clave de la cuenta en texto sin formato:

Esto significa que cualquier persona con acceso para ver los recursos en Azure Portal puede ver estas salidas. Para mantener una buena postura de seguridad, se recomienda no devolver secretos como salidas en Bicep.

Esperamos que Bicep admita en el futuro el uso del decorador @secure para las salidas, de modo que devolver secretos sea seguro.

Secretos de los recursos

Si devolver secretos desde Bicep es un problema, ¿cómo puedes obtener secretos de un módulo a otro? Una opción es acceder a un recurso existente con la palabra clave existing. Por ejemplo:

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

Esta cadena de conexión podría usarse como entrada para otro recurso.

Secretos de Key Vault

Obtener recursos existentes es una forma de conseguir secretos, pero también puedes usar Key Vault para recuperarlos.

Nota: Asegúrate de que la configuración de acceso de Key Vault permita el acceso a través de "Azure Resource Manager para la implementación de plantillas".

Se accede a Key Vaults de la misma forma que en la sección anterior, mediante la palabra clave existing. Sin embargo, debes tener en cuenta que el método getSecret solo se puede usar al asignar un parámetro de módulo con el decorador @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}

Análisis de seguridad de Bicep

El análisis de la infraestructura como código (IaC) es cada vez más popular, y es alentador ver que hay interés en encontrar problemas de seguridad lo antes posible. Snyk ofrece una CLI gratuita que puedes usar para analizar IaC de forma local según estándares de seguridad y cumplimiento. Aunque no admite directamente el formato Bicep, sí permite analizar las plantillas ARM en las que se compila Bicep.

Para compilar Bicep en ARM, debes tener instalada la CLI de Bicep. Para comenzar a usar Snyk CLI, crea una cuenta gratuita y luego instala Snyk CLI con npm. Si tienes Node.js instalado localmente, puedes instalarla ejecutando:

1npm install snyk@latest -g

Una vez instalada y configurada, puedes ejecutar el comando:

1az bicep build -f {file_name}.bicep

Esto generará un archivo JSON con el mismo nombre que el archivo Bicep. Luego, podrás ejecutar el análisis de Snyk con el comando:

1snyk iac test {file_name}.json

Reflexiones finales

Todos debemos pensar en la seguridad. Aunque es un objetivo que cambia constantemente, cuanto más aprendemos, más podemos hacer para ayudar a proteger nuestros recursos. Espero que esta publicación haya sido informativa y te haya dado ideas para proteger tus configuraciones de Bicep.