Namespacing limitations #309
artem-nefedov
started this conversation in
General
Replies: 1 comment 8 replies
-
Our design is very serious about security. We do not, and will not, violate the namespace boundary to make TF-controller secure and trustworthy. That's our principle. Every service account and secret must belong to a specific namespace. Runner pods also belong to the namespace too.
Trust me - it's a bit hard to deal with this namespace scope initially, but it will pay you off when it prevents bad (security) things from happening. |
Beta Was this translation helpful? Give feedback.
8 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
While investigating the possibility of moving our current architecture to tf-controller, we've hit a pretty big wall because of the namespacing limitations. Specifically, 2 things in particular:
Now, we could maybe handle it somehow if instead at least output Secret could be written to a different namespace, but right now that isn't possible as well.
Our current solution is Crossplane-based, and it the overall design heavily on a large number of arbitrarily generated namespaces for various reasons. Crossplane works with that because composition claims are namespaced, and will write output Secret to the namespace they exist in, but the ProviderConfig resource referenced in composition is NOT namespaced, and it allows to use static credentials Secret from any namespace (which we only have one of). Also there are no runners.
Before proceeding further, I would like to clarify if current namespace limitations of tf-controller are there to stay, and then decide accordingly.
Beta Was this translation helpful? Give feedback.
All reactions