Subscribe to our blog

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.

저자 소개

채널별 검색

automation icon


기술, 팀, 환경을 포괄하는 자동화 플랫폼에 대한 최신 정보

AI icon


고객이 어디서나 AI 워크로드를 실행할 수 있도록 지원하는 플랫폼 업데이트

cloud services icon

클라우드 서비스

관리형 클라우드 서비스 포트폴리오에 대해 더 보기

security icon


환경과 기술 전반에 걸쳐 리스크를 감소하는 방법에 대한 최신 정보

edge icon

엣지 컴퓨팅

엣지에서의 운영을 단순화하는 플랫폼 업데이트

Infrastructure icon


세계적으로 인정받은 기업용 Linux 플랫폼에 대한 최신 정보

application development icon


복잡한 애플리케이션에 대한 솔루션 더 보기

Original series icon

오리지널 쇼

엔터프라이즈 기술 분야의 제작자와 리더가 전하는 흥미로운 스토리