Support for AssumeRole in AWS Secrets Store CSI Provider for SecretProviderClass

[dvp34]

Summary

This PR adds support for assuming an IAM role at mount time via a new SecretProviderClass parameter: assumeRoleArn. When specified, the AWS provider will perform an STS AssumeRole using the base credentials (IRSA or Pod Identity) and use the assumed-role credentials for all AWS Secrets Manager and SSM calls for that mount.

Optional parameters are also supported:

• assumeRoleDurationSeconds
• assumeRoleExternalId

This enables cleaner and more scalable cross-account access patterns for secrets.

---

Problem Statement

Currently, secrets-store-csi-driver-provider-aws retrieves secrets using the credentials obtained via IRSA or Pod Identity and directly calls AWS Secrets Manager or SSM with those credentials.

In cross-account setups (for example, EKS in Account A accessing Secrets Manager in Account B), this requires:

• The IRSA role to have secretsmanager:GetSecretValue permissions, and
• A resource policy on each secret in Account B explicitly allowing access from the IRSA role.

This approach introduces significant operational overhead, especially when multiple workloads or clusters need access to cross-account secrets.

Although users may specify an assumeRoleArn (or similar) under spec.parameters today, the AWS provider does not parse or act on this value. No sts:AssumeRole call is made, and the parameter is effectively ignored. As a result, common cross-account access patterns are not supported.

---

Proposed Solution

Add support for assuming a role per mount by introducing the following SecretProviderClass parameters under spec.parameters:

• assumeRoleArn (string, required)
  Instructs the provider to call STS AssumeRole using the base credentials (IRSA or Pod Identity).

• assumeRoleDurationSeconds (string or int, optional)
  Session duration for the assumed role.

• assumeRoleExternalId (string, optional)
  External ID to pass to the AssumeRole call.

When assumeRoleArn is specified, the IRSA role only needs permission to call sts:AssumeRole. All Secrets Manager or SSM access is performed using the assumed role, eliminating the need for:

• Direct Secrets Manager permissions on the IRSA role, and
• Resource policies on secrets for each consuming role.

---

Example SecretProviderClass

apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
  name: cross-account-secrets
spec:
  provider: aws
  parameters:
    region: us-east-1
    assumeRoleArn: arn:aws:iam::123456789012:role/target-role
    assumeRoleDurationSeconds: "900"
    objects: |
      - objectName: "arn:aws:secretsmanager:us-east-1:123456789012:secret:MySecret-abc123"
        objectType: "secretsmanager"

---

Behaviour & implementation notes

• When assumeRoleArn is present:
  1. Provider obtains base credentials via IRSA or Pod Identity (current behavior).
  2. Provider calls STS AssumeRole (with optional Duration/ExternalId) using those credentials.
  3. Provider uses the resulting assumed-role creds to instantiate region clients (Secrets Manager / SSM) for the mount request.
• If assumeRoleArn is missing, current behaviour is unchanged.

[simonmarty]

Could you talk a bit more about your use case? You should be able to access secrets cross-account using their ARN https://docs.aws.amazon.com/secretsmanager/latest/userguide/auth-and-access_examples_cross.html.

If you are an enterprise customer, I'd like to encourage you to reach out to AWS Support about your use case too.

[dvp34]

Could you talk a bit more about your use case? You should be able to access secrets cross-account using their ARN https://docs.aws.amazon.com/secretsmanager/latest/userguide/auth-and-access_examples_cross.html.

If you are an enterprise customer, I'd like to encourage you to reach out to AWS Support about your use case too.

Thanks you for review and question.
Currently, secrets-store-csi-driver-provider-aws supports fetching secrets using IRSA or pod identity. In a cross-account setup (for example, EKS in Account A and Secrets Manager in Account B), this requires:

The IRSA role to have secretsmanager:GetSecretValue permissions, and

A resource policy on the secret in Account B explicitly allowing access from the IRSA role.

This introduces significant operational overhead when managing cross-account secrets.

If the provider supported specifying an assumeRole, the IRSA role would only need permission to assume that role. All Secrets Manager actions would then be performed using the assumed role, eliminating the need for:

Direct Secrets Manager permissions on the IRSA role, and

Resource policies on the secret for each consuming role.

This approach simplifies cross-account access patterns and aligns well with common AWS security practices.

[codecov]

Codecov Report

❌ Patch coverage is 75.60976% with 10 lines in your changes missing coverage. Please review.
✅ Project coverage is 60.25%. Comparing base (6dbe3b9) to head (54f359f).

Files with missing lines	Patch %	Lines
server/server.go	41.17%	9 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #555      +/-   ##
==========================================
+ Coverage   60.10%   60.25%   +0.14%     
==========================================
  Files          11       11              
  Lines         762      790      +28     
==========================================
+ Hits          458      476      +18     
- Misses        287      296       +9     
- Partials       17       18       +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[dvp34]

Hello @simonmarty I would appreciate your review on this PR again. Please do let me know if there are any other comments/questions you may have. Thank you!