You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The content you are editing has changed. Please copy your edits and refresh the page.
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.
The text was updated successfully, but these errors were encountered:
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:
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.
The text was updated successfully, but these errors were encountered: