Bicep does not resolve 'foo${uniqueString(resourceGroup().id)}' when deploying from VSCode - azure

I'm trying to deploy a Bicep template directly from VSCode with the Bicep extension, but it consistently fails. It works fine when I deploy from PowerShell using the New-AzResourceGroupDeployment cmdlet, though. Am I doing something wrong or is it a bug?
Bicep template deploys a new storage account and contains the following parameter for the storage account's name:
param storageName string = 'mystorage${uniqueString(resourceGroup().id)}'
Error when deploying from VSCode
When I deploy from VSCode, it does not resolve storageName automatically and prompts me to confirm it:
I believe this prompt is unexpected. storageName should be resolved automatically. I press Enter to confirm. This parameter should be resolved automatically alter after all.
And it fails when I attempt to deploy this Bicep template from VSCode. Here is the error status message:
{
"status": "Failed",
"error": {
"code": "AccountNameInvalid",
"message": "[format('mystorage{0}', uniqueString(resourceGroup().id))] is not a valid storage account name. Storage account name must be between 3 and 24 characters in length and use numbers and lower-case letters only."
}
}
As far as I see, for some reason, the storageName parameter was not resolved into an actual string (see the last line of the output). So it's expected that ARM does not let my deploy this template.
Get-AzResourceGroupDeployment -ResourceGroupName VSCodeBicepTest-RG -Name MyTestDeployment-FAILS
DeploymentName : MyTestDeployment-FAILS
ResourceGroupName : VSCodeBicepTest-RG
ProvisioningState : Failed
Timestamp : 19/01/2023 19:56:37
Mode : Incremental
TemplateLink :
Parameters :
Name Type Value
=============== ========================= ==========
location String "northeurope"
storageName String "[format('mystorage{0}', uniqueString(resourceGroup().id))]"
Works fine from PowerShell
Everything seems to be fine when I deploy the template from PowerShell. The deployment has succeeded:
New-AzResourceGroupDeployment -Name MyTestDeployment-SUCCEEDS -ResourceGroupName VSCodeBicepTest-RG -TemplateFile ./sample-template.bicep
DeploymentName : MyTestDeployment-SUCCEEDS
ResourceGroupName : VSCodeBicepTest-RG
ProvisioningState : Succeeded
Timestamp : 19/01/2023 19:56:16
Mode : Incremental
TemplateLink :
Parameters :
Name Type Value
=============== ========================= ==========
location String "northeurope"
storageName String "mystoragedcgcd6nvj5tje"
As you may see, the storageName parameter was correctly resolved into the string mystoragedcgcd6nvj5tje. That's expected.
Right now, I don't know why this is happening, but it looks like a bug in the Bicep extension for VSCode.
VSCode 1.74.3 (Universal) on MacOS,
Bicep extension v0.13.1.

This appears to be a known bug. As a workaround, you may wrap your interpolated parameters with string().
E.g., change this:
param storageName string = 'mystorage${uniqueString(resourceGroup().id)}'
To this:
param storageName string = string('mystorage${uniqueString(resourceGroup().id)}')

Related

checkov custom policy to scan variables

I'm writing a custom policy in checkov in yaml format. For demo purpose I created a policy which will check the name of storage account and throws error if it has non-alphanumeric characters. My policy file is :
metadata:
name: "Ensure that storage account has no special characters"
category: "convention"
id: "SCV_VARIABLE_01"
definition:
resource_types:
- "azurerm_storage_account"
attribute: "name"
operator: regex_match
value: "^[a-z0-9]{3,24}$"
my variable.tf
variable "storage_account_name"{
type = string
default = "test-12324-$"
}
my main.tf will look like:
resource "azurerm_storage_account" "storage_account" {
name = var.storage_account_name
resource_group_name = var.resource_group_name
location = var.location
}
I created a policy folder and kept my policy-file.yaml only in it. policy folder is in $PWD location. All tf files are also in $PWD location.
If I execute checkov docker command:
docker run -t -v $PWD:/tf bridgecrew/checkov -d /tf --external-checks-dir /tf/policy
checkov internal policy "CKV_AZURE_43" is able to catch that my variable has some special characters and show it as Failed but my custom policy is Passed.
If I directly keep storage account name in main.tf then my custom policy is throwing error and working as expected.
Could you tell me what to specify in my custom policy file to throw error when I pass wrong variable value?
thanks,
Santosh
Ignore my question. Checkov indeed checks the variable values like CKV_AZURE_43. I have misconfigured the custom policy yaml earlier. "cond_type:" is mandatory in custom yaml to give correct output.

Azure SQL Database ARM - Parameter 'maxSizeBytes' must be of type 'int'

When downloading a template through Azure Portal for creating a new SQL Database with Basic tier and a new SQL Server you get a parameter called 'maxSizeBytes'. Using this template and parameters with a Azure Resource Group project in Visual Studio you get the error below:
Parameter 'maxSizeBytes' must be of type 'int'
Given that a int32 max value is 2,147,483,647 I tried to use one less byte. Validation then passed but I got an error during deploy instead:
InvalidMaxSizeTierCombination: The tier 'Basic' does not support the
database max size '2147483647'.
In your template.json change maxSizeBytes type to string instead of int.
"maxSizeBytes": {
"type": "string"
},
In parameters.json change int value to a string:
"maxSizeBytes": {
"value": "2147483648"
},
Then it worked for me:
Given that the template was downloaded raw from Azure I think it is weird this has to be done in the first place.
I think its an Visual Studio bug. Try deploying with PowerShell (Az Module) and use the size: 2147483648
New-AzResourceGroupDeployment -ResourceGroupName <resource-group-name> -TemplateFile <path-to-template> -TemplateParameterFile <path-to-parameterfile>
The size needs to be 100MB, 500MB, 1GB or 2GB when using Basic SKU
If it works deploying using PowerShell without modifying the DataType then it proves that it is a Visual Studio bug.

Template parameter override not work if deploy template from storage?

I want to deploy my ARM template from storage blob. Following is what I did:
1. Upload the template file template.json and parameter file paramter.json to blob
In the parameter file I defined a parameter with empty value:
"environment": {
"value":""
}
2. Run following powershell script to deploy template and override the parameter:
New-AzureRmResourceGroupDeployment -ResourceGroupName myResourceGroup
-TemplateUri $templateUri
-TemplateParameterUri $parameterUri
-environment "Test"
But per the template output, the actual environment value is empty.
It is interesting that, if I deploy the template from local file with TemplateFile and TemplateParameterFile, than it works well.
Anyone knows what's wrong in my code?
I dont think anything is wrong with your code, its just this cmdlet is coded in such a fashion that you cannot override parameters that are set in the parameters file if you supply parameters file from the URI, unfortunately.

Function App keys noting being created for new Function App

I'm deploying a Storage Account and Function App via an ARM template, but after a successful deployment, I'm unable to use the the Function App because no keys are being created.
We are not able to retrieve the runtime master key. Please try again later.
From what I understand (see this issue on GitHub), there should be a folder created in the associated Storage Accont that contains hosts.json: storage-account/azure-webjobs-secrets/function-app. However, this folder does not exist.
I was hoping that upon deployment of a Function, hosts.json would be created. I believe there should also be a file named FunctionName.json that contains Function specific keys, but still the aforementioned folder does not exist and neither does this file. This leads to an additional error being displayed.
We are not able to retrieve the keys for function FunctionName. This can happen if the runtime is not able to load your function. Check other function errors.
Just in case anyone from MS picks this up, both errors should hopefully be recorded under Session ID a814072a75d643d89c71d64d20c3dd55.
Is there some bug with Function App deployment via an ARM template, or am I doing something wrong?
ARM Template
Can be found in this Pastebin
Example output
DeploymentName : DEV-FunctionAppName
ResourceGroupName : a-resourece-group
ProvisioningState : Succeeded
Timestamp : 02/10/2017 10:30:28
Mode : Incremental
TemplateLink :
Parameters :
Name Type Value
=============== ========================= ==========
environment String DEV
environmentSettings Object {
"applicationInsightsName": "service-name-app-insights",
"functionAppName": "DEV-FunctionAppName",
"storageAccountName": "servicenamedevstorene"
}
serviceName String Service Name
location String northeurope
serverFarmName String NorthEuropePlan
storageAccountSku Object {
"name": "Standard_GRS",
"tier": "Standard"
}
tags Object {
"Application": "Service Name",
"Environment": "DEV"
}
Outputs :
DeploymentDebugLogLevel :

Should the Register-AzureRmAutomationDscNode cmdlet function identically to the Azure portal functionality?

We are seeing an issue with Register-AzureRmAutomationDscNode and are wondering if it is not working as expected or if our understanding of what it is supposed to do is incorrect.
When we onboard an Azure VM as an Azure Automation DSC node via the portal, everything works as expected. The VM is onboarded and the configuration is applied.
When we attempt to do the same via Register-AzureRmAutomationDscNode, the cmdlet appears to succeed, but the VM never appears as a DSC node in the portal or via the Get-AzureRmAutomationDscNode command.
We have verified the parameters we are passing via the UI in the portal and via the cmdlet are identical. In both cases, we also see a successful deployment on the VM with identical input and outputs.
The output from the cmdlet is:
DeploymentName : 20170825085614
ResourceGroupName : 36ddce91
ProvisioningState : Succeeded
Timestamp : 8/25/2017 2:57:17 PM
Mode : Incremental
TemplateLink :
Uri : https://eus2oaasibizamarketprod1.blob.core.windows.net/automationdscpreview/azuredeployV2.json
ContentVersion : 1.0.0.0
Parameters :
Name Type Value
=============== ========================= ==========
vmName String Windows-VM
location String East US
modulesUrl String https://eus2oaasibizamarketprod1.blob.core.windows.net/automationdscpreview/RegistrationMetaConfigV2.zip
configurationFunction String RegistrationMetaConfigV2.ps1\RegistrationMetaConfigV2
registrationKey SecureString
registrationUrl String https://eus2-agentservice-prod-1.azure-automation.net/accounts/8b6a1713-dc00-4ae1-a513-c582def16380
nodeConfigurationName String RemoteManagement.36ddce91
configurationMode String ApplyAndMonitor
configurationModeFrequencyMins Int 15
refreshFrequencyMins Int 30
rebootNodeIfNeeded Bool True
actionAfterReboot String ContinueConfiguration
allowModuleOverwrite Bool True
timestamp String 8/25/2017 2:56:14 PM
Outputs :
DeploymentDebugLogLevel :
Is there an issue with Register-AzureRmAutomationDscNode or does onboarding a VM via the portal perform additional actions that are not covered by Register-AzureRmAutomationDscNode?

Resources