AWS IAM/IRSA federated identity management for connections

Overview of roadmap item

AWS IAM (and IRSA in Kubernetes) enable applications to access AWS resources without using static credentials (like passwords and access keys). This is a security best practice and many organizations will require the use of IAM for applications to connect to AWS APIs.

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

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

The workflow could look like this:

• A platform engineer is building a new resource type and recipe for accessing S3.
• The new recipe omits any credentials like passwords from its output.
• The new recipe returns metadata as part of the recipe outputs indicating that:
  • IAM/IRSA is required for applications using the recipe.
  • The permissions that the application should have (see IAM Role).
  • This is done instead of returning credentials as recipe outputs.
• Developers can build applications that use this new resource type with containers that declare a connection to it.
• When deployed, Radius will configure an IAM/IRSA 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 IAM in order to access the resource.

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

Related issues

### Related issues

Additional context

Note: Radius already supports IAM/IRSA for management operations performed on-behalf-of the user (docs). The linked feature configures how Radius authenticates with AWS, 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.

Start by turning the proposed Recipes and Connections workflow into a concrete feature specification for application IAM/IRSA, keeping it distinct from the existing AWS provider IRSA support described in the linked documentation. Define the recipe output metadata, per-container identity setup, least-privilege permissions, and how completion would be validated; the payload names no implementation files or tests.