Installing the External Secrets Operator

Install External Secrets Operator for integrating external secret management systems with Automation Suite.

Note:

This step is required only if you want to store sensitive credentials in an external secret-management system.

Important:

By default, Automation Suite includes the External Secrets Operator.

If you choose not to use the bundled version, you can install your own External Secrets Operator instance by following the steps described in this section.

The External Secrets Operator (ESO) is a Kubernetes operator that integrates with external secret management systems (for example, AWS Secrets Manager, HashiCorp Vault). It reads data from external secret backends and automatically creates and synchronizes the values as native Kubernetes Secrets.

Automation Suite supports Azure Key Vault, HashiCorp Vault, and AWS Secrets Manager as external secret providers.

Adding the External Secrets Helm repository

You must add the External Secrets Helm repository to your Helm installation as follows:

helm repo add external-secrets https://charts.external-secrets.io

After adding the repository, you must update your Helm repositories to fetch the latest chart information as follows:

helm repo update

OpenShift: Configuring the Security Context Constraint

On OpenShift, the External Secrets Operator pods require permissions to run outside the default restricted UID range. You must grant the anyuid Security Context Constraint (SCC) to the ESO service accounts before installing the operator.

To configure the SCC, take the following steps:

1. Save the following in a file named eso-anyuid-role.yaml to create a Role that grants access to the anyuid Security Context Constraint:

   kind: Role
   apiVersion: rbac.authorization.k8s.io/v1
   metadata:
     name: eso-anyuid-role
     namespace: external-secrets
   rules:
     - verbs:
         - use
       apiGroups:
         - security.openshift.io
       resources:
         - securitycontextconstraints
       resourceNames:
         - anyuid
   

2. Create the Role by running the following command:

   oc apply -f eso-anyuid-role.yaml
   

3. Save the following in a file named eso-anyuid-rolebinding.yaml to create a RoleBinding that binds the Role to all three ESO service accounts:

   kind: RoleBinding
   apiVersion: rbac.authorization.k8s.io/v1
   metadata:
     name: eso-anyuid-rolebinding
     namespace: external-secrets
   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
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: Role
     name: eso-anyuid-role
   

4. Create the RoleBinding by running the following command:

   oc apply -f eso-anyuid-rolebinding.yaml
   

Important:

You must create the external-secrets namespace and apply these resources before installing the operator. If the ESO pods are already failing due to SCC violations, apply the Role and RoleBinding, then delete the failing pods to trigger re-creation.

Installing the External Secrets Operator

You must deploy the External Secrets Operator using version v0.16.2 or later. Automation Suite requires External Secrets Operator version v0.16.2 as the minimum supported version, which includes the ESO v1 APIs.

Create the namespace first (if not already created during the SCC step), then install the operator:

oc create namespace external-secrets --dry-run=client -o yaml | oc apply -f -
helm install external-secrets \
  external-secrets/external-secrets \
  -n external-secrets \
  --version 0.16.2

The External Secrets Operator requires access to the uipath namespace to function properly.

OpenShift: Creating the NetworkPolicy

On OpenShift, you must create the following NetworkPolicy to allow the API server to reach the ESO webhook:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-apiserver-to-eso-webhook
  namespace: external-secrets
spec:
  podSelector:
    matchLabels:
      app.kubernetes.io/name: external-secrets-webhook
  ingress:
  - ports:
    - port: 10250
      protocol: TCP
  policyTypes:
  - Ingress

Apply the NetworkPolicy by running the following command:

oc apply -f allow-apiserver-to-eso-webhook.yaml

Note:

Update spec.ingress[0].ports[0].port to the appropriate webhook port if your installation uses a non-default port.

Verifying the installation

After installation, you must verify that the operator pods are running as follows:

kubectl get pods -n external-secrets

You should see output similar to the following example:

NAME                                               READY   STATUS    RESTARTS   AGE
external-secrets-7d8c9b5f9f-abc12                  1/1     Running   0          30s
external-secrets-cert-controller-6d8f7b9c-def34    1/1     Running   0          30s
external-secrets-webhook-8c9d7f6e5-ghi56           1/1     Running   0          30s

If all pods display a Running status, the installation is complete.

If any pod shows CreateContainerConfigError or CrashLoopBackOff with SCC-related errors in the events, verify that the Role and RoleBinding from the SCC configuration step were applied correctly:

oc get role eso-anyuid-role -n external-secrets
oc get rolebinding eso-anyuid-rolebinding -n external-secrets
oc get events -n external-secrets --sort-by='.lastTimestamp' | grep -i scc