External Secret Store is currently a beta feature of Crossplane. This feature enables us to publish connection details (Crossplane currently outputs these to a Kubernetes Secret in the Crossplane cluster) to an external vault, This then enables us to reference those secrets/connection details from a context outside of the Crossplane cluster. See this post for more on External Secret Store. But there is another interesting option when we simply need secrets from the Crossplane cluster to be available to Pods in a remote cluster.

For example, consider the following workflow: we provision a K8s cluster in a cloud provider, then provision a managed database in the cloud provider, ad then provision a Pod in the provisioned K8s cluster that needs to access that database. In that case we need the managed DB’s connection secrets available to the Pod in the remote cluster (i.e. not the Crossplane cluster). External Secret Store will enable this scenario, but it comes with some heavy lifting and if our only need is for K8s secrets for K8s resources, using Provider-Kubernetes is possibly a better option.

A unique capability of Provider-Kubernetes is its patchesFrom.fieldPath and toFieldPath (I believe this was introduced by MorningSpace). With this method, we can take values from resources in the Crossplane cluster and patch them into resources we create in the remote cluster. In the case of Secrets, we refer to the connection details secret created in the Crossplane cluster when we create something like a cloud provider managed database, and then replicate those secrets to the remote cluster. This then enables us to create a Pod in that remote cluster that can mount the Secret and authenticate to the database server.The Provider-Kubernetes repo has some examples using ConfigMaps here. I’ve posted an example using the database scenario and Secrets here.

In this case, I’m propagating the connection secret to the remote cluster so I can run a K8s Job that connects to the AWS RDS instance and creates a database. This enables me to create multiple databases within one RDS instance rather than creating an RDS instance for each DB I need. There are other ways to solve for this, but this approach was one I wanted test out. And as it turns out, it works. I’m not suggesting this specific use case and solution is the best possible. It is simply an exercise to see the concept.

The patching mechanisms built into Provider-Kubernetes are unique in comparison to all other Providers. They offer us convenient flexibility. Very cool contribution @MorningSpace.