nais
Move Google Service account resources into team namespaces
Move Google Service account resources into team namespaces
Beskrivelse / Essensen
Currently, when an application uses a Google service, a Google service account is created in the serviceaccounts namespace.
This hides one key resource from the teams, and it doesn't work well with owner references. It might also more easily hit the Service Account quota in the cluster project.
Tested today that cross project workload identity works as expected, it's just in Google Cloud Console that there's an error when referencing a workload identity provider URL and not an email.
So the suggestion is to migrate service accounts from the service accounts namespace and into each team project/namespace.
Investeringsvilje
2 uker (vi kan egentlig ikke gå tilbake når vi har startet, da vi ikke ønsker å stå med SAer i flere forskjellige steder)
Ikke-mål
- let replicator create the configconnectorcontext instead of naisd
Mulig løsning i grove trekk
- Flytte CNRM-ressursen over til hvert teams namespace
- Migrere selve service account til teamets prosjekt
- Her må man passe på at man får med seg alle rettigheter som var gitt til SAen
- Slette
serviceaccountsnamespace
Eventuell annen relevant informasjon
~Won't that break as GKE Workload Identity only works with one project (the cluster project in our case)?~ edit: ok, so this is possible now
We should also move the team SA into team project.
This allows for removal of serviceaccounts NS.
Another related improvement is to let replicator create the configconnectorcontext instead of naisd. Naisd would only need to set an annotation for replicator to use during templating
I'm not convinced that this refactor is useful. However, I'm pretty certain that it will cause problems down the line.
Can anyone give a clear explanation of the problem we're trying to solve?
As stated in the original message:
This hides one key resource from the teams, and it doesn't work well with owner references. It might also more easily hit the Service Account quota in the cluster project.
We've had to increase the SA quota in cluster projects already. E.g in nav-dev-gcp we have a quota of 3000, and currently using 2265.
In a newer tenant project, it seems like there's no limit anymore, so we might be able to get unlimited in nav cluster projects as well to remove that as a reason to do this.
I missed the comments of this issue.
I'm not convinced that this refactor is useful. However, I'm pretty certain that it will cause problems down the line.
Can you elaborate, on both?
Can anyone give a clear explanation of the problem we're trying to solve?
This is stated both in the original message and then again when asked. I don't understand why this is then closed without any commentary.
To me this seems like a obvious clean-up in how we provision service accounts for workloads and teams. This was done originally due to a limitation, which isn't there anymore.
@jhrv said: I don't understand why this is then closed without any commentary.
Here's why:
@thokra-nav said: In a newer tenant project, it seems like there's no limit anymore, so we might be able to get unlimited in nav cluster projects as well to remove that as a reason to do this.
Also,
@jhrv said: To me this seems like a obvious clean-up in how we provision service accounts for workloads and teams.
It can also be viewed as an unneccessary design change, as long as the limit is lifted.
Ah okey. I think it's just misunderstood slightly. Even though the quota-bit isn't a limitation anymore, I still think (and interpreted Thomas that way too), that this is well worth doing.
It can also be viewed as an unneccessary design change, as long as the limit is lifted.
Having team resources in the team project together with all the other team resources is not only natural and easier to understand/intuitive, and we don't have to have special handling of this case with an extra namespace. It also makes it easier when we talk about moving clusters and cluster-projects.