Open adriansuarez opened 4 months ago
This is great. I understand the security implication here. And I really appreciate the time and effort in this PR!
One question, shouldn't the controller be namespaced in such a way so that is only watches and acts on a single namespace? I feel a namespaced controller is really the heart of the conversation. If the controller is limited to a namespace, it should not create, or even be aware, of resources outside of its own namespace. Instead, namespace the controller, and add additional controllers to different namespaces as needed.
I personally use the tf-operator in a larger platform and name-spacing is a little harder to manage, but I can definitely see why it would be appealing.
I love the helper functions and the label prefix, these were much needed improvements! But what do you think of having the option to make the controller "namespace" aware instead or forcing all the tasks into a namespace?
I have to refresh my memory on this, but I think the motivation for this is that my organization's policy was restricting cluster-scoped access to resources like Secrets
and ConfigMaps
, which is a security concern to grant at a wide scope, but it was not a security concern to grant cluster-scoped access to CRDs owned by a controller.
The deployment scenario that this change was supposed to enable is one where a particular service owner in a multi-tenant cluster would have its own namespace (separate from the Terraform
controller), and would be able to make the Terraform
controller provision resources on its behalf by creating a Terraform
CR in its own namespace.
This change allows the Terraform task pod and other resources to be created in the namespace that the controller is running in.
This should address #173.