Consider supporting connectionSecretDeletionPolicy

[hasheddan]

What problem are you facing?

Currently, managed resources support setting deletionPolicy in the spec to either Delete (default) or Orphan. This allows users to remove a managed resource from the Kubernetes API without it being deleted externally. However, when a managed resource is deleted with deletionPolicy: Orphan, its connection Secret is still cleaned up in the cluster. This makes sense in most cases (similar to how it usually makes sense to delete the infrastructure externally when the managed resource is deleted), but it does make it inconvenient to migrate resources from one cluster to another while preserving all connection details. Some external APIs only return full connection details when the resource is initially created, so later "importing" an existing external resource into the cluster will not provide the full connection information.

How could Crossplane help solve your problem?

Introducing a common connectionSecretDeletionPolicy (or nesting a deletionPolicy under writeConnectionSecretToRef / publishConnectionDetails) to all managed resources will make this behavior configurable. By default, the policy should be Delete, but some cases, such as those listed above would be candidates for using Orphan. I imagine this functionality will become even more useful once additional Secret "sinks" are supported, as described in crossplane/crossplane#2366.

[negz]

Is there any chance we could get away with just lumping this in with the existing deletionPolicy: Orphan? i.e. Always leave and orphan the connection secret if the managed resource is orphaned?

[hasheddan]

@negz possibly, if a user wanted the connection secret cleaned up after deletionPolicy: Orphan they could just manually delete it. We could always change that to be the default behavior and then add the additional field in the future, making the behavior such that secrets are orphaned by default if deletionPolicy: Orphan unless otherwise overridden by the future field.

[negz]

Definitely worth considering. I don't feel strongly here - just looking for places to keep our API a little simpler. I like the idea of being able to handle this simply (i.e. by orphaning secrets) now, while leaving an avenue over to control that behaviour in future.

[muvaf]

Reusing deletionPolicy makes sense to me too with the default of Delete.

[luis-alen]

Some external APIs only return full connection details when the resource is initially created, so later "importing" an existing external resource into the cluster will not provide the full connection information.

Facing this issue with provider-sql here. When a resource such as a MySQL user or PostgreSQL role is deleted with deletionPolicy: Orphan and gets recreated, writeConnectionSecretToRef will generate an empty secret :(

It'd be really nice if deletionPolicy would be inherited/reused for the secret.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.