To date, Crossplane has enabled us to write ‘secrets’ to a Crossplane in-cluster Kubernetes Secret. These are resource/provider specific, but typically include things like username, password, host address, port, etc.. These secrets stored in the Crossplane cluster can then be retrieved by platform and application engineers to further configure a service and/or by Crossplane to automatically configure a ProviderConfig.
But what if you wanted to provision a K8s cluster, a managed database service, and a pod in that provisioned cluster that needs to authenticate to the managed database, without manual configuration? The pod isn’t running in the Crossplane cluster, so it can’t refer to the secret created for the database.
In this case, we need the database connection secrets in the provisioned cluster. We can achieve this with Provider-Kubernetes with the spec.references.patchesFrom method. We essentially read from the secret in the Crossplane cluster, patch it into a Secret resource manifest, and apply it via Provider-Kubernetes to the provisioned cluster. Voila, we have the secret in the remote cluster and the pod can mount it.
Now for the second ‘but’. What if we didn’t want to use Kubernetes Secrets at all? What if we needed the secret available outside of a Kubernetes cluster? In this case, we could rely on an external secret Vault. This is where External Secret Stores (ESS) comes in. With ESS, we change from spec.writeConnectionSecretToRef to spec.publishConnectionDetailsTo. With an extensible plugin architecture, we are able to incorporate any external secret vault. As a bonus, a K8s cluster can be an external store as well. This means we can publish connection details as vault stored secrets and/or as K8s Secrets in any remote cluster.
Rather than reproduce the great work of Hasan Turken and Ezgi Demirel, I will provide some links to it here. Both the design doc and quick start guide are excellent resources.
Check out these great new additions to Crossplane and safely unlock connection details automation.