Error on or near line 216: the current account must have Owner privilege on the subscription to deploy launchpad.; exiting with status 2
I am running into an issue with lower level state. The scenario is I have an application_gateway that is deployed at level3 and I am trying to refer to a certificate in kv_secrets KeyVault. The configuration snippet in the gateway looks like:
trusted_root_certificate = {
wildcard_ingress = {
lz_key = "launchpad"
keyvault_key = "secrets"
name = "appgateway"
}
}
and the level3 landingzone is configured like:
landingzone = {
backend_type = "azurerm"
level = "level3"
key = "cluster_aks"
global_settings_key = "shared_services"
tfstates = {
shared_services = {
level = "lower"
tfstate = "caf_shared_services.tfstate"
}
networking_hub = {
level = "lower"
tfstate = "networking_hub.tfstate"
}
launchpad = {
level = "lower"
tfstate = "caf_launchpad.tfstate"
}
}
}
When I try to run plan on Level3 I get the following error:
│ on /home/vscode/.terraform.cache/modules/solution/modules/networking/application_gateway/application_gateway.tf line 17, in data "azurerm_key_vault_certificate" "trustedcas":
│ 17: key_vault_id = var.keyvaults[try(each.value.lz_key, var.client_config.landingzone_key)][each.value.keyvault_key].id
│ ├────────────────
│ │ each.value.keyvault_key is "secrets"
│ │ each.value.lz_key is "launchpad"
│ │ var.client_config.landingzone_key is "cluster_aks"
│ │ var.keyvaults is object with 4 attributes
│
│ The given key does not identify an element in this collection value.
Through some creative coding I was able to dump out the value of var.keyvaults and it looks like the merge of the keyvaults from the lower tfstates results in empty dictionaries, e.g.
"cluster_aks": {}
"launchpad": {}
"networking_hub": {}
"shared_services": {}
I'm not 100% confident I am looking at the correct dump of the data structure but the error seems to indicate so. var.keyvaults["launchpad"]["secrets"] should be resolving but it is not.
Any thoughts?
landingzone = {
backend_type = "azurerm"
global_settings_key = "launchpad"
level = "level1"
key = "caf_foundations"
tfstates = {
// Remote tfstate to retrieve default location and log analytics workspace
#caf_foundations_sharedservices = {
# level = "current"
# tfstate = "caf_foundations_sharedservices.tfstate"
#}
caf_foundations_enterprise_scale = {
level = "current"
tfstate = "caf_foundations.tfstate"
}
// Remote tfstate to retrieve the MSI created by the launchpad and set permissions on the MG hierarchy
// Requires scenarion 200 to get access to Log Analytics key 'central_logs_region1'
launchpad = {
level = "lower"
tfstate = "caf_launchpad.tfstate"
}
}
}
Hi I have Created vnet in level2 networking-hub and now i want to use this vnet for my virtual machines i want to create in level3 solutions for this when i provide the vnet key getting an error
I'm new to landing zones is it possible to use virtual network created at level2 can be used in leve3 deployments.
@mohsinaliariz_gitlab you need to define the "lower" level tf state and use the lz_key from it.
"landingzone = {
backend_type = "azurerm"
global_settings_key = "shared_services"
level = "level3"
key = "solutions"
tfstates = {
shared_services = {
level = "lower"
tfstate = "sharedservices.tfstate"
}
networking_spoke = {
level = "lower"
tfstate = "networking.tfstate"
}
}
} "
I am completely stuck and hoping someone can help. I have a shared image gallery in a different subscription not deployed via LandingZone. I need to reference this shared image gallery and its images in my single_linux_vm.tfvar file. I have tried different things like storage_image_reference or azurerm_shared_image references but nothing seems to be working. Can anyone point me in the right direction what I can look at to build a linux image from a pre-existing shared image gallery hosted in the same tenant but different subscription?
Any help on this would be appreciated. I see an issue from September 9th, 2020 where a feature "Add support to create VM from image gallery" is listed but not checked. Can anyone shed some light on this? aztfmod/terraform-azurerm-caf#4
I am running into something similar as @sukhi25. If i change my "networking" CAF module version from "~>5.2.0" to "~>5.3.0" my vnet creation fails with the following error:
'''
Error: Missing required argument
on /home/vscode/.terraform.cache/modules/landingzones_shared_services/modules/azuread/groups/group.tf line 1, in resource "azuread_group" "group":
1: resource "azuread_group" "group" {
The argument "name" is required, but no definition was found.
Error: Unsupported argument
on /home/vscode/.terraform.cache/modules/landingzones_shared_services/modules/azuread/groups/group.tf line 3, in resource "azuread_group" "group":
3: display_name = var.global_settings.passthrough ? format("%s", var.azuread_groups.name) : format("%s%s", try(format("%s-", var.global_settings.prefixes.0), ""), var.azuread_groups.name)
An argument named "display_name" is not expected here.
'''
I'm having an issue with setting up a bootstrap service principal and the main issue is if the secret is changed. It seems as though the secret is cached somewhere within rover.
The following gist shows what I'm doing - https://gist.github.com/pmatthews05/77c2b79a8b2630e814216eadadcce073
On a brand new instance of Rover (aztfmod/rover:0.15.4-2105.2603) calling those lines of code, it logs in correct using az login --service-principal, and when Rover is called it logs in correctly with the Service Principal.
If I change the secret in Azure AD, run the gist code again with the updated secret. It can login to az with service principal without any issues, but when it login inside rover, it first shows "Resources from this landing zone are going to be deployed in the following subscription:" which shows the service principal in the user section. But after Initializing az cloud variables it says secret is invalid.
"ERROR: AADSTS7000215: Invalid client secret is provided.
Trace ID: 177140d2-33fe-42e6-a169-b8a7b0d11600
Correlation ID: b6b0a0c3-8cf2-46bc-8d13-b628d4ce3f80
Timestamp: 2021-06-10 09:27:20Z
To re-authenticate, please run az login
. If the problem persists, please contact your tenant administrator.
Logged in rover app object_id: "
They only way I can stop this from happening is removing the entire rover image from my machine, downloading it again and running.
We don't want our VM names to use the global prefix as this causes a lot of headache with the 15 character netbios limit for windows names I.E if we want a VM to be called vm-appx01-uks then if the prefix is 5 characters, it pushes the name over the limit and causes mismatches and weird issues with some having the prefix and some not.
The only solution I've found so far is to take a local copy of the main aztfmod https://github.com/aztfmod/terraform-azurerm-caf and comment out the prefixes variable under the compute/vm modules then set my landingzone module source to the local copy rather than the MS maintained github repo.
Am I missing something obvious? Is there a way to opt out of using a prefix for certain resources (particulary those with character limits)?
Good afternoon, so have just onboarded a new Application Gateway, and now have a requirement for health probes and header re-writes, however it looks like the application gateway module is only partially completed??? /modules/networking/application_gateway/application_gateway.tf:
dynamic "backend_http_settings" {
for_each = local.backend_http_settings
content {
name = var.application_gateway_applications[backend_http_settings.key].name
cookie_based_affinity = try(backend_http_settings.value.cookie_based_affinity, "Disabled")
port = backend_http_settings.value.port
protocol = backend_http_settings.value.protocol
request_timeout = try(backend_http_settings.value.request_timeout, 30)
pick_host_name_from_backend_address = try(backend_http_settings.value.pick_host_name_from_backend_address, false)
trusted_root_certificate_names = try(backend_http_settings.value.trusted_root_certificate_names, null)
}
}
There's no probe_name or host_name....
In addition there's no probe block, and several other blocks are missing from the actual resource....
Any plans to complete this or should I just use the resource itself you reckon?
There's some blocks rem'd out probably in a to-do list eh:
I have an Application that was created in level 0
azuread_apps = {
# Do not rename the key "launchpad" to be able to upgrade to the standard launchpad
caf_launchpad_level0 = {
useprefix = true
application_name = "caf_launchpad_level0"
password_expire_in_days = 180
# Store the ${secret_prefix}-client-id, ${secret_prefix}-client-secret...
# Set the policy during the creation process of the launchpad
keyvaults = {
level0 = {
secret_prefix = "aadapp-caf-launchpad-level0"
}
}
}
}
If in Level0 I want grant access to a keyvault with this app I can put in the following
keyvault_access_policies_azuread_apps = {
level0 = {
caf_launchpad_level0 = {
# Reference a key to an azure ad applications
azuread_app_key = "caf_launchpad_level0"
secret_permissions = ["Set", "Get", "List", "Delete", "Purge", "Recover"]
}
}
}
How do I grant this same app access to a keyvault in level1? I've attempted to follow examples like the MSI's and AD Groups, but I keep getting null errors.
keyvault_access_policies_azuread_apps = {
bastion = {
caf_launchpad_level0 = {
lz_key = "launchpad"
azuread_app_key = "caf_launchpad_level0"
secret_permissions = ["Set", "Get", "List", "Delete", "Purge", "Recover"]
}
}
}