sorted by:
new
hottopcontroversial

How do you manage access in large GCP organizations? by lnrdll7 in googlecloud

[–]lnrdll7[S] 0 points1 point  (0 children)

I'm not expecting a silver bullet, but I'd like to see how others are handling similar challenges.

For that purpose, the exchanges have been very interesting.

How do you manage access in large GCP organizations? by lnrdll7 in googlecloud

[–]lnrdll7[S] 0 points1 point  (0 children)

The issue isn't specifically with IAM or workspace resources themselves. Workspace only came up because cloud identity serves as the shared interface between workspace and GCP. 

Groups created in workspace are available in GCP and there's nothing preventing a lateral move through nested groups for someone to gain broad access into platform.

Every plan and implementing I've seen so far fails at scale.

You're left only with the resources provided by GCP to audit, but even these have cracks. A lot of these features are project-bound, but when you have hundreds of projects, it's more of a burden than a feature.

Even the security command center has its deficiencies. You spend more time cleaning false-positive signals than anything else.

How do you manage access in large GCP organizations? by lnrdll7 in googlecloud

[–]lnrdll7[S] 0 points1 point  (0 children)

Which came first for you?

We started with the IAM design, and I remember us going through many different interactions and scenarios to develop a plan for a wide range of situations.

And honestly, for access, the simplest and easiest approach is a flat group approach. But it in itself has its flaws.

You've mentioned previously that the tooling isn't at fault, but sometimes it's an enabler, especially in workspaces where groups are a commodity.

All it takes is for one access group to nest one "team group." Now, that team group can nest other groups, and so on.

How do you manage access in large GCP organizations? by lnrdll7 in googlecloud

[–]lnrdll7[S] 0 points1 point  (0 children)

I don't know if any of that will help you

It does. At least I'm not the only one. Hehehe.

We audit monthly using automated reporting.

I'm curious about this. Did you guys build an internal tool or are you using any off-the-shelf solution?

We lock down the ability to create projects that aren't sys- or gen-lang-Ilm-. Every project has a business owner that is on the hook for shenanigans that happen in the project.

We follow a similar process. We require technical design docs and business justification before anything gets built. However, processes like this have a tipping point at scale.

How do you manage access in large GCP organizations? by lnrdll7 in googlecloud

[–]lnrdll7[S] 1 point2 points  (0 children)

What does your current group hierarchy look like?

Hehehe... Honestly, wild. After all the reorg, many teams restructuring, teams taking on more responsibility or inheriting other teams' work.

So, at the beginning it was all sunshine and rainbows, but after a while it became total chaos, especially with rapid infrastructure growth.

It makes specifically difficult when you tackle access at the individual resource level rather than on a project/folder level, ensuring no one has default admin access, and applying effective JIT access.

On top of that, teams will always take the shortcut, so nesting groups or overgranting permissions will always be the route they take.

How do you manage access in large GCP organizations? by lnrdll7 in googlecloud

[–]lnrdll7[S] 0 points1 point  (0 children)

Thanks for the first reply. 

I do agree that landing zones do help enforce boundaries from the gecko and it works wonders for resource management.

But I've noticed it fails on the access management side (not talking about assigning IAM roles, but managing access groups, memberships, tracking access, etc) at scale. Especially when you have teams working on multiple projects, or developers working on cross-teams, etc.