pulumi-azure-native
pulumi-azure-native copied to clipboard
Using Entra ID Only Auth and Updating causes a failure when Tag is incorrectly set
What happened?
We have turned Entra ID Only Auth on and then changed a Tag on the Azure SQL Server from the value that Pulumi sets.
This caused this error:
"AadOnlyAuthenticationIsEnabled" Message="Azure Active Directory Only Authentication is enabled. Please contact your system administrator."
Once the stack is in this state we are unable to get it refresh the value back, even if we manually update the tag to the correct value.
We are using version v2.14 of Azure Native and Pulumi v3.74.0
Example
var databaseServer = new Server(databasePulumiName, new ServerArgs
{
ServerName = args.Name,
Version = args.Version,
Location = args.Location,
ResourceGroupName = args.ResourceGroupName,
MinimalTlsVersion = "1.2",
PublicNetworkAccess = args.IsPrivateLinkEnabled ? ServerNetworkAccessFlag.Disabled : ServerNetworkAccessFlag.Enabled,
AdministratorLogin = args.AdminUserName,
AdministratorLoginPassword = adminUserPassword,
Administrators = new ServerExternalAdministratorArgs
{
AdministratorType = AdministratorType.ActiveDirectory,
PrincipalType = PrincipalType.Group,
AzureADOnlyAuthentication = args.EntraIdOnlyAuth,
Login = administratorArgs.Apply(x => x.AdministratorGroupName),
Sid = administratorArgs.Apply(x => x.AdministratorSid),
TenantId = administratorArgs.Apply(x => x.AdministratorTenantId)
},
Identity = new ResourceIdentityArgs { Type = IdentityType.SystemAssigned },
RestrictOutboundNetworkAccess = args.RestrictOutboundNetworkAccess ? ServerNetworkAccessFlag.Enabled : ServerNetworkAccessFlag.Disabled,
Tags = args.Tags,
}, sqlOptions);
Output of pulumi about
We are using version v2.14 of Azure Native and Pulumi v3.74.0, Pulumi Automation 3.55
CLI Version 3.91.0 Go Version go1.21.3 Go Compiler gc
Plugins NAME VERSION azure 5.41.0 azure-native 2.14.0 azuread 5.38.0 command 0.5.2 dotnet unknown kubernetes 3.30.0 random 4.13.2
Additional context
No response
Contributing
Vote on this issue by adding a 👍 reaction. To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already).
Hmm... It looks looks like what is happening is that we can't read the state of the resource because the AzureADOnlyAuthentication mode blocks reads from the user account that's running the refresh command. Some details that would be helpful for debugging:
What authentication method are you using for the refresh command? Is the account running the refresh on the administrator list for the database server?
Looks like you're passing the Login, Sid and TenantId from outside this code block. Are those also managed with Pulumi or are is the administrator group manage separately?
hmm... this issue on the Terraform provider could also be a hint: https://github.com/hashicorp/terraform-provider-azurerm/issues/14348 It looks like setting the
AdministratorLoginPassword while also setting AzureADOnlyAuthentication might be allowed when creating the resource, but rejected during an update.
What authentication method are you using for the refresh command? Is the account running the refresh on the administrator list for the database server?
We are using Managed Identity; we are using a Entra ID group for Administrators and have the Managed Identity included in the group. Why would it need Admin access to SQL to update the tags though?
Looks like you're passing the Login, Sid and TenantId from outside this code block. Are those also managed with Pulumi or are is the administrator group manage separately?
These values are passed into our Pulumi code via json files, this allows us to have different settings for production and test.
hmm... this issue on the Terraform provider could also be a hint: hashicorp/terraform-provider-azurerm#14348 It looks like setting the
AdministratorLoginPasswordwhile also settingAzureADOnlyAuthenticationmight be allowed when creating the resource, but rejected during an update.
The issue mentions a workaround using an ignore on the AdministratorLoginPassword setting, I am already doing this mainly because I need to set the Password during creation otherwise it refuses to create it.
I think this response from the Azure SQL team is the explanation for this odd behavior. Essentially
- Changing the password is not allowed when Entra-only auth is enabled because it could lead to invalid templates.
- Any updates containing the same, unchanged password are also rejected because different behavior on same vs different password would be a vector for brute forcing the password.
That would mean that the immediate workaround would be to remove AdministratorLoginPassword altogether from your code after the creation of the server. Would you be able to try that out?
Of course, that's not the idempotent update experience we want. We might be able to special-case this in the provider, removing the password from update requests when AzureADOnlyAuthentication is set.
@thomas11 good find. Other providers have a concept of "create-only" properties - which are only valid to be sent on the initial creation.
Is there any indication of such behaviour expectations in the Azure API Specifications?
Alternatively, perhaps we could add a similar, manually curated set of metadata for resource properties which should only be sent on creation.
@danielrbradley It's slightly more tricky than that. If AzureADOnlyAuthentication is not set, then updating the password is allowed. So the property is create-only only if AzureADOnlyAuthentication is enabled.
This could hypothetically be solved using the same suggested mechanism as for handling circular dependencies:
- https://github.com/pulumi/pulumi/issues/13999
I think the best immediate approach would be to document this oddity in the Azure API design.
The added docs are live now. I hope that helps.
I'll close this issue since it's essentially by design of the Azure API.
https://github.com/pulumi/pulumi/issues/13999 might be a future enhancement to make this design easier to work with.