For context, I'm using the recommended approach in https://docs.garden.io/guides/namespaces and it's great. However, when a single cluster is used to host multiple namespaces (one per developer, or one per preview deployment), there are also resources that are still global to the cluster. In my case, this includes - ingress - cert-manager When I want to tear down a preview environment or a developer wants to clear our their setup, how do I prevent these cluster level resources from getting removed? Would it makes sense to create unique garden environments for these modules and then template these modules to be disabled for all other environments? That would require deploying them separately, such as

garden deploy --env=devGlobal

, but it would mean when a dev does

garden delete environment dev

it wouldn't try to remove them.

Hi @chilly-waitress-62592 👋 I would set aside a namespace whatever you use for ingress and cert-manager as you suggest. Is there a reason why you'd want to explicitly disable them for some namespaces? I'd use Kubernetes' native RBAC for blocking access to anything you don't want devs to get to.

I could be misunderstanding. Specifying a namespace on ingress and cert-manager doesn't prevent them from trying to be created when a dev does

garden deploy --env=dev

. Secondly, when a dev tears down their environment it will attempt to delete them as well

garden delete environment --env=dev

. RBAC will prevent them from altering the installs, but garden will throw a bunch of error messages due to insufficient permissions. Hence declaring them as separate garden environments and adding a conditional to the

disable

flag.

Maybe we should get on a video call to discuss because I don't want you to feel misunderstood! If you'd appreciate something like that, just let me know and I'll make time. Let me see if I can clarify from my side: for cluster-wide things you'd always want running that would generally be owned by an org's Platform Team --> DevOps team --> DevOps person in order of org-size and maturity. So you'd want those cluster-wide things either deployed out-of-band or if using Garden to deploy, they'd be in their own Garden project. Anything handed to dev teams would be their own project with their own modules. One should not need to have them mixed together, in other words.

Sorry, just saw this latest response. Thank you for the video call offer! Okay, so the suggestion is use a separate garden project. That makes sense. Do you think anything would break regarding

ingressClass

and

tlsCertificates

settings and setting

ingress

on container modules? Currently the extra environment approach is working, for what it's worth.

Hey @chilly-waitress-62592 hope everything is going good. Have you tried having 2 separate Garden configurations? For example; if you are the one who's managing most of the configuration side of Garden (prerequisites to make everything work) I would have a separate project.garden.yaml to deploy all of those configurations (

cert-manager/ingress

) and maybe protect those namespaces with RBAC as well. Then on the Developer side they only would have access to the application part which might be in a different namespace (${user.name}) or something like that and they would have permissions to be able to deploy/tear down the environment as they want. ------- Notes: - In this case probably is more worthy to have a wildcard certificate, if you tear-down/create those certificates too often you will likely get hit by the restrictions of letsencrypt (Rates). - I would setup the wildcard cert as part of your management layer Garden configuration and make that your developers only use the secret. - As far of the ingressClass I don't see it having a problem as you will have your ingress setup always so then a developer deploys a new env everything should be already there and they are just basically consuming those resources. ---- Recommendations: 1. Do a little PoC of this setup, don't go directly and change everything. 2. Try to start with a tiny configuration in a different cluster to make sure you don't affect nothing, try to use the dual-garden-project approach and see how it works for you. Good luck!🌸

Thanks friend, I will review