1. Proposed title of this feature request

Support for Referencing AWS IAM Role from Kubernetes Secret in ClusterSecretStore 

2. What is the nature and description of the request?

Problem Statement

We are implementing the External Secrets Operator (ESO v0.1.0) on our OpenShift 4.19 clusters to securely manage secrets from AWS Secrets Manager, following a GitOps-first approach using OpenShift GitOps (Argo CD) and Helm. However, we have encountered a significant blocker in achieving a secure, declarative deployment pattern.

The ClusterSecretStore requires the AWS IAM Role ARN to be specified as a plaintext value in its spec under spec.provider.aws.role. Unlike auth.secretRef, which supports referencing Kubernetes Secrets, the role parameter offers no such mechanism, resulting in:

• Violation of security policies (sensitive credential identifiers in Git)

• GitOps compliance issues

• Operational complexity via insecure workarounds

Current Behavior

Example configuration snippet:

apiVersion: external-secrets.io/v1
kind: ClusterSecretStore
metadata:
  name: {{ .Values.clusterSecretStoreName }}
spec:
  provider:
    aws:
      auth:
        secretRef:
          accessKeyIDSecretRef:
            key: AWS_ACCESS_KEY_ID
            name: {{ .Values.awsCredentialsSecretName }}
            namespace: {{ .Release.Namespace }}
          secretAccessKeySecretRef:
            key: AWS_SECRET_ACCESS_KEY
            name: {{ .Values.awsCredentialsSecretName }}
            namespace: {{ .Release.Namespace }}
      region: {{ .Values.awsRegion }}
      role: {{ required "A valid .Values.awsIamRole entry required!" .Values.awsIamRole }}  # <- No secretRef support
      service: SecretsManager 

Security & Operational Risk

• Security Violation: The ARN is a privileged identifier that must not be stored in Git. Even though it isn’t a secret per se, leaking ARNs can aid attackers in privilege escalation or reconnaissance.
• Audit Failure Risk: Plaintext ARNs in Git would cause us to fail compliance audits (ISO 27001, CIS Benchmarks, internal InfoSec policies).
• Broken GitOps Flow: Pipeline-based injection causes Git <-> Cluster drift, violating GitOps' principle of full declarative state.

Expected Behavior / Feature Request:

Introduce a new field:

spec:
  provider:
    aws:
      roleSecretRef:
        name: aws-role-secret
        key: ROLE_ARN
        namespace: my-namespace
 

• This roleSecretRef should override the plaintext role field if present.
• Aligns behavior with auth.secretRef to support secure, secret-based injection for all sensitive fields.
• Compatible with Helm and GitOps workflows where the secret is managed out-of-band (e.g., via a bootstrap Job, initContainer, Sealed Secrets, or vault-sync).

3. Why does the customer need this? (List the business requirements here)

Security:

• Hardcoding the ARN in Git introduces security risk — role ARNs are sensitive identifiers for trust policies.

• Base64 or Helm templating are not secure substitutes.

GitOps:

• GitOps models require storing all declarative manifests in Git.

• A pipeline-based override breaks "declarative-only" workflows and introduces configuration drift.

Operational Burden:

• Current workaround requires a separate privileged injection pipeline to fetch and inject the ARN securely.

• Significantly increases deployment complexity and violates principles of automation and immutability.

4. List any affected packages or components.