What problem are you facing?
Crossplane has supported generating and writing connection details to Kubernetes secrets since its first release.
Connection details are the details needed to connect to a resource. For example you need to know an RDS instance's address, username, and password to connect to its default database. Connection details are often sensitive.
Claims, XRs, and MRs all have a spec.writeConnectionSecretToRef field. When you specify this field, Crossplane writes connection details to the named Kubernetes secret.
Crossplane v1.7.0 (release notes) added alpha support for "external secret stores". External secret stores allow Crossplane to write connection details to an external secret store, like HashiCorp Vault. You can read the design document here.
You configure Crossplane to write connection details to an external secret store using the spec.publishConnectionDetailsTo field of a claim, XR, or MR. Crossplane's external secret stores are write-only. You can't read secrets, for example provider credentials, from an external secret store. Adding support for reading from external secret stores is tracked in #2985.
As of Crossplane v1.15.0 (two years later), external secret stores are still an alpha feature. They're off by default, and must be enabled using the --enable-external-secret-stores flag.
At the time we designed Crossplane's external secret stores:
- We couldn't find any existing projects that could push Kubernetes secrets to an external store like Vault. Projects like https://external-secrets.io/ were early, and only supported pulling secrets.
- Some Crossplane users had expressed that they could never write connection details to a Kubernetes secret, which they deemed too insecure.
Since then, External Secrets Operator has added support for pushing Kubernetes secrets to external secret stores using a PushSecret resource. You can read about that here.
How could Crossplane help solve your problem?
I propose we deprecate and remove Crossplane's native external secret store support. Removing external secret store support means Crossplane would only be able to write connection details to a Kubernetes secret.
You could still write connection details to external secret stores like Vault by pairing Crossplane with an https://external-secrets.io PushSecret.
I believe External Secrets Operator can already do everything Crossplane's native external secret store support can do, and more. It supports more secret stores than Crossplane does. It also supports pulling external secrets, e.g. for provider credentials.
Dropping support for native external secret stores allows us to focus on other areas of the project, instead of spending our time and energy supporting things that External Secrets Operator can already do.
I believe the only remaining argument for Crossplane maintaining native external secret store support is to avoid ever writing connection details to Kubernetes secrets. While I believe this is a real constraint for some people, I don't think it's enough people to warrant Crossplane building and maintaining its own external secret store support.
Here are a few issues and articles that make the case that there's diminishing security returns in trying to completely avoid Kubernetes secrets:
I think the assertion that relatively few people need to strictly avoid Kubernetes secrets is backed up by the fact that there's been little community demand for and engagement with Crossplane's native external secret stores:
What problem are you facing?
Crossplane has supported generating and writing connection details to Kubernetes secrets since its first release.
Connection details are the details needed to connect to a resource. For example you need to know an RDS instance's address, username, and password to connect to its default database. Connection details are often sensitive.
Claims, XRs, and MRs all have a
spec.writeConnectionSecretToReffield. When you specify this field, Crossplane writes connection details to the named Kubernetes secret.Crossplane v1.7.0 (release notes) added alpha support for "external secret stores". External secret stores allow Crossplane to write connection details to an external secret store, like HashiCorp Vault. You can read the design document here.
You configure Crossplane to write connection details to an external secret store using the
spec.publishConnectionDetailsTofield of a claim, XR, or MR. Crossplane's external secret stores are write-only. You can't read secrets, for example provider credentials, from an external secret store. Adding support for reading from external secret stores is tracked in #2985.As of Crossplane v1.15.0 (two years later), external secret stores are still an alpha feature. They're off by default, and must be enabled using the
--enable-external-secret-storesflag.At the time we designed Crossplane's external secret stores:
Since then, External Secrets Operator has added support for pushing Kubernetes secrets to external secret stores using a
PushSecretresource. You can read about that here.How could Crossplane help solve your problem?
I propose we deprecate and remove Crossplane's native external secret store support. Removing external secret store support means Crossplane would only be able to write connection details to a Kubernetes secret.
You could still write connection details to external secret stores like Vault by pairing Crossplane with an https://external-secrets.io
PushSecret.I believe External Secrets Operator can already do everything Crossplane's native external secret store support can do, and more. It supports more secret stores than Crossplane does. It also supports pulling external secrets, e.g. for provider credentials.
Dropping support for native external secret stores allows us to focus on other areas of the project, instead of spending our time and energy supporting things that External Secrets Operator can already do.
I believe the only remaining argument for Crossplane maintaining native external secret store support is to avoid ever writing connection details to Kubernetes secrets. While I believe this is a real constraint for some people, I don't think it's enough people to warrant Crossplane building and maintaining its own external secret store support.
Here are a few issues and articles that make the case that there's diminishing security returns in trying to completely avoid Kubernetes secrets:
I think the assertion that relatively few people need to strictly avoid Kubernetes secrets is backed up by the fact that there's been little community demand for and engagement with Crossplane's native external secret stores: