How does policy inheritance work in the Google Cloud Platform?

Asked 2 years ago

I am aware that I can set policies at different levels or resources on the Google Cloud Platform. I understand that you can allow who to have access to the cloud resources, but what I don’t get is how it works. I'm just confused about how policy inheritance works. Can someone please explain?

Graham Barrera

Friday, June 10, 2022

Attached allow policies, also known as Identity and Access Management (IAM) policies, provide access to Google Cloud resources. Each resource has one allow policy. The allow policy regulates permissions and any successors that inherit it.

Policy structure: Allow policies contain role bindings and metadata. Identity binding determines resource access. It connects one or more principals to a single IAM role and any situational criteria that affect role granting. Metadata provides an ETag and version to aid policy administration.

To elaborate further on how policy inheritance works, I'll walk you through an example to understand the allow policy inheritance:

Suppose you want to grant a user, namely James, access to two different IAM roles at different resource levels. You assigned James a role at the organizational level by quoting this allows policy on your organization:

{

"bindings": [

{

"members": [

"user:james@example.com"

],

"role": "roles/storage.objectViewer"

}

],

"etag": "BwUjMhCsNvY=",

"version": 1

}

With this "allow policy", James receives the Storage Object Viewer role (roles/storage.objectViewer). Consequently, James has access to the get and list consent of projects and Cloud Storage objects. Now he can use those permissions on all your projects and Cloud Storage objects.

Now let's suppose you wish to grant James a position at the project level instead of the whole organization. So you set this allow policy on the intended project projectvip-101:

{

"bindings": [

{

"members": [

"user:james@example.com"

],

"role": "roles/storage.objectCreator"

}

],

"etag": "BwUjMhCsNvY=",

"version": 1

}

Due to this allow policy, James holds the Storage Object Creator role (roles/storage.objectCreator). Since the policy is created at a project level, James can only play this role and create Cloud Storage only for projectvip-101.

So we have two allow policies in place and two role bindings. It means James has his hands on the target Cloud Storage objects under projectvip-101. Accordingly, the following allows policies are applicable:

  1. When the policy is enabled at the organization level, all Cloud Storage objects within the organization can be listed and retrieved.
  2. The project-level allow policy permits the creation of objects within projectvip-101.




Write an answer...

Cancel

Please follow our  Community Guidelines

Can't find what you're looking for?