Subscribe to the feed

External Secrets Operator is a Kubernetes operator that integrates with external secret management systems like AWS Secrets Manager, HashiCorp Vault, Google Secrets Manager, Azure Key Vault, and many more. The operator reads information from external APIs and automatically injects the values into a Kubernetes secret.

You can read more about External Secrets Operator here.

In this blog post, we will create an ArgoCD application to showcase how an External Secrets Operator fetches the GitLab CI variable and creates a Kubernetes secret object in the cluster.

Below is the workflow diagram showing how ROSA, ArgoCD, GitLab CI, and ESO work together:


Product versions used in this blog post:

Red Hat OpenShift on AWS4.12.27
External Secrets Operator0.9.3
Red Hat OpenShift Gitops (Argo CD) Operator1.5.10
GitLab Enterprise Edition16.3.0
OC CLI4.12.x

GitLab Configuration

Referring to the above diagram, we will set up GitLab CI as an external secret store.

To talk to GitLab API, ESO needs a GitLab access token and project or group ID. ESO secret store will leverage the access token to authenticate against Gitlab APIs:

To create a token in GitLab, on the left pane, navigate to Settings -> Access Tokens - > add a new token


Set the token name, expiration date, and role (I have added all, but grant API and read_api roles should be enough for ESO to fetch the Gitlab CI variables).


Be sure to save the token, as you won't be able to re-access it.

Now we will define the secrets in GitLab CI UI as a variable and ensure that sensitive secrets like tokens or passwords are stored under settings in the GitLab UI, not in the .gitlab-ci.yml file.

Navigate to Settings -> CI/CD -> Add variables in Gitalb UI:

awsdraft1 awsdraft44

ESO Configuration

Now we will configure the External Secrets Operator and RedHat OpenShift GitOps (Argo CD) on the Red Hat OpenShift on AWS cluster. (I will not cover the installation of ESO and Red Hat OpenShift GitOps as they are relatively straightforward.) The operators (ESO and Red Hat OpenShift GitOps) can be installed declaratively using the GitOps principle, but I will leave that for another time.

Note that if you are planning to use External Secrets Operator from the OpenShift operator hub, after installing ESO, you need to create the CR ( to install an instance of external Secrets and a namespace for the OperatorConfig. Let's create a namespace, "external-secrets", to host the OperatorConfig CR. Below are the manifests files for reference:

OperatorConfig Namespace:

apiVersion: v1
kind: Namespace
name: external-secrets
annotations: "-10"


OperatorConfig Custom Resource:

kind: OperatorConfig
name: cluster
namespace: external-secrets
annotations: "2" SkipDryRunOnMissingResource=true
  enabled: true
    port: 8080
   cpu: 10m
   memory: 96Mi
   cpu: 100m
   memory: 256Mi


Next we will create a Kubernetes secret object containing the GitLab access token. External Secrets Operator will leverage the token to access the GitLab APIs to fetch the secrets stored as GitLab CI variables.

Secret Containing GitLab Access Token:

apiVersion: v1
kind: Secret
name: external-secret-token
namespace: openshift-config
  type: gitlab
type: Opaque
token: "XXXXXXXX"  (Gitlab project access token goes here)


It's time to create the SecretStore, which will specify how to access GitLab to fetch the project variables as secret. It uses the GitLab Access Token created earlier to authenticate against the GitLab API:

SecretStore Resource:

kind: SecretStore
name: gitlab-demo-secret-store
namespace: openshift-config
    url:     (replace with your GitLab url)
          name: external-secret-token (we are referring to GitLab token secret)
          key: token
    projectID: "48411817"     (replace with your GitLab project id)


Note: If you need a global, cluster-wide SecretStore that can be referenced from all namespaces, a ClusterSecretStore  would be more appropriate.

The last resource to create is an External Secrets resource that declares what data to fetch (GitLab CI variable in this case). It has a reference to a SecretStore, which knows how to access that data.

External Secrets Resource:

kind: ExternalSecret
name: gitlab-demo-external-secret
namespace: openshift-config
refreshInterval: '15s'

  kind: SecretStore
  name: gitlab-demo-secret-store (name must match secret store created earlier)

  name: eso-secret   (secret name to be created on target cluster)
  creationPolicy: Owner
      secretKey: "{{ .secretKey }}"

  - secretKey: secretKey (key for the secret to be created on the cluster)
      key: gitlabsecret (key for CI variable on GitLab)


Below is a snapshot of my Git repository with the above files:


Let's add my GitLab repository to the Argo and deploy the External Secrets manifests to our Red Hat Openshift on AWS cluster:


We will now create an ArgoCD application to showcase the demo. Our test case here is the External Secrets Operator, which should fetch the GitLab CI variable with key:"gitlabsecret" and value: "secretmanagementwitheso" and create a secret object with the name "eso-secret" and value as "secretmanagementwitheso" in the "openshift-config" namespace.

kind: Application
name: eso
  name: ''
  namespace: ''
  server: 'https://kubernetes.default.svc'
  path: eso
  repoURL: ''
  targetRevision: HEAD
project: default
    prune: false
    selfHeal: false


As shown below, the ArgoCD application synced successfully:


Navigate back to the OpenShift console under the "openshift-config" namespace to ensure the secret "eso-secret" is created:

awsdraft 2

As you can see, ESO fetched the GitLab CI/CD variable and created the secret in the desired namespace.


I find ESO with GitLab CI a very neat solution for organizations that don't have an enterprise-grade secret management solution.

Additionally, ESO not only creates the secrets but also keeps them updated/synced to the external secret store.  

ESO supports a wide variety of secrets types, including Dockerconfig, TLS Cert, SSH keys, and more. Refer to the ESO Secret Types for more information.

I have used RedHat OpenShift on AWS as a reference in the blog post; however, the External Secrets Operator configuration will work for all OpenShift managed and on-prem offerings.

About the author


Browse by channel

automation icon


The latest on IT automation for tech, teams, and environments

AI icon

Artificial intelligence

Updates on the platforms that free customers to run AI workloads anywhere

open hybrid cloud icon

Open hybrid cloud

Explore how we build a more flexible future with hybrid cloud

security icon


The latest on how we reduce risks across environments and technologies

edge icon

Edge computing

Updates on the platforms that simplify operations at the edge

Infrastructure icon


The latest on the world’s leading enterprise Linux platform

application development icon


Inside our solutions to the toughest application challenges

Original series icon

Original shows

Entertaining stories from the makers and leaders in enterprise tech