Description
Description
KeyVaultAdministrator is too high of a priviledge role to use by default in applications. By default apps should not need to manage key vault settings, but instead just be able to read secrets. So instead, by default apps will get KeyVaultSecretsUser role and if an application needs a higher role, it can be configured easily by using WithRoleAssignments.
For more information, see:
- Make the default role for KeyVault references to Key Vault Secrets User (dotnet/aspire#8218)
- Reduce default KeyVault role (dotnet/aspire#8351)
Version
.NET Aspire 9.2
Previous behavior
Previously applications were granted the KeyVaultAdministrator role when referencing an Azure KeyVault.
New behavior
Now applications will be granted the KeyVaultSecretsUser role when referencing an Azure KeyVault.
Type of breaking change
- Binary incompatible: Existing binaries might encounter a breaking change in behavior, such as failure to load or execute, and if so, require recompilation.
- Source incompatible: When recompiled using the new SDK or component or to target the new runtime, existing source code might require source changes to compile successfully.
- Behavioral change: Existing binaries might behave differently at run time.
Reason for change
KeyVaultAdministrator is too high of a priviledge role to use by default in applications. By default apps should need to manage key vault settings, but instead just be able to read secrets. It is more secure to use a lower role by default.
Recommended action
If an application needs higher privileges than KeyVaultSecretsUser, you can specify the roles necessary for the application by using the WithRoleAssignments API:
using Azure.Provisioning.KeyVault;
var kv = builder.AddAzureKeyVault("kv");
builder.AddProject<Projects.ApiService>("api")
.WithRoleAssignments(kv, KeyVaultBuiltInRole.KeyVaultContributor)
Affected APIs
- Aspire.Hosting.AzureKeyVaultResourceExtensions.AddAzureKeyVault
Metadata
Metadata
Assignees
Labels
Type
Projects
Status