Feature Request: Add a namespace field to the git.secretRef for RepoSync CRD
jmymy opened this issue · 6 comments
Would be great to reference a git secret in another namespace so that I dont need multiple copies of a git token in a cluster that is connecting to multiple repos (or multiple folders in the same repo)
Use case:
when using a multi repo setup via RepoSync objects, I currently need to add a git token in each namespace where I define a RepoSync object. It would be better to just reference one in another namespace when using the same token again, as opposed to copying it over.
The reason it’s constrained to the same namespace is to avoid privilege escalation by tenants who only have access to specific namespaces. Otherwise anyone who could make a RepoSync would be able to exfiltrate any secret on the cluster, even if they don’t have direct access.
My counter argument would be that I should be able to set my "defense" perimeter where I choose. If no one has command line access to the cluster and everything is controlled via GitOps, and I set my controls on the git repo via codeowners, number of reviewers, etc then it should be made to happen if its committed to the repo.
This use case isnt multi tenant architectures, just a good way of breaking out how many resources a single reconciler controls and allowing other people to add namespaces without having to go through a central platform team or a root sync object to add a namespace just to add the resources for that namespace in another git folder or repo
Yeah, I get it.
The recommended way of managing namespaces in a central RootSync repo requires asking permission to create the new namespace, either by support ticket or git pull request review process. But you want to allow users to create new tenant namespaces and RepoSyncs self-service, with some defaults that are pre-approved.
You say that’s not multi-tenant, but if there are people using the cluster that don’t have cluster admin or access to make RootSyncs, those users are tenants. You just want to allow them to self-service without asking permission to make a new tenant, moving to a more “trust and audit” model than an “ask permission first” model.
Unfortunately, allowing RepoSyncs to use secrets in other namespaces won’t give that to you. It will just create a new security vulnerability. What you really need is a tenant management service with its own permission model that allows users to request and provision a set of resources. There’s lots of ways to build something like this, as a k8s operator or a separate service with its own web UI. But ConfigSync doesn’t provide this functionality out of the box today.
Fair.
In my use case though its not people that are doing the PRs but services. Was just trying to keep the service logic simplified instead of having to open multiple PRs or change files in many locations at once. Its basically a single tenant arch for a saas app and when a new client signs up, they get their own copy in git. Was just trying to have all the resources for that tenant be in one directory instead of spread across many, since deleting also causes new issues with repo syncs as you need to remove all the repo resources first before deleting the reposync object itself
since deleting also causes new issues with repo syncs as you need to remove all the repo resources first before deleting the reposync object itself
In 1.15.0, you can use the new deletion-propagation feature to delete all objects managed by a RootSync or RepoSync.