Azure managed identity / workload identity support for connections

Overview of roadmap item

Managed Identity (and Workload Identity in Kubernetes) enable applications to access Azure APIs without using static credentials (like passwords and access keys). This is a security best practice and many organizations will require the use of MI for applications to connect to the cloud.

The downside of MI is that it's complex to configure. Each container must a unique identity, and that identity must be granted access to the Azure APIs it accesses in a least-privilege fashion.

Radius can simplify this for users by dynamically managing the MI configuration based on the existing Recipes and Connections concept. Recipes already get to configure how the container accesses the Azure APIs by returning credentials and other configuration data in their outputs. This can be extended to include MI configuration.

The workflow could look like this:

• A platform engineer is building a new resource type and recipe for accessing Azure Storage.
• The new recipe returns metadata as part of the recipe outputs indicating that:
  • MI/WI is required for applications using the recipe.
  • The permissions that the application should have (see Role Assignment).
  • This is done instead of returning credentials as recipe outputs.
• Developers can build applications that use this new resource type and containers that declare a connection to it.
• When deployed, Radius will configure an MI/WI identity for each container that requires it, and configure the required permissions (based on the recipe outputs).

In this workflow, compliance with the required policy is met by using the new resource type. The recipe does not return any static credentials, and so developers must use MI in order to access the Azure APIs.

Compliance organization-wide can be enforced by onboarding to the new resource type.

Related issues

### Related issues

Additional context

Note: Radius already supports MI/WI for management operations performed on-behalf-of the user (docs). The linked feature configures how Radius authenticates with Azure, and is unrelated to the user's applications.

This roadmap item provides new features targeted at application developers and at recipe authors. It should not be confused with the existing support.

Note: Radius already supports a similar feature for direct connections. The direct connections feature pre-dates the addition of Recipes to Radius, and is much less powerful. Direct connections should be removed in favor of the proposed feature.

Start by reading the existing Azure managed/workload identity documentation and the direct connections documentation referenced in the issue, then review how Recipes and Connections currently expose outputs. Define the recipe metadata, identity configuration, and permission flow needed for application containers. Done means recipe-based connections can configure MI/WI and required role assignments without static credentials, with direct connections addressed.