Bicep api management multiple products - azure

I'm creating a api managment using bicep files, but when i try to create a products it works only when i created just one in the template. Is there somehow a way to create multiple products related with api management, below is the sample approch
resource apim 'Microsoft.ApiManagement/service#2021-08-01' existing = {
name: 'apim'
}
resource lambdaStoreApi 'Microsoft.ApiManagement/service/apis#2020-12-01' = {
name: 'api'
parent: apim
properties:{
format: 'swagger-json'
value: loadTextContent('./swagger.json')
path: 'path'
}
}
resource product1 'Microsoft.ApiManagement/service/products#2020-12-01' = {
name: '${apim.name}/product1'
properties: {
displayName: 'displayName'
description: 'description'
subscriptionRequired: true
approvalRequired: false
state: 'published'
}
}
resource product2 'Microsoft.ApiManagement/service/products#2020-12-01' = {
name: '${apim.name}/product2'
properties: {
displayName: 'displayName'
description: 'description'
subscriptionRequired: true
approvalRequired: false
state: 'published'
}
}
I am getting error "Product with the same name already exists", but only if I try with more than 1 product.
Is there some way to create with more than one product?

Looking at the documentation:
displayName: Product name. string (required).
The displayName (product name) also have to be unique. You just need to give this property a unique value:
resource product1 'Microsoft.ApiManagement/service/products#2020-12-01' = {
name: '${apim.name}/product1'
properties: {
displayName: 'product1'
...
}
}
resource product2 'Microsoft.ApiManagement/service/products#2020-12-01' = {
name: '${apim.name}/product2'
properties: {
displayName: 'product2'
...
}
}

Related

Deploy Logic App (Std) Workflow Disabled with Bicep/YAML

I have tried numerous methods and the workflow is still deployed enabled.
My latest attempt was to use the resource in my bicep:
resource workflow 'Microsoft.Web/sites/workflows#2015-08-01' = {
name: workflowName
dependsOn: [ logicContainer ]
location: location
kind: 'Stateful'
properties: {
flowstate: 2
}
}
However, the workflow never appears in the Logic App function.
I cannot even deploy the container in the 'Stopped' state, since for Microsoft.Web/sites#2022-03-01, state is readonly.
In my yaml I send a the workflows in a pipe separated string e.g. "wf-one|wf-two|wf-three|wf-four"
Then, in my bicep I populate an array of Workflow states app settings:
var wfAppSettingStatuses = [ for wf in split(workflows,'|'): {
name: 'Workflows.${wf}.FlowState'
value: 'Disabled'
}]
To add to the Logic App container configuration settings use the union function:
resource logicContainer 'Microsoft.Web/sites#2022-03-01' = {
name: appName
location: location
kind: 'functionapp,workflowapp'
identity: {
type: 'SystemAssigned'
}
properties: {
httpsOnly: true
siteConfig: {
appSettings: union(wfAppSettingStatuses, [
{
name: 'APPINSIGHTS_INSTRUMENTATIONKEY'
value: applicationInsights.properties.InstrumentationKey
}
...
])
use32BitWorkerProcess: true
}
serverFarmId: planId
clientAffinityEnabled: false
vnetRouteAllEnabled: true
storageAccountRequired: false
keyVaultReferenceIdentity: 'SystemAssigned'
}
}
Each workflow in the list is now disabled, therefore if you require one to be enabled on deployment, remove it from the pipe delimited string.

Can I deploy an event trigger to Function App via Bicep?

I aim to create such a bicep file that would deploy a function app with an event trigger in it, however, I'm not sure if it's possible. I've tried googling but Function App deployment via bicep tutorials tend to stop right after the deployment of an empty function app. I need to go a step further and add triggers to it.
Why do I want to deploy at least an empty event trigger via bicep?
The core of the issue is: I would like to perform two stages of CD, where the first one will be all about bicep (preparing all of the resources) and the second one about code deployment.
However, at the first CD stage, the following error occurs:
{"code":"Endpoint validation","message":"Destination endpoint not
found. Resource details: resourceId:
/subscriptions/.../functionAppNameHere/functions/eventTriggerFuncName.
Resource should pre-exist before attempting this operation.}
I assume that EventGrid EventSubscriptions requires prior presence of a resource with the trigger (seems understandable though).
Is it even possible to add an event trigger via bicep so it would move smoothly to event subscription creation? If yes: can you please give me some tips?, if no: do you have any ideas on how to circumvent this?
Here are my bicep files that may come in handy when thinking about the issue:
main.bicep
module azStorageAccount 'modules/azStorageAccount.bicep'= {
name: '${deployName}-st'
params: {
location: location
name: '${stNamePrefix}${resourceSuffix}'
}
}
module azAppInsights 'modules/azAppInsights.bicep' = {
name: '${deployName}-appi'
params: {
location: location
name: '${appiNamePrefix}${resourceSuffix}'
}
}
module azHostingPlan 'modules/azHostingPlan.bicep' = {
name: '${deployName}-asp'
params: {
location: location
name: '${aspNamePrefix}${resourceSuffix}'
}
}
module azFunctionApp 'modules/azFunctionApp.bicep' = {
name: '${deployName}-func'
params: {
storageId:azStorageAccount.outputs.storageId
storageName: azStorageAccount.outputs.storageName
azAppInsightsInstrumentationKey: azAppInsights.outputs.azAppInsightsInstrumentationKey
location: location
name: '${funcNamePrefix}${resourceSuffix}'
serverFarmId: azHostingPlan.outputs.azHostingPlaniD
}
}
module azEventGrid 'modules/azEventGrid.bicep' = {
name: '${deployName}-evg'
params: {
subscription: subscription
evgtName: '${evgtNamePrefix}${resourceSuffix}'
evgsName: '${evgsNamePrefix}${resourceSuffix}'
resourceId: '/subscriptions/${subscription}/resourceGroups/${resourceGroup}/providers/Microsoft.Web/sites/${funcNamePrefix}${resourceSuffix}/functions/${eventFunction}'
}
}
modules/azFunctionApp
// params here
resource azFunctionApp 'Microsoft.Web/sites#2021-03-01' = {
name: name
kind: kind
location: location
identity: {
type: 'SystemAssigned'
}
properties: {
httpsOnly: true
serverFarmId: serverFarmId
clientAffinityEnabled: true
reserved: true
siteConfig: {
appSettings: [
{
name: 'FUNCTIONS_EXTENSION_VERSION'
value: '~3'
}
// more settings here
]
alwaysOn: false
}
}
}
modules/azEventGrid
// params here
resource azEventGridSystemTopic 'Microsoft.EventGrid/systemTopics#2022-06-15' = {
name: evgtName
location: 'global'
tags: {
// tags
}
properties: {
source: '/subscriptions/${subscription}'
topicType: 'Microsoft.Resources.Subscriptions'
}
}
resource azEventGridEventSubscriptions 'Microsoft.EventGrid/systemTopics/eventSubscriptions#2022-06-15' = {
parent: azEventGridSystemTopic
name: evgsName
properties: {
destination: {
properties: {
resourceId: resourceId
maxEventsPerBatch: 1
preferredBatchSizeInKilobytes: 64
}
endpointType: 'AzureFunction'
}
filter: {
includedEventTypes: [
'Microsoft.Resources.ResourceWriteSuccess'
'Microsoft.Resources.ResourceDeleteSuccess'
]
enableAdvancedFilteringOnArrays: true
}
labels: []
eventDeliverySchema: 'EventGridSchema'
retryPolicy: {
maxDeliveryAttempts: 30
eventTimeToLiveInMinutes: 1440
}
}
}

How to show the path of the script of the Azure runbook in Bicep?

I am want to deploy an Azure Automation Account runbook with Bicep with below code:
resource automationAccount 'Microsoft.Automation/automationAccounts#2019-06-01' = {
name: 'name'
}
resource automationRunbook 'Microsoft.Automation/automationAccounts/runbooks#2019-06-01' = {
parent: automationAccount
name: 'name'
location: 'westeurope'
properties: {
logVerbose: true
logProgress: true
runbookType: 'Script'
publishContentLink: {
uri: 'uri'
version: '1.0.0.0'
}
description: 'description'
}
}
I want to use a runbook which is on my Azure Repos. Can I use a relative path such as ../scripts/runbook.ps1 as I do in Powershell? I see that there isn't any property for that but I am asking if I miss anything.
As explained here, you may leverage 'uri' property.
To use a relative path, you may leverage parameter section and variable section. Something like:
param runbooksUri string = 'https://xxxxxxxxxxxxxxxx/xxxxx/xxxxx/'
var testScripts = {
testrunbooks: [
{
name: 'XXXXXXX'
url: uri(runbooksUri, 'xxxxxxx.ps1')
}
{
name: 'YYYYYYY'
url: uri(runbooksUri, 'yyyyyyy.ps1')
}
]
}
resource automationRunbook 'Microsoft.Automation/automationAccounts/runbooks#2019-06-01' = [for i in range(0, length(testScripts.testrunbooks)): {
xxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxx
properties: {
publishContentLink: {
uri: testScripts.testrunbooks[i].url
xxxxxxxxxxxxxxxxxxxxxxxxx
}
}
xxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxx
}]

Azure Bicep script produces error "Changing property > 'agentPoolProfile.vnetSubnetID' is not allowed." on second execution

I'm using Azure Bicep to create a virtualNetwork with a single subnet and then use that as the input for creating an aks cluster with : vnetSubnetID: virtualNetwork.properties.subnets[0].id
The first time I run the command, it creates the virtual network and cluster just fine, but the second time I run the command it gives this error :
{"error":{"code":"InvalidTemplateDeployment","message":"The template
deployment 'cluster' is not valid according to the validation
procedure. The tracking id is '[REDACTED_JUST_IN_CASE]'. See inner errors for
details.","details":[{"code":"PropertyChangeNotAllowed","message":"Provisioning
of resource(s) for container service playground-cluster0 in resource
group showcase-kevinplayground2 failed. Message: {\n "code":
"PropertyChangeNotAllowed",\n "message": "Changing property
'agentPoolProfile.vnetSubnetID' is not allowed.",\n "target":
"agentPoolProfile.vnetSubnetID"\n }. Details: "}]}}
I double checked and there is just the one subnet inside the virtualNetwork created by the deployment (no other magically appeared or anything).
I repeated the experiment on a second resource group and the same thing happened, so it's reproducible.
Here is the full bicep file (just call az deployment group create --resource-group showcase-kevinplayground2 -f cluster.bicep in the resource group of your choice)
targetScope = 'resourceGroup'
resource virtualNetwork 'Microsoft.Network/virtualNetworks#2021-02-01' = {
name: 'aksVirtualNetwork'
location: resourceGroup().location
properties:{
addressSpace:{
addressPrefixes:[
'10.10.0.0/16'
]
}
subnets:[
{
name: 'aks'
properties:{
addressPrefix: '10.10.5.0/24'
}
}
]
}
}
resource aksManagedIdentity 'Microsoft.ManagedIdentity/userAssignedIdentities#2018-11-30' = {
name: 'playgroundIdentity'
location: resourceGroup().location
}
resource aks 'Microsoft.ContainerService/managedClusters#2021-02-01' = {
name: 'playground-cluster0'
location: resourceGroup().location
identity: {
type:'UserAssigned'
userAssignedIdentities: {
'${aksManagedIdentity.id}': {}
}
}
sku: {
name: 'Basic'
tier: 'Free'
}
properties: {
kubernetesVersion: '1.21.2'
dnsPrefix: 'playground'
enableRBAC: true
networkProfile: {
networkPlugin: 'azure'
networkPolicy: 'calico'
}
aadProfile: {
managed: true
enableAzureRBAC: true
}
autoUpgradeProfile: {}
apiServerAccessProfile: {
enablePrivateCluster: false
}
agentPoolProfiles: [
{
name: 'aksnodes'
count: 1
vmSize: 'Standard_B2s'
osDiskSizeGB: 30
osDiskType: 'Managed'
vnetSubnetID: virtualNetwork.properties.subnets[0].id
osType: 'Linux'
maxCount: 1
minCount: 1
enableAutoScaling: true
type: 'VirtualMachineScaleSets'
mode: 'System'
orchestratorVersion: null
}
]
}
}
Looking at this reported github issue, you need to use the resourceId function.
In your case, something like that should work:
vnetSubnetID: resourceId('Microsoft.Network/virtualNetworks/subnets', 'aksVirtualNetwork', 'aks')

App Service Managed Identity and Key Vault the right way

I am currently trying to deploy out a resource group using azure bicep, however, I am running into an issue using key vault for my azure app service. I would like to know if I am actually doing this the correct way. I have a main bicep file that is along the lines of:
// params removed for brevity...
targetScope = 'subscription'
resource rg 'Microsoft.Resources/resourceGroups#2021-04-01' = {
name: 'rg-${appName}-${region}'
location: 'centralus'
}
module appServicePlan 'appplan.bicep' = {
params: {
sku: appServicePlanSku
appName: appName
region: region
}
scope: rg
name: 'AppServicePlanDeploy'
}
module keyVault 'keyvault.bicep' = {
params: {
keyVaultName: keyVaultName
sqlPassword: sqlServerPassword
webSiteManagedId: webSite.outputs.webAppPrincipal
}
scope: rg
name: 'KeyVaultDeploy'
dependsOn: [
webSite
]
}
module ai 'ai.bicep' = {
scope: rg
name: 'ApplicationInsightsDeploy'
params: {
name: appName
region: region
keyVaultName: keyVault.outputs.keyVaultName
}
dependsOn: [
keyVault
]
}
resource kv 'Microsoft.KeyVault/vaults#2019-09-01' existing = {
name: keyVaultName
scope: rg
}
module sql 'sqlserver.bicep' = {
scope: rg
name: 'SQLServerDeploy'
params: {
appName: appName
region: region
sqlPassword: kv.getSecret('sqlPassword')
sqlCapacitity: sqlCapacitity
sqlSku: sqlSku
sqlTier: sqlTier
}
dependsOn: [
keyVault
]
}
module webSite 'site.bicep' = {
params: {
appName: appName
region: region
keyVaultName: keyVaultName
serverFarmId: appServicePlan.outputs.appServicePlanId
}
scope: rg
name: 'AppServiceDeploy'
dependsOn: [
appServicePlan
]
}
My question comes with the implementation of the site.bicep, I started off by passing the secret uri from exported variables and creating the web app last as app insights, sql, etc... all need to be setup and in keyvault before we use their exported secret uri to construct a config. I had something along the lines of:
site.bicep (before):
properties: {
serverFarmId: serverFarmId
keyVaultReferenceIdentity: userAssignedId
siteConfig: {
appSettings: [
{
name: 'APPLICATIONINSIGHTS_CONNECTION_STRING'
value: '#Microsoft.KeyVault(SecretUri=${appInsightsConnectionString})'
}
{
name: 'APPINSIGHTS_INSTRUMENTATIONKEY'
value: '#Microsoft.KeyVault(SecretUri=${appInsightsKey})'
}
]
netFrameworkVersion: 'v5.0'
}
}
The only problem with this implementation is that the key vault MUST be constructed before the website because sql, ai, and the other services will store their values inside of the key vault for the web app to consume by their respective uris. The issue with this is that the KeyVault rightfully so has no idea which azure service to let access it's keys.
My question is the solution of constructing the web app before the key vault the only way to beat this problem? I am using managed identities on the web app and would like to continue doing so if possible. My final solution ended up somewhat like this:
site.bicep (final)
// params removed for brevity...
resource webApplication 'Microsoft.Web/sites#2020-12-01' = {
name: 'app-${appName}-${region}'
location: resourceGroup().location
tags: {
'hidden-related:${resourceGroup().id}/providers/Microsoft.Web/serverfarms/appServicePlan': 'Resource'
}
identity: {
type: 'SystemAssigned'
}
properties: {
serverFarmId: serverFarmId
siteConfig: {
appSettings: [
{
name: 'APPLICATIONINSIGHTS_CONNECTION_STRING'
value: '#Microsoft.KeyVault(SecretUri=${keyVaultName}.vault.azure.net/secrets/aiConnectionString)'
}
{
name: 'APPINSIGHTS_INSTRUMENTATIONKEY'
value: '#Microsoft.KeyVault(SecretUri=${keyVaultName}.vault.azure.net/secrets/aiInstrumentationKey)'
}
{
name: 'AngularConfig:ApplicationInsightsKey'
value: '#Microsoft.KeyVault(SecretUri=${keyVaultName}.vault.azure.net/secrets/aiInstrumentationKey)'
}
]
netFrameworkVersion: 'v5.0'
}
}
}
output webAppPrincipal string = webApplication.identity.principalId
And the KeyVault which will take a dependsOn webSite
keyVault.bicep(final):
resource keyVault 'Microsoft.KeyVault/vaults#2019-09-01' = {
name: keyVaultName
location: resourceGroup().location
properties: {
enabledForDeployment: true
enabledForTemplateDeployment: true
enabledForDiskEncryption: true
enableRbacAuthorization: true
tenantId: subscription().tenantId
sku: {
name: 'standard'
family: 'A'
}
accessPolicies: [
{
tenantId: subscription().tenantId
objectId: webSiteManagedId
permissions: {
keys: [
'get'
]
secrets: [
'list'
'get'
]
}
}
]
}
}
Just treat your accessPolicies as separate resource and add them when both Key Vault and App Service are created. Same applies for Config section and Connection Strings. Check documentation here.
In ARM templates you can achieve same effect using nested templates. In Bicep it is kind the same, but you declare them as separate resource that usually contains parent name (e.g. name: '${kv.name}/add', name: '${webSite.name}/connectionstrings')
Sample
Step 1: Create an App Service without config section
resource webSite 'Microsoft.Web/sites#2020-12-01' = {
name: webSiteName
location: location
properties: {
serverFarmId: hostingPlan.id
siteConfig:{
netFrameworkVersion: 'v5.0'
}
}
identity: {
type:'SystemAssigned'
}
}
Step 2: Create Key Vault without access policies
resource kv 'Microsoft.KeyVault/vaults#2019-09-01' = {
name: keyVaultName
location: location
properties:{
sku:{
family: 'A'
name: 'standard'
}
tenantId: tenantId
enabledForTemplateDeployment: true
accessPolicies:[
]
}
}
Step 3: Create new access policy and reference Web Apps Managed Identity
resource keyVaultAccessPolicy 'Microsoft.KeyVault/vaults/accessPolicies#2021-06-01-preview' = {
name: '${kv.name}/add'
properties: {
accessPolicies: [
{
tenantId: tenantId
objectId: webSite.identity.principalId
permissions: {
keys: [
'get'
]
secrets: [
'list'
'get'
]
}
}
]
}
}
Step 4: Update Webb app config section
resource webSiteConnectionStrings 'Microsoft.Web/sites/config#2020-06-01' = {
name: '${webSite.name}/connectionstrings'
properties: {
DefaultConnection: {
value: '#Microsoft.KeyVault(SecretUri=${keyVaultName}.vault.azure.net/secrets/aiConnectionString)'
type: 'SQLAzure'
}
}
}
One solution could be to use User Assigend Identity instead of System Assigned. Then you would deploy the following:
Deploy a user assigend identity
Key Vault and assign permissions for user assigned identity
Deploy web app with user assigned identity and read / write secrets
User assigned is independent of the resources and so you avoid your chicken and egg problem.
More:
https://learn.microsoft.com/en-us/azure/templates/microsoft.managedidentity/userassignedidentities?tabs=bicep
https://learn.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/overview
You should split up three parts of your deployment into separate resources:
Deploy the Key Vault - without any access policies!
Deploy the App Service - with the SystemAssigned Identity, but without the app settings
Deploy the Key Vault Access Policy for the MSI
Deploy the App Settings

Resources