Able to namespace deployment

[kassah]

Command

• check-image-updates
• delete
• deploy
• diff
• helm-pull
• helm-update
• list-images
• list-targets
• poke-images
• prune
• render
• seal
• validate
• version

Who are you?

William Lightning, Systems Architect at Fuel Medical Group

What do you want to do?

I want to have per namespace deployments with everything about the deployment siloed to the namespace. I want each namespace to be like a shared tenant, with no access to another tenant (even to see that they exist).

Why do you need that?

I want to be able to have least privilege for the application which in short means that there is an RBAC enforced boundary.

[kassah]

Optimally this would involve a flag in the command indicating the namespace. If that flag mismatched the deployment overrideNamespace it would refuse to continue. Result store would also be within the namespace. Any delete, validate, prune, etc would contain it's actions to within the namespace (should not be touch the namespace itself, other than to be able to read it).

The idea is it could fit entirely within the default namespaced cluster role binding of edit created with a command like:

kubectl -n ${NAMESPACE} create rolebinding deploy-access --serviceaccount=${NAMESPACE}:deploy-user --clusterrole=edit

This could also be added to the KluctlDeployment which can already be tied to a service account, this would just ensure that it could operate entirely within the namespace.