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. Continue reading