Chapter 12. External Secrets Operator for Red Hat OpenShift

Procedure

1. Log in to the OpenShift Container Platform web console.
2. Navigate to Ecosystem Software Catalog.
3. Enter External Secrets Operator in the search box.
4. Select the External Secrets Operator for Red Hat OpenShift from the generated list and click Install.

5. On the Install Operator page:

   1. Update the Update channel, if necessary. The channel defaults to stable-v1, which installs the latest stable release of the External Secrets Operator.
   2. Select the version from Version drop-down list.

   3. Choose the Installed Namespace for the Operator.

      • To use the default Operator namespace, select the Operator recommended Namespace option.
      • To use the namespace that you created, select the Select a Namespace option, and then select the namespace from the drop-down list.
      • If the default external-secrets-operator namespace does not exist, it is created for you by the Operator Lifecycle Manager (OLM).

   4. Select an Update approval strategy.

      • The Automatic strategy enables OLM to automatically update the Operator when a new version is available.
      • The Manual strategy requires a user with appropriate credentials to approve the Operator update.
   5. Click Install.

Verification

1. Navigate to Ecosystem Installed Operators.
2. Verify that External Secrets Operator is listed with a Status of Succeeded in the external-secrets-operator namespace.

Procedure

1. Create a new project named external-secrets-operator by running the following command:

   $ oc new-project external-secrets-operator

2. Create an OperatorGroup object by defining a YAML file with the following content:

   apiVersion: operators.coreos.com/v1
   kind: OperatorGroup
   metadata:
     name: openshift-external-secrets-operator
     namespace: external-secrets-operator
   spec:
     targetNamespaces: []

3. Create the OperatorGroup object by running the following command:

   $ oc create -f operatorGroup.yaml

4. Create a Subscription object by defining a YAML file with the following content:

   The following is an example of a subscription.yaml file.

   apiVersion: operators.coreos.com/v1alpha1
   kind: Subscription
   metadata:
     name: openshift-external-secrets-operator
     namespace: external-secrets-operator
   spec:
     channel: stable-v1
     name: openshift-external-secrets-operator
     source: redhat-operators
     sourceNamespace: openshift-marketplace
     installPlanApproval: Automatic
     startingCSV: external-secrets-operator.v1.0.0

5. Create the Subscription object by running the following command:

   $ oc create -f subscription.yaml

Verification

1. Verify that the OLM subscription is created by running the following command:

   $ oc get subscription -n external-secrets-operator

   The following is example output verifying the OLM subscription is created.

   NAME                                  PACKAGE                               SOURCE             CHANNEL
   openshift-external-secrets-operator   openshift-external-secrets-operator   redhat-operators   stable-v1

2. Verify whether the Operator is successfully installed by running the following command:

   $ oc get csv -n external-secrets-operator

   The following is example output verifying that the Operator is installed.

   NAME                               DISPLAY                                           VERSION   REPLACES   PHASE
   external-secrets-operator.v1.0.0   External Secrets Operator for Red Hat OpenShift   1.0.0                Succeeded

3. Verify that the status of the External Secrets Operator is Running by entering the following command:

   $ oc get pods -n external-secrets-operator

   The following is example output verifying the External Secrets Operator is Running.

   NAME                                                            READY   STATUS    RESTARTS   AGE
   external-secrets-operator-controller-manager-5699f4bc54-kbsmn   1/1     Running   0          25h

Procedure

1. Create an externalsecretsconfig.openshift.operator.io object by defining a YAML file with the following content:

   Example externalsecretsconfig.yaml file.

   apiVersion: operator.openshift.io/v1alpha1
   kind: ExternalSecretsConfig
   metadata:
     labels:
       app: external-secrets-operator
       app.kubernetes.io/name: cluster
     name: cluster
   spec:
     controllerConfig:
       networkPolicies:
       - componentName: ExternalSecretsCoreController
         egress:
         - {}
         name: allow-external-secrets-egress

   For more information on spec configuration, see "External Secrets Operator for Red Hat OpenShift APIs".

2. Create the externalsecretsconfigs.openshift.operator.io object by running the following command:

   $ oc create -f externalsecretsconfig.yaml

Verification

1. Verify that the external-secrets pods are running by entering the following command:

   $ oc get pods -n external-secrets

   Example output

   NAME                                                READY   STATUS    RESTARTS   AGE
   external-secrets-75d47cb9c8-6p4n2                   1/1     Running   0          4h5m
   external-secrets-cert-controller-676444b897-qb6ft   1/1     Running   0          4h5m
   external-secrets-webhook-b566658ff-7m4d5            1/1     Running   0          4h5m

2. Verify that the external-secrets-operator deployment object reports a successful status by running the following command:

   $ oc get externalsecretsconfig.operator.openshift.io cluster -n external-secrets-operator -o jsonpath='{.status.conditions}' | jq .

   Example output

   [
     {
       "lastTransitionTime": "2025-06-17T14:57:04Z",
       "message": "",
       "observedGeneration": 2,
       "reason": "Ready",
       "status": "False",
       "type": "Degraded"
     },
     {
       "lastTransitionTime": "2025-11-27T05:58:38Z,
       "message": "reconciliation successful",
       "observedGeneration": 2,
       "reason": "Ready",
       "status": "True",
       "type": "Ready"
     }
   ]

Procedure

1. Edit the ExternalSecretsConfig CR by running the following command:

   $ oc edit externalsecretsconfigs.operator.openshift.io cluster

2. Set the policy by editing the networkPolicies section:

   apiVersion: operator.openshift.io/v1alpha1
   kind: ExternalSecretsConfig
   metadata:
     name: cluster
   spec:
     controllerConfig:
       networkPolicies:
         - name: allow-external-secrets-egress
           componentName: CoreController
           egress: # Allow all egress traffic

Procedure

1. Edit the ExternalSecretsConfig CR by running the following command:

   $ oc edit externalsecretsconfigs.operator.openshift.io cluster

2. Set the policy by editing the networkPolicies section. The following example shows how to allow egress to Amazon Web Services (AWS) endpoints.

   apiVersion: operator.openshift.io/v1alpha1
   kind: ExternalSecretsConfig
   metadata:
     name: cluster
   spec:
     controllerConfig:
       networkPolicies:
         - componentName: ExternalSecretsCoreController
           egress:
             # Allow egress to Kubernetes API server, AWS endpoints, and DNS
             - ports:
                 - port: 443   # HTTPS (AWS Secrets Manager)
                   protocol: TCP
         - name: allow-external-secrets-egress

   where:

   componentName

   Specifies the name for the core controller which is ExternalSecretsCoreController. Egress rules must specify the required ports, such as Transmission Control Protocol (TCP) port 443, for services such as the AWS Secrets Manager.

Procedure

1. Create the cluster-monitoring-config.yaml YAML file:

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: cluster-monitoring-config
     namespace: openshift-monitoring
   data:
     config.yaml: |
       enableUserWorkload: true

2. Apply the ConfigMap by running the following command:

   $ oc apply -f cluster-monitoring-config.yaml

Procedure

1. Configure the Operator to use HTTP for the metrics server. HTTPS is enabled by default.

   1. Update the subscription object for External Secrets Operator for Red Hat OpenShift to configure the HTTP protocol by running the following command:

      $ oc -n external-secrets-operator patch subscription openshift-external-secrets-operator --type='merge' -p '{"spec":{"config":{"env":[{"name":"METRICS_BIND_ADDRESS","value":":8080"}, {"name": "METRICS_SECURE", "value": "false"}]}}}'

   2. To verify that the External Secrets Operator pod is redeployed and that the configured values for METRICS_BIND_ADDRESS and METRICS_SECURE are updated, run the following command:

      $ oc set env --list deployment/external-secrets-operator-controller-manager -n external-secrets-operator | grep -e METRICS_BIND_ADDRESS -e METRICS_SECURE -e container

      The following example shows that the METRICS_BIND_ADDRESS and METRICS_SECURE have been updated:

      # deployments/external-secrets-operator-controller-manager, container manager
      METRICS_BIND_ADDRESS=:8080
      METRICS_SECURE=false

2. Create the Secret resource with the kubernetes.io/service-account.name annotation to inject the token required for authenticating with the metrics server.

   1. Create the secret-external-secrets-operator.yaml YAML file:

      apiVersion: v1
      kind: Secret
      metadata:
        labels:
          app: external-secrets-operator
        name: external-secrets-operator-metrics-auth
        namespace: external-secrets-operator
        annotations:
          kubernetes.io/service-account.name: external-secrets-operator-controller-manager
      type: kubernetes.io/service-account-token

   2. Create the Secret resource by running the following command:

      $ oc apply -f secret-external-secrets-operator.yaml

3. Create the ClusterRoleBinding resource required for granting permissions to access metrics:

   1. Create the clusterrolebinding-external-secrets.yaml YAML file:

      The following example shows a clusterrolebinding-external-secrets.yaml file.

      apiVersion: rbac.authorization.k8s.io/v1
      kind: ClusterRoleBinding
      metadata:
        labels:
          app: external-secrets-operator
        name: external-secrets-allow-metrics-access
      roleRef:
        apiGroup: rbac.authorization.k8s.io
        kind: ClusterRole
        name: external-secrets-operator-metrics-reader
      subjects:
        - kind: ServiceAccount
          name: external-secrets-operator-controller-manager
          namespace: external-secrets-operator

   2. Create the ClusterRoldeBinding custom resource by running the following command:

      $ oc apply -f clusterrolebinding-external-secrets.yaml

4. Create the ServiceMonitor CR if using the default HTTPS:

   1. Create the servicemonitor-external-secrets-operator-https.yaml YAML file:

      apiVersion: monitoring.coreos.com/v1
      kind: ServiceMonitor
      metadata:
        labels:
          app: external-secrets-operator
        name: external-secrets-operator-metrics-monitor
        namespace: external-secrets-operator
      spec:
        endpoints:
          - authorization:
              credentials:
                name: external-secrets-operator-metrics-auth
                key: token
              type: Bearer
            interval: 60s
            path: /metrics
            port: metrics-https
            scheme: https
            scrapeTimeout: 30s
            tlsConfig:
              ca:
                configMap:
                  name: openshift-service-ca.crt
                  key: service-ca.crt
              serverName: external-secrets-operator-controller-manager-metrics-service.external-secrets-operator.svc.cluster.local
        namespaceSelector:
          matchNames:
            - external-secrets-operator
        selector:
          matchLabels:
            app: external-secrets-operator
            svc: external-secrets-operator-controller-manager-metrics-service

   2. Create the ServiceMonitor CR by running the following command:

      $ oc apply -f servicemonitor-external-secrets-operator-https.yaml

5. Create the ServiceMonitor CR if configured to use HTTP:

   1. Create the servicemonitor-external-secrets-operator-http.yaml YAML file:

      apiVersion: monitoring.coreos.com/v1
      kind: ServiceMonitor
      metadata:
        labels:
          app: external-secrets-operator
        name: external-secrets-operator-metrics-monitor
        namespace: external-secrets-operator
      spec:
        endpoints:
          - authorization:
              credentials:
                name: external-secrets-operator-metrics-auth
                key: token
              type: Bearer
            interval: 60s
            path: /metrics
            port: metrics-http
            scheme: http
            scrapeTimeout: 30s
        namespaceSelector:
          matchNames:
            - external-secrets-operator
        selector:
          matchLabels:
            app: external-secrets-operator
            svc: external-secrets-operator-controller-manager-metrics-service

   2. Create the ServiceMonitor CR by running the following command:

      $ oc apply -f servicemonitor-external-secrets-operator-http.yaml

      After the ServiceMonitor CR is created, the user workload Prometheus instance begins metrics collection from the Operator. The collected metrics are labeled with job="external-secrets-operator-controller-manager-metrics-service".

Verification

1. In the OpenShift Container Platform web console, navigate to Observe Targets.

2. In the Label filter field, enter the following labels to filter the metrics targets for each operand:

   $ service=external-secrets-operator-controller-manager-metrics-service

3. Confirm that the Status column shows Up for the external-secrets-operator.

Procedure

1. In the OpenShift Container Platform web console, navigate to Observe Metrics.

2. In the query field, enter the following PromQL expressions to query the External Secrets Operator for Red Hat OpenShift metric:

   {job="external-secrets-operator-controller-manager-metrics-service"}

Procedure

1. Create the ClusterRoleBinding resource required for granting permissions to access metrics:

   1. Create the clusterrolebinding-external-secrets.yaml YAML file:

      The following example shows a clusterrolebinding-external-secrets.yaml file.

      apiVersion: rbac.authorization.k8s.io/v1
      kind: ClusterRoleBinding
      metadata:
        labels:
          app: external-secrets
        name: external-secrets-allow-metrics-access
      roleRef:
        apiGroup: rbac.authorization.k8s.io
        kind: ClusterRole
        name: external-secrets-operator-metrics-reader
      subjects:
        - kind: ServiceAccount
          name: external-secrets
          namespace: external-secrets
        - kind: ServiceAccount
          name: external-secrets-cert-controller
          namespace: external-secrets
        - kind: ServiceAccount
          name: external-secrets-webhook
          namespace: external-secrets

   2. Create the ClusterRoldeBinding custom resource by running the following command:

      $ oc apply -f clusterrolebinding-external-secrets.yaml

2. Create the ServiceMonitor CR:

   1. Create the servicemonitor-external-secrets.yaml YAML file:

      apiVersion: monitoring.coreos.com/v1
      kind: ServiceMonitor
      metadata:
        labels:
          app: external-secrets
        name: external-secrets-metrics-monitor
        namespace: external-secrets
      spec:
        endpoints:
          - interval: 60s
            path: /metrics
            port: metrics
            scheme: http
            scrapeTimeout: 30s
        namespaceSelector:
          matchNames:
            - external-secrets
        selector:
          matchExpressions:
            - key: app.kubernetes.io/name
              operator: In
              values:
                - external-secrets
                - external-secrets-cert-controller
                - external-secrets-webhook
            - key: app.kubernetes.io/instance
              operator: In
              values:
                - external-secrets
            - key: app.kubernetes.io/managed-by
              operator: In
              values:
                - external-secrets-operator

   2. Create the ServiceMonitor CR by running the following command:

      $ oc apply -f servicemonitor-external-secrets.yaml

      After the ServiceMonitor CR is created, the user workload Prometheus instance begins metrics collection from the External Secrets Operator for Red Hat OpenShift operands. The collected metrics are labeled with job="external-secrets",job="external-secrets-cainjector", and job="external-secrets-webhook".

Verification

1. In the OpenShift Container Platform web console, navigate to Observe Targets.

2. In the Label filter field, enter the following labels to filter the metrics targets for each operand:

   $ service=external-secrets

   $ service=external-secrets-cert-controller-metrics

   $ service=external-secrets-webhook

3. Confirm that the Status column shows Up for the external-secrets, external-secrets-cert-controller and external-secrets-webhook.

Procedure

1. In the OpenShift Container Platform web console, navigate to Observe Metrics.

2. In the query field, enter the following PromQL expressions to query the External Secrets Operator for Red Hat OpenShift operands metric for each operand:

   {job="external-secrets"}

   {job="external-secrets-webhook"}

   {job="external-secrets-cert-controller-metrics"}

Verification

1. The External Secrets Operator pod is redeployed. Verify that the log level of the External Secrets Operator for Red Hat OpenShift is updated by running the following command:

   $ oc set env deploy/external-secrets-operator-controller-manager -n external-secrets-operator --list | grep -e OPERATOR_LOG_LEVEL -e container

   The following example verifies that the log level of the External Secrets Operator for Red Hat OpenShift is updated.

   # deployments/external-secrets-operator-controller-manager, container manager
   OPERATOR_LOG_LEVEL=2

2. Verify that the log level of the External Secrets Operator for Red Hat OpenShift is updated by running the oc logs command:

   $ oc logs -n external-secrets-operator -f deployments/external-secrets-operator-controller-manager -c manager

Procedure

1. Edit the ExternalSecretsConfig CR by running the following command:

   $ oc edit externalsecretsconfigs.operator.openshift.io cluster

2. Set the log level value by editing the spec.appConfig.logLevel section:

   apiVersion: operator.openshift.io/v1alpha1
   kind: ExternalSecretsConfig
   ...
   spec:
     appConfig:
       logLevel: <log_level> 

   1

   1

   Supports the value range of 1-5. The log level gets mapped to the following operand support levels:

   • 1 - warnings
   • 2 - error logs
   • 3 - info logs
   • 4 and 5 - debug logs

3. Save your changes and exit the editor.

Procedure

1. Edit the ExternalSecretsConfig custom resource by running the following command:

   $  oc edit externalsecretsconfigs.operator.openshift.io cluster

2. Configure cert-manager by editing the spec.controllerConfig.certProvider.certManager section as follows:

   apiVersion: operator.openshift.io/v1alpha1
   kind: ExternalSecretsConfig
   ...
   spec:
     controllerConfig:
       certProvider:
         certManager:
           injectAnnotations: "true"
           issuerRef:
             name: <issuer_name>
             kind: <issuer_kind>
             group: <issuer_group>
           mode: Enabled

   where:

   injectAnnotation

   Must be set to true when enabled.

   name

   Specifies the name of the issuer object referenced in ExternalSecretsConfig.

   kind

   Specifies the API issuer. Can be set to either Issuer or ClusterIssuer.

   group

   Specifies the API issuer group. The group name must be cert-manager.io.

   mode

   Must be set to Enabled. This is an immutable field and cannot be modified once it is configured.

3. Save your changes.

4. After you update the cert-manager configurations in the externalsecretsconfig.operator.openshift.io object, you must manually delete external-secrets-cert-controller deployment by running the following command. This prevents performance degradation of the external-secrets application.

   $ oc delete deployments.apps external-secrets-cert-controller -n external-secrets

5. Optionally, you can delete other resources created for the cert-controller by running the following commands:

   $ oc delete clusterrolebindings.rbac.authorization.k8s.io external-secrets-cert-controller

   $ oc delete clusterroles.rbac.authorization.k8s.io external-secrets-cert-controller

   $ oc delete serviceaccounts external-secrets-cert-controller -n external-secrets

   $ oc delete secrets external-secrets-webhook -n external-secrets

Procedure

1. Edit the ExternalSecretsConfig custom resource by running the following command:

   $  oc edit externalsecretsconfigs.operator.openshift.io cluster

2. Edit the spec.plugins.bitwardenSecretManagerProvider section as follows to enable the Bitwarden Secrets Manager:

   apiVersion: operator.openshift.io/v1alpha1
   kind: ExternalSecretsConfig
   ...
   spec:
     plugins:
       bitwardenSecretManagerProvider:
         mode: Enabled
         secretRef:
           name: <secret_object_name>

   where:

   name

   The name of the secret containing the certificate key pair for the plugin. The key name in the secret for the certificate must be tls.crt. The key name for the private key must be tls.key. The key name for the Certificate Authority (CA) certificate key name must be ca.crt. Configuring the secret is optional when the cert-manager certificate provider is configured.

3. Save your changes and exit the editor.
4. If you disable the plugin the following resources must be deleted manually by running the following commands:

Procedure

1. Edit the ExternalSecretsConfig CR by running the following command:

   $ oc edit externalsecretsconfigs.operator.openshift.io cluster

2. Add the annotations field under spec.controllerConfig as follows:

   apiVersion: operator.openshift.io/v1alpha1
   kind: ExternalSecretsConfig
   metadata:
     name: cluster
   spec:
     controllerConfig:
       annotations:
         prometheus.io/scrape: "true"
         example.com/environment: "production"

Verification

1. Verify that annotations are applied to the external-secrets deployment by running the following command:

   $ oc get deployment external-secrets -n external-secrets -o jsonpath='{.metadata.annotations}' | jq .

   The output should include the custom annotations you specified.

2. Verify that annotations are applied to the pod template by running the following command:

   $ oc get deployment external-secrets -n external-secrets -o jsonpath='{.spec.template.metadata.annotations}' | jq .

   The output should include the custom annotations you specified.

3. Verify that annotations are applied to other managed resources such as Services by running the following command:

   $ oc get service external-secrets-webhook -n external-secrets -o jsonpath='{.metadata.annotations}' | jq .

   The output should include the custom annotations you specified.

Procedure

1. Edit the ExternalSecretsConfig CR by running the following command:

   $ oc edit externalsecretsconfigs.operator.openshift.io cluster

2. Add the componentConfigs field under spec.controllerConfig as follows:

   apiVersion: operator.openshift.io/v1alpha1
   kind: ExternalSecretsConfig
   metadata:
     name: cluster
   spec:
     controllerConfig:
       componentConfigs:
         - componentName: ExternalSecretsCoreController
           deploymentConfigs:
             revisionHistoryLimit: 5
         - componentName: Webhook
           deploymentConfigs:
             revisionHistoryLimit: 3

   where

   spec.controllerConfig.componentConfigs.componentName.deploymentConfigs.revisionHistoryLimit

   Specifies the number of old ReplicaSet objects to retain for rollback. The value must be at least 1 to ensure rollback capability. The maximum value is 50. If not specified, the default is 10.

Procedure

1. Edit the ExternalSecretsConfig CR by running the following command:

   $ oc edit externalsecretsconfigs.operator.openshift.io cluster

2. Add the overrideEnv field under the desired component in the spec.controllerConfig.componentConfigs stanza as follows:

   apiVersion: operator.openshift.io/v1alpha1
   kind: ExternalSecretsConfig
   metadata:
     name: cluster
   spec:
     controllerConfig:
       componentConfigs:
         - componentName: ExternalSecretsCoreController
           overrideEnv:
             - name: Example
               value: "4"

   where

   spec.controllerConfig.componentConfigs.overrideEnv.name

   Specifies the name of the environment variable. Environment variable names starting with HOSTNAME, KUBERNETES_, or EXTERNAL_SECRETS_ are reserved and are not allowed.

   spec.controllerConfig.componentConfigs.overrideEnv.value

   Specifies the value of the environment variable.

Procedure

1. Log in to the OpenShift Container Platform web console.

2. Uninstall the External Secrets Operator for Red Hat OpenShift using the following steps:

   1. Navigate to Ecosystem Installed Operators.
   2. Click the Options menu next to the External Secrets Operator for Red Hat OpenShift entry and click Uninstall Operator.
   3. In the confirmation dialog, click Uninstall.

Procedure

1. Log in to the OpenShift Container Platform web console.

2. Remove the deployments of the external-secrets application components in the external-secrets namespace:

   1. Click the Project drop-down menu to see a list of all available projects, and select the external-secrets project.
   2. Navigate to Workloads Deployments.
   3. Select the deployment that you want to delete.
   4. Click the Actions drop-down menu, and select Delete Deployment to see a confirmation dialog box.
   5. Click Delete to delete the deployment.

3. Remove the custom resource definitions (CRDs) that were installed by the External Secrets Operator using the following steps:

   1. Navigate to Administration CustomResourceDefinitions.
   2. Choose external-secrets.io/component: controller from the suggestions in the Label field to filter the CRDs.

   3. Click the Options menu next to each of the following CRDs, and select Delete Custom Resource Definition:

      • ACRAccessToken
      • ClusterExternalSecret
      • ClusterGenerator
      • ClusterPushSecret
      • ClusterSecretStore
      • ECRAuthorizationToken
      • ExternalSecret
      • GCRAccessToken
      • GeneratorState
      • GithubAccessToken
      • Grafana
      • MFA
      • Password
      • PushSecret
      • QuayAccessToken
      • SecretStore
      • SSHKey
      • STSSessionToken
      • UUID
      • VaultDynamicSecret
      • Webhook

4. Remove the external-secrets-operator namespace using the following steps:

   1. Navigate to Administration Namespaces.
   2. Click the Options menu next to the External Secrets Operator and select Delete Namespace.
   3. In the confirmation dialog, enter external-secrets-operator in the field and click Delete.

Procedure

1. Delete the deployments of the external-secrets application components in the external-secrets namespace by running the following command:

   $ oc delete deployment -n external-secrets -l app=external-secrets

2. Delete the custom resource definitions (CRDs) that were installed by the External Secrets Operator by running the following command:

   $ oc delete customresourcedefinitions.apiextensions.k8s.io -l external-secrets.io/component=controller

3. Delete the external-secrets-operator namespace by running the following command:

   $ oc delete project external-secrets-operator

Procedure

1. Find your community Operator’s namespace by running the following command:

   $ oc get operatorconfigs.operator.external-secrets.io -A

   The following is an example of finding the namespace:

   NAMESPACE             NAME        AGE
   external-secrets      cluster     9m18s

2. Delete the operatorconfig custom resrouce (CR) by running the following command:

   $ oc delete operatorconfig <config_name> -n <operator_namespace>

Verification

1. To verify that the operatorconfig CR is deleted, run the following command:

   $ oc get operatorconfig -n <operator_namespace>

   The command must return no resource found.

2. To verify that the old webhooks are deleted, run the following commands:

   $ oc get validatingwebhookconfigurations | grep external-secrets

   $ oc get mutatingwebhookconfigurations | grep external-secrets

   The commands must return no results.

Procedure

1. Create an externalsecretsconfig file by defining a YAML file with the following content:

   apiVersion: operator.openshift.io/v1alpha1
   kind: ExternalSecretsConfig
   metadata:
     labels:
       app.kubernetes.io/name: cluster
     name: cluster
   spec:
     appConfig:
       logLevel: 1
     controllerConfig:
       networkPolicies:
         - componentName: ExternalSecretsCoreController
           egress:
             - {}
           name: allow-external-secrets-egress
     plugins: {}

2. Create the ExternalSecretsConfig object by running the following command:

   $ oc create -f externalsecretsconfig.yaml

1. To verify that the external-secrets pods are in a running state, run the following command:

   $ oc get pods -n external-secret

   The following is example output that the external-secrets pods are in a running state.

   NAME                                          READY        STATUS        RESTARTS     AGE
   bitwarden-sdk-server-5b4cf48766-w7zp7         1/1          Running       0            5m
   external-secrets-5854b85dd5-m6zf9             1/1          Running       0            5m
   external-secrets-webhook-5cb85b8fdb-6jtqb     1/1          Running       0            5m

2. To verify that the SecretStore CR is present, run the following command:

   $ oc get secretstores.external-secrets.io -A

   The following is example output from validating that the SecretStore is present:

   NAMESPACE               NAME                         AGE         STATUS      CAPABILITIES    READY
   external-secrets-1      gcp-store                    18min       Valid       ReadWrite       True
   external-secrets-2      aws-secretstore              11min       Valid       ReadWrite       True
   external-secrets        bitwarden-secretsmanager     20min       Valid       Readwrite       True

3. To verify that the ExternalSecret CR is present, run the following command:

   $ oc get externalsecrets.external-secrets.io -A

   The following is example output from validating that the SecretStore is present:

   NAMESPACE             NAME                    STORE                      REFRESH INTERVAL    STATUS          READY
   external-secrets-1    gcp-externalsecret      gcp-store                  1hr                 SecretSynced    True
   external-secrets-2    aws-external-secret     aws-secret-store           1hr                 SecretSynced    True
   external-secrets      bitwarden               bitwarden-secretsmanager   1hr                 SecretSynced    True

4. To verify that the SecretStore is apiVersion: external-secrets.io/v1, run the following command:

   $ oc get secretstores.external-secrets.io -n external-secrets-1 gcp-store -o yaml

   The following is example output that the SecretStore is apiVersion: external-secrets.io/v1.

   apiVersion: external-secrets.io/v1
   kind: SecretStore
   metadata:
     creationTimestamp: "2025-10-27T11:38:19Z"
     generation: 1
     name: gcp-store
     namespace: external-secrets-1
     resourceVersion: "104519"
     uid: 7bccb0cc-2557-4f4a-9caa-1577f0108f4b
   spec:
   .
   .
   .
   status:
     capabilities: ReadWrite
     conditions:
     - lastTransitionTime: "2025-10-27T11:38:19Z"
       message: store validated
       reason: Valid
       status: "True"
       type: Ready

5. To verify that the ExternalSecret is apiVersion: external-secrets.io/v1, run the following command:

   $ oc get externalsecrets.external-secrets.io -n external-secrets-1 gcp-externalsecret -o yaml

   The following is example output that the ExternalSecret is apiVersion: external-secrets.io/v1.

   apiVersion: external-secrets.io/v1
   kind: ExternalSecret
   metadata:
     creationTimestamp: "2025-10-27T11:39:03Z"
     generation: 1
     name: gcp-externalsecret
     namespace: external-secrets-1
     resourceVersion: "104532"
     uid: 93a3295a-a3ad-4304-90e1-1328d951e5fb
   spec:
   .
   .
   .
   status:
     binding:
       name: k8s-secret-gcp
     conditions:
     - lastTransitionTime: "2025-10-27T11:39:03Z"
       message: secret synced
       reason: SecretSynced
       status: "True"
       type: Ready
     refreshTime: "2025-10-27T12:13:15Z"
     syncedResourceVersion: 1-f47fe3c0b255b6dd8047cdffa772587bb829efe7a1cb70febeda2eb2