Allow resources to be created in controller namespace #174
Conversation
This change allows the Terraform task pod and other resources to be created in the namespace that the controller is running in.
Always include both resourceName and resourceNamespace in selector. Previously it was being omitted for backwards-compatibility, but that creates problems when there are Terraform resources in different namespaces and also in the same namespace as the controller, both having the same name. Just assume that any old resources would have been cleaned up before upgrading, and if not, force the user to manually delete them.
|
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 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 |
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.