external-secrets

External Secrets

External Secrets is an operator to fetch content from secure stores and synthesize that state into a Kubernetes Secret.

This sample uses a fake SecretStore (to avoid external infrastructure) and ExternalSecret to create a binding Secret. The Spring PetClinic workload and MySQL database are independently bound to the ExternalSecret.

Setup

If not already installed, install the ServiceBinding CRD and controller, and the External Secrets Operator.

NOTE: Provisioned Service support was added to External Secrets in the v0.8.2 release, prior versions are not compatible.

This sample uses Carvel Kapp, rather than kubectl to install and watch the sample become ready.

Deploy

Apply the ExternalSecret, SecretStore, PetClinic workload, MySQL service and connect them with ServiceBindings:

kapp deploy --app servicebinding-sample-external-secrets -f samples/external-secrets

When you are done with this sample, all resources in the deploy can be removed by running:

kapp delete --app servicebinding-sample-external-secrets

When prompted, you can review the resource about to be created (updated or deleted) and approve them, or add --yes to the above commands. Resources are tracked between deploys, if a resource is removed from the file it will be removed from the cluster on the next deploy.

Kapp will monitor the health of the resources it creates and exit when they become ready, or fail to become ready. The startup logs from our workload will also be displayed.

Understand

Inspect the ExternalSecret:

kubectl describe externalsecrets.external-secrets.io eso-example

If the ExternalSecret is working, a new Secret is created and the name of that Secret is reflected on the status. The describe output will contain:

...
Status:
  Binding:
    Name:  eso-example-db
...

The ServiceBinding for the PetClinic workload references the ExternalSecret resource to discover the binding Secret exposed. The Spring PetClinic sample goes into deeper detail for how a Spring Boot workload can consume service bindings at runtime.

kubectl describe servicebindings.servicebinding.io eso-example

Spec:
  Service:
    API Version:  external-secrets.io/v1beta1
    Kind:         ExternalSecret
    Name:         eso-example-db

Additional, the ServiceBinding for the MySQL database projects environment variables since the MySQL image is not natively aware of service bindings.

kubectl describe servicebindings.servicebinding.io eso-example-db

...
Spec:
  Env:
  - Key:   username
    Name:  MYSQL_USER
  - Key:   password
    Name:  MYSQL_PASSWORD
  - Key:   database
    Name:  MYSQL_DATABASE
...

Play

A key advantage of referencing a Provisioned Service resources over directly referencing the binding Secret, is that the name of the Secret referenced can be updated at any time, bound workloads will automatically receive the updated Secret.

Try updating the ExternalSecret to manage the Secret under a different name.

kubectl patch externalsecrets.external-secrets.io eso-example-db --type json --patch '[{"op": "replace", "path": "/spec/target/name", "value":"my-new-super-duper-secret"}]'

Look at the ExternalSecret status and the Deployments to see that they have been updated to use the my-new-super-duper-secret secret.