Organization policies are needed to enforce what resources are available in a Google Cloud trust boundary (folder, project, or other organizational level).
Cloud Identity and Access Management (IAM) enables you to manage access control by defining who (identity) has what access (role) to which resource.
Policies
Top to bottom : Resources inherit the policies of their parent resource.
Google Cloud Platform Policies are set at the highest level, like the organisation node are cascaded down to the project.
Inheritance is transitive, all the resources in a project inherit the policy.
However policies implemented at a higher level in this hierarchy can’t affect the access that’s granted exceptionally at a lower level.
For example,
Policy A – Enforced at the Organisation Level – Users can view cloud storage buckets.
Policy B – Enabled at the Project Level – User can modify cloud storage buckets.
Since Project Level Policy B is granting a more generous access at a lower level, it shall take effect and override Policy A.
Cloud IAM
An IAM policy has the following :
- “who” part,
- a “can do what” part, and
- an “on which resource” part.
Who
The “who” part of an IAM policy can be defined either by a
a. Google account
b. Google group
c. Service account
d. G Suite
e. Cloud Identity domain.
Can Do What – Role
The “can do what” part is defined by an IAM role which is a collection of permissions.
To do any meaningful operations, you need more than one permission.For example, to manage instances in a project, you need to create, delete, start, stop, and change an instance.
So the permissions are grouped together into a role that makes them easier to manage.
There are three kinds of roles in Cloud IAM:
- Primitive roles: Roles historically available in the Google Cloud Console. These roles are Owner, Editor, and Viewer. Avoid using these roles if possible, because they include a wide range of permissions across all Google Cloud services.
- Predefined roles: Roles that give finer-grained access control than the primitive roles. For example, the predefined role Pub/Sub Publisher (
roles/pubsub.publisher
) provides access to only publish messages to a Pub/Sub topic. - Custom roles: Roles that you create to tailor permissions to the needs of your organization when predefined roles don’t meet your needs.
Reference : Concepts Related to Access Management
very good publish, i certainly love this website, carry on it
Heya! I’m at work browsing your blog from my new iphone! Just wanted to say I love reading through your blog and look forward to all your posts! Keep up the excellent work!
Awesome post! Keep up the great work! 🙂
Great content! Super high-quality! Keep it up! 🙂