Open lnalex opened 4 years ago
This would be immensely helpful for software platforms that manage AWS resources inside a customer-owned AWS account. Such platforms really need a better way than tagging to say "this is an externally managed resource, you should really delete it via the external platform's API or management UI rather than deleting it directly from within the AWS portal."
Promoting a set of well-known tags and using them to warn the user in the interactive web UI would be good too, e.g. if a user tries to delete a suitably-tagged resource in the Portal I'd love to see a pop-up like:
"This resource is tagged with ManagedBy=FooCo. See {{ManagedBy/ManageResourceURI}} for details on the management of this resource. Use {{ManagedBy/DeleteURI}} to delete this resource instead of deleting it via the AWS portal."
But delete-protection would sure be a big forward step.
Azure has a general concept of a Lock. Allowing you to set any resource to be locked from deletion. You can then configure who can control that at iam.
GCP has the concept of a lien (https://cloud.google.com/resource-manager/docs/project-liens), though theirs is at the project level. Something like this for EKS would be very useful.
please take this seriously aws
Looking forward to have this feature in AWS EKS too
Community Note
Tell us about your request What do you want us to build?
Add an option to enable some form of termination/deletion protection for EKS clusters, similar to the EC2 termination protection and RDS deletion protection features: https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/terminating-instances.html#Using_ChangingDisableAPITermination https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_DeleteInstance.html#USER_DeleteInstance.DeletionProtection
Which service(s) is this request for? EKS
Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?
EKS clusters in production use are highly critical components, arguably on the same level as a production database. Adding an additional layer of protection can be helpful in preventing accidental deletion of an entire Kubernetes control plane, particularly when done through the SDK or CLI which does not include a confirmation step like the AWS Console does.
IAM policies can be used to achieve some level of deletion protection, but is not necessarily a straightforward method when large numbers of entities and policies exist in an account.
Are you currently working around this issue? How are you currently solving this problem? N/A
Additional context Anything else we should know? N/A
Attachments If you think you might have additional information that you'd like to include via an attachment, please do - we'll take a look. (Remember to remove any personally-identifiable information.)