Protecting the flux-system namespace from deletion

[Mo0rBy]

Hello!

I would like to block the ability for anyone in my team to delete the flux-system namespace, or kustomization object.
The reason I want to do this is because in the past, I myself have accidentally deleted the flux-system namespace and suffered a few stressful hours re-building all the cluster resources.

I'm guessing I can do this using an RBAC but I'm not quite sure how to go about as there are a few unknowns.

1. I am using AWS EKS and I just authenticate to the cluster using the AWS CLI through an OKTA federated account. My immediate team members authenticate in the same way. Here is a very small part of a command to show the username I am authenticated to the cluster with:

❯ kubectl auth whoami
ATTRIBUTE                                              VALUE
Username                                               kubernetes-admin
...

I'm not sure how this matches up to RBAC stuff that is pre-installed into an AWS EKS cluster.

2. What role does Flux use to install/upgrade it's resources? I believe its the "cluster-admin" role, but I'm not 100% sure. If this is the case, do I need to leave the "cluster-admin" role completely alone? Or is it still possible to restrict it from deleting the flux-system namespace? Is deletion of the namespace required when upgrading/updating Flux?
3. Is this sort of restriction a bad idea for some reason? I've literally never needed to delete the flux-system namespace for any reason, I've only ever done it accidentally and it caused me a whole world of pain, but maybe there is a scenario I've not though of.

Thanks all!

[stefanprodan]

Only the Flux CLI will ever need to delete the namespace with flux install. Best way to protect it is with a ValidatingAdmissionPolicy and a CEL expression that denies deletion unless the manager is called flux (that's the CLI).

[Mo0rBy]

I love how fast you reply @stefanprodan . I'll give this a go thanks!
Also, would it be an idea to add this as something that gets installed with flux bootstrap?

[stefanprodan]

You would add this to the policy pack that should get deployed first, after bootstrap. Example here: https://github.com/controlplaneio-fluxcd/d2-fleet/blob/main/tenants/policies.yaml

[Mo0rBy]

Sorry whats the "policy pack"? And thank you for giving that example, that helps.

I have Flux installed using the TF provider, are you saying I should have this new ValidatingAdmissionPolicy defined somewhere in the TF code?

[stefanprodan]

No, I'm saying that polices should be applied first by Flux, everything else should depend on them.