[jrockway]

Deletion is typically specified by an immutable finalizer on the resource. For example, you can create a StorageClass that saves your PersistentVolume when you delete the PersistentVolumeClaim, and you can't change the class of a claim, so even if your templating goes haywire and deletes your volume claim, the actual data is safe and can be recovered. I have to imagine that any API that lets you create things like RDS instances would have similar protection. (You might think that the k8s world is very mutable, but there are some immutable things hanging around. For cases exactly like this.)

I don't use AWS so I didn't look into this thoroughly, but the word "finalizer" does show up in the code frequently:

    // MarkManaged places the supplied resource under the management of ACK.
    // What this typically means is that the resource manager will decorate the
    // underlying custom resource (CR) with a finalizer that indicates ACK is
    // managing the resource and the underlying CR may not be deleted until ACK
    // is finished cleaning up any backend AWS service resources associated
    // with the CR.

I dunno how good it is, but clearly they've thought about it. Test it before you invest billions of dollars into it, though.

[dilyevsky]

Finalizers dont do much for safety. They are simply there to ensure controller (in this case ACK) won’t miss the deletion event and leave the resource dangling. To actually prevent object from being deleted you need a validation webhook

[robszumski]

An interesting part of the Operator Lifecycle Manager (OLM) is the capability to scaffold webhooks for Operators, rotate their secrets, etc to make this type protection easy for everyone to provide. All you need to do is bring your validation logic specific to the app.

https://olm.operatorframework.io/docs/advanced-tasks/adding-...

[an_opabinia]

Kubernetes complexity: The amount of indirection for “you must write a --force flag to delete something” is astounding.

[DanielDent]

What this describes is a mechanism for k8s to delete underlying resources prior to removing them from k8s.

E.g. before completely removing the CRD representing an S3 bucket, this provides a mechanism for that S3 bucket to be deleted from AWS systems.

Which I think is the opposite of what you were hoping.