Limiting proxy developer access to specific assets (proxies, shared flows, KVMs) when multiple teams are sharing an environment.
I have a situation where a company has many developer teams that will "Share" the gateway. This could be done using fine grain resource permissions allowing developers to read/write/delete a subset of proxies, shared flows and other assets. For example, developer A can read/write proxy "A" and "B" but not "C". Whereas Developer "B" can read/write proxy "C" but not "A" or "B". This extends to shared flows, KVMs and the like. Managing these permissions would be somewhat complex and perhaps create friction to getting work done in a timely manner.
I am therefore thinking environment separation is a better choice as the permissions would be granted to the dedicated environment and therefore alleviate the need for fine grain permissions. The downside to this is that there could be many (20 or more) environments in the "Dev" Org. The artifacts created in the "DEV" org would ultimately promote to a merged (all groups assets commingled) Org under CI/CD control and then finally Prod Org which would have same CI/CD control.
Example summary would be
"Dev Org" - One environment per developer team to achieve separation. Could be as many as 20 environments.
"Non-Prod Org - Test, QA, Perf environments where all assets are merged and under CI/CD control.
"Prod Org" - Same as Non Prod in structure with CI/CD control.
Thoughts?
Best Answer
Hi Bill and welcome home.
This is a common ask. In Apigee X, this "could" be done using GCP IAM and custom roles, details yet to be proven and documented. Are you using Apigee X?
The approach for the Dev Org would still require custom roles per team, since proxies are not scoped to the environment, just their deployment.
A simpler approach would be to have "Dev Org A", "Dev Org B", etc. rolling up to the merged orgs, but that may be cost prohibitive based on the number of teams.
Hey Kurt.
Customer will be on "X" and I have been poking around with Roles and Permissions. I am hoping (yet to prove) that they are more effective than what we had with Edge. That said my brute force approach would be to carve up teams into isolated environments with some more granular permissions as needed. All the team level environments would roll up into a "unified view" as the assets move closer to production and be under more strict CI/CD level permission sets. Think less hands/eyes on and more automation.
All of this does come at a cost for what could be construed as environment bloat but might be worth the added cost. Keyword "Might".
I, without much thought, punted on carving up teams into Orgs purely due to cost with upside being even more isolation but this customer could be in the 20 org range. $$$$ I will revisit this.
Thanks for the feedback.
Hi Bill,
After significant testing and empirical analysis of "current state" Apigee X, there's currently no way to create a "team" role that allows/restricts access to specific proxies or other org level entities by name.
Conditions on GCP IAM Role assignment currently do not work based on resource name.
resource.name.startsWith("organizations/apigeex-eval-kurt/apis/team-1")
The Method: organizations.environments.setIamPolicy works at the environment level which means it only applies to anything below "organizations/*/environments/*". This BTW shows up in the UI when set via Apigee API and works when no role is assigned in IAM (e.g. on a service account).
Conditions currently cannot be set this way either.
So, you could isolate teams by environment level resources. Any developer with access to the org will be able to see other proxies, but won't be able to see the secret stuff (e.g. env level property sets).
Fine Grained Permissions and IAM Conditions are planned to be available later this year.
It seems that Environment level isolation by team is now my only real path forward with the idea that upper environments have cross team assets commingled but restricted to CI/CD pipelines and not prying eyes.
Thanks for doing the "significant and empirical" testing. I will report back when I have fleshed this out further.
As always thanks for the support.
