Import-AzBluePrintwithartifact fails if no subscription is available in Az context
artisticcheese opened this issue · comments
Please see following issue opened since March 2020
Azure/azure-powershell#11245
In case Az context does not contain subscription this cmdlet will throw Import-AzBlueprintWithArtifact: Object reference not set to an instance of an object.
upon attempt to upload blueprint.
This happens when service principal does not have direct Role Assignment on subscription level but have inherited assignment through management group. In this case Connect-AzAccount does not populate subscription info
Repro
Connect-AzAccount -ServicePrincipal -Credential $credentials -Tenant 65e4e06f-f263-4c1f-becb-90deb8c2d9ff
WARNING: The provided service principal secret will be included in the 'AzureRmContext.json' file found in the user profile ( C:\Users\artis\.Azure ). Please ensure that this directory has appropriate protections.
Account SubscriptionName TenantId Environment
------- ---------------- -------- -----------
eccf917e-14e5-4493-b2b7-808444e4e890 65e4e06f-f263-4c1f-becb-90deb8c2d9ff AzureCloud
PS C:\repo\DSO\DSO\DSO> Import-AzBlueprintWithArtifact -Name $env:BPNAME -InputPath "$($env:SYSTEM_DEFAULTWORKINGDIRECTORY)$($env:BLUEPRINTLOCATION)" -Force -ManagementGroupID $env:MANAGEMENTGROUPID
Import-AzBlueprintWithArtifact: Object reference not set to an instance of an object.
Would you say the issue is with Connect-AzAccount
or with Import-AzBlueprintWithArtifact
?
I would say issue with Import-AzBlueprintArtifact since if there are no subscriptions inside MG you still shall be able to deploy artifact to MG
Do you know if -Whatif
will ever be implemented properly for blueprints? I imagine that information shall be available if all ARM artifacts are rung with -Whatif
on backplane.
Given the planned migration from blueprints to templateSpecs and deployment stacks, we won't be implementing what-if for the current blueprint APIs. WhatIf already works for templateSpec-based deployments and it will also be supported for stacks.
Is the SPN/context issue blocking? or is it possible to give limited access to a sub as a workaround? The reason I ask is because given the migration, this is a fix we'd like to avoid if possible.
It's not blocking, just as you can see several people run into that. Proving IAM permissions is sufficient to workaround.