Using AWS Secrets Manager with External Secrets Operator on ROSA HCP

Bridging the Security Gap with External Secrets Operator

In the modern cloud-native landscape, managing sensitive credentials across distributed environments is a critical challenge for platform engineers. The External Secrets Operator (ESO) for Red Hat OpenShift provides a robust, cluster-wide service designed to bridge the gap between enterprise security standards and Kubernetes agility. By acting as a secure conduit, ESO automates the fetching, refreshing, and provisioning of secrets from external management systems directly into your OpenShift clusters, ensuring that your applications remain secure without manual overhead.

The Security Limitations of Native Kubernetes Secrets

While Kubernetes provides a native Secret resource, relying on it alone presents significant security hurdles for production-grade environments:

• Encoding vs. Encryption: By default, native secrets are stored as Base64-encoded strings—an obfuscation method that offers no true cryptographic protection and is easily reversible.
• The “Admin-as-Superuser” Risk: Even when encryption-at-rest is enabled in etcd, cluster administrators often maintain inherent visibility into secret values, complicating compliance in multi-tenant environments.
• Rotation Inconsistency: Manual rotation processes are prone to human error, often leading to stale credentials or security gaps across global clusters.
• Access Control Fragility: A single misconfiguration in Role-Based Access Control (RBAC) can inadvertently expose sensitive data to unauthorized entities within a namespace.

The Strategic Advantage of Externalized Secret Management

Moving sensitive data out of the cluster and into a dedicated management system shifts the security paradigm from reactive to proactive. By utilizing an external-first approach, organizations gain:

• Centralized Governance: A single source of truth for sensitive data that exists independently of the Kubernetes lifecycle.
• Enhanced Privilege Separation: By decoupling storage from the cluster, you can protect secrets from cluster admins and enforce strict “least-privilege” access.
• Automated Lifecycle Management: Fully automate the secret lifecycle—from creation and fine-grained access control to rotation and expiration—ensuring your security posture evolves in real-time.

Refer to External Secrets Operator for Red Hat OpenShift for more details.

Refer to Limitations of External Secrets Operator

Prerequisites

1. ROSA HCP Cluster access with cluster-admin privileges.
2. OpenShift CLI (oc)
3. Access AWS Secrets Manager and aws cli

Create environment variables

1. Create environment variables :

Install the ESO Operator

You can install the operator via console by searching for External Secrets Operator for Red Hat OpenShift in the OperatorHub or Software Catalog search query.

Alternatively, follow this step to install via CLI.

1. OpenShift project for ESO operator

2. Create an OperatorGroup

3. Create a Subscription for ESO Operator

Note: Make sure to validate the current stable channel version.

4. Verify Operator Installation Verify OLM subscription, Operator deployment and the status of the External Secrets Operator is Running

Note: This can take up to a minute.

Example Output

Make sure that the pod’s status is Running before moving on to the next step.

Note: Refer to External Secrets Operator for Red Hat OpenShift and external-secrets for advance configurations.

5. Create external secrets operand

Use external secret in ROSA HCP project

1. Create a secret in AWS Secrets Manager

Make sure to replace the username and password placeholder values.

2. Create an IAM Access Policy for above secret

3. Create an IAM Role trust policy

4. Create an IAM role and attach the IAM policy

5. Create a Project to test access to AWS secret in ROSA HCP project

6. Annotate the default service account to use the STS Role

Note: create separate service account if your appplication uses non defult service account

7. Create the SecretStore for service account:

8. Create an ExternalSecret Resource

Note: For more advanced examples refer external-secrets

9. Validate access to external secret

First, check that SecretStore is Ready and validated.

Example Output

And then check that the ExternalSecret object exists and points at the right remote secret.

Example Output

Confirm that Kubernetes created a local secret named my-app-secrets.

Example Output

Confirm that secret has data, i.e. metadata/size

Example Output

Decode and verify the secret value

Example Output

10. Deploy a pod and validate

11. Verify the pod has the secret mounted

Cleanup

1. Delete test Project

2. Delete the custom resource definitions (CRDs)

3. Delete the external-secrets-operator namespace

4. Cleanup your AWS Policies and roles

5. Delete the Secrets Manager secret