Feature Overview (aka. Goal Summary)  

An elevator pitch (value statement) that describes the Feature in a clear, concise way.  Complete during New status.

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.

Goals (aka. expected user outcomes)

The observable functionality that the user now has as a result of receiving this feature. Include the anticipated primary user type/persona and which existing features, if any, will be expanded. Complete during New status.

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.

Requirements (aka. Acceptance Criteria):

A list of specific needs or objectives that a feature must deliver in order to be considered complete.  Be sure to include nonfunctional requirements such as security, reliability, performance, maintainability, scalability, usability, etc.  Initial completion during Refinement status.

<enter general Feature acceptance here>

Anyone reviewing this Feature needs to know which deployment configurations that the Feature will apply to (or not) once it's been completed.  Describe specific needs (or indicate N/A) for each of the following deployment scenarios. For specific configurations that are out-of-scope for a given release, ensure you provide the OCPSTRAT (for the future to be supported configuration) as well.

Use Cases (Optional):

Include use case diagrams, main success scenarios, alternative flow scenarios.  Initial completion during Refinement status.

<your text here>

Questions to Answer (Optional):

Include a list of refinement / architectural questions that may need to be answered before coding can begin.  Initial completion during Refinement status.

<your text here>

Out of Scope

High-level list of items that are out of scope.  Initial completion during Refinement status.

<your text here>

Background

Provide any additional context is needed to frame the feature.  Initial completion during Refinement status.

<your text here>

Customer Considerations

Provide any additional customer-specific considerations that must be made when designing and delivering the Feature.  Initial completion during Refinement status.

<your text here>

Documentation Considerations

Provide information that needs to be considered and planned so that documentation will meet customer needs.  If the feature extends existing functionality, provide a link to its current documentation. Initial completion during Refinement status.

<your text here>

Interoperability Considerations

Which other projects, including ROSA/OSD/ARO, and versions in our portfolio does this feature impact?  What interoperability test scenarios should be factored by the layered products?  Initial completion during Refinement status.

<your text here>