External Secrets Operator (ESO) Installation

External Secrets Operator (ESO) is a Secret Syncing from Vault to Kubernetes Cluster as Kubernetes Secret Resource Utility

---

External Secrets Operator (ESO) can have multiple instances dedicated to each of Workload Type Kubernetes Cluster.

Note

Instructions providing here are steps for ONE External Secrets Operator (ESO) Instance of a Kubernetes Cluster.

It is meant for you to REPEAT the steps FOR EACH of Kubernetes Clusters. Please change the configuration value accordingly.

Guided Assumptions

For this Guided Assumptions,

Will install on 🟦 Non-Production Workload and 🟥 Production Workload.

Pre-Installation

ESO Preparation

1. Create Helm Value Configurations

   Note

   All Workload Clusters can use the same Helm Values

   cat <<EOF > $BASE_WORKING_DIR/helm-values/eso-full-values.yaml
   leaderElec: true
   installCRDs: true
   
   EOF

Complete Prerequisites

Kubernetes Cluster

1. Ensure Kubernetes Namespace devsecops-system Exists

   External Secrets Operator (ESO) is installed into Namespace devsecops-system and the Helm Command below does not create it — helm upgrade --install returns Error: namespaces "devsecops-system" not found when the Namespace is missing.

   Create it with DevSecOps - Create Namespace across Kubernetes Clusters.

   Create the Namespace with its Label, not with --create-namespace

   Namespace devsecops-system carries a Pod Security Admission Label. A Namespace created by a bare kubectl create namespace, or by helm --create-namespace, inherits the Default Pod Security Admission Profile of the Kubernetes Cluster instead — and every Tool that shares devsecops-system is then admitted under a Profile that was never intended for it.

Installation

1. Add ESO Helm Repository.

   # Add Helm Repository
   helm repo add external-secrets-operator https://charts.external-secrets.io/
   helm repo update

2. Connect to Kubernetes Cluster ; i.e w/ Kubeconfig File

   Set Kubeconfig File

   export KUBECONFIG="$HOME/opstella-installation/kubeconfigs/CHANGEME_cluster.yaml"

3. Install ESO on Kubernetes Cluster.

   • Install a Helm Release with specific Helm Chart Version --version 0.19.2 (App Version: v0.19.2)

     # Install ESO Helm Release
     helm install external-secrets-operator external-secrets-operator/external-secrets --version 0.19.2 \
         --namespace devsecops-system \
         -f $HOME/opstella-installation/helm-values/eso-full-values.yaml

Post-Installation

External Secrets Operator (ESO) Testing

Note

Applies to All Workload Kubernetes Clusters

1. Connect to Kubernetes Cluster ; i.e w/ Kubeconfig File

   Set Kubeconfig File

   export KUBECONFIG="$HOME/opstella-installation/kubeconfigs/CHANGEME_cluster.yaml"

2. Get Pod Status - External Secret Operator (ESO)

   kubectl get pods -n devsecops-system

   External Secret Operator (ESO) should be `Running

   NAME                   READY   STATUS    RESTARTS   AGE
   ... (deducted)
   external-secret-operator-external-secrets-XXXXXXX-YYYY            1/1     Running   0          XdXh
   external-secret-operator-external-secrets-cert-controller-YYYYY   1/1     Running   0          XdXh
   external-secret-operator-external-secrets-webhook-XXXXXXXXX       1/1     Running   0          XdXh

3. Check which API version the CRDs serve

   kubectl get crd clustersecretstores.external-secrets.io \
     -o jsonpath='{range .spec.versions[*]}{.name}{" served="}{.served}{"\n"}{end}'

   💡 Chart 0.19.2 serves v1 only — v1beta1 is still listed in the CRD but with served=false. Anything that submits external-secrets.io/v1beta1, including Secret templates rendered by the Opstella workers, has to be updated to v1; otherwise the resource is never created and the API server reports the kind as unknown.

When Vault uses a private or self-signed certificate

The operator validates a ClusterSecretStore by calling Vault itself. With a certificate that is not issued by a publicly trusted CA, the store never becomes ready:

InvalidProviderConfig: unable to validate store: invalid vault credentials:
Get "https://vault.example.com/v1/auth/token/lookup-self":
tls: failed to verify certificate: x509: certificate signed by unknown authority

Every ExternalSecret bound to that store then reports SecretSyncedError.

Publish the CA on the cluster where ESO runs:

kubectl create configmap vault-ca --namespace vault \
  --from-file=ca.crt=/path/to/vault-ca.crt \
  --dry-run=client -o yaml | kubectl apply -f -

And point the store at it:

spec:
  provider:
    vault:
      caProvider:
        type: ConfigMap
        name: vault-ca
        key: ca.crt
        namespace: vault

Stores created by the Opstella workers need this too

The workers render ClusterSecretStore objects from the templates described in Opstella Platform Core Resources, so caProvider has to be part of that template. Adding it to an existing object instead does not survive the next reconcile.