Skip to main content

Google Identity Access Management (Google IAM)



IAM lets administrators authorized who can take on specific resources.

An IAM Policy has
“Who” Part
A “Can do What” part and
“On which resource” Part

Who can do what on which resources?

Who: IAM policies can apply to any of four types of principals
Google Account or Cloud Identity User
Service Account
Google group
G Suite domain

Can do what: IAM roles are collections of related permissions
Example Instance Admin Role can have below list of permission
compute.instance.list
compute.instance.delete
compute.instance.start
compute.instance.stop

On Which Resources: Users get roles on specific items in the hierarchy
When you give a user, group, or service account a role on a specific element of the resource hierarchy, the resulting policy applies to the element you chose, as well as to elements below it in the hierarchy.
OrganizationàfolderàProjectàResources
There are three kinds of roles in Cloud IAM
IAM primitive roles apply across all GCP services in a project
Primitive roles are broad. You apply them to a GCP project, and they affect all resources in that project. IAM primitive roles offer fixed, coarse-grained levels of access



These are the Owner, Editor, and Viewer roles. If you’re a viewer on a given resource, you can examine it but not change its state. If you’re an editor, you can do everything a viewer can do plus change its state. And if you’re an owner, you can do everything an editor can do plus manage roles and Permissions on the resource. The owner role on a project lets you do one more thing too: you can set up billing. Often companies want someone to be able to control the billing for a project without the right to change the resources in the project, and that’s why you can grant someone the billing administrator role.
Be careful! If you have several people working together on a project that contains sensitive data, primitive roles are probably too coarse a tool. Fortunately, GCP IAM provides finer-grained types of roles.

IAM predefined roles apply to a particular GCP service in a project. offer more fine-grained permission on particluar  services.

GCP services offers their own sets of predefined roles, and they define where those roles can be applied. For example, Compute Engine, which offers virtual machines as a service. Compute Engine offers a set of predefined roles, and you can apply them to Compute Engine resources in a given project, a given folder, or an entire organization.

InstanceAdmin Role on Project,  

compute.instances.delete
compute.instances.get
compute.instances.list
compute.instances.start
compute.instances.stop

IAM custom roles let you define a precise set of permissions
What if you need something even finer-grained? That’s what custom roles permit. A lot of companies use a “least-privilege” model, in which each person in your organization the minimal amount of privilege needed to do his or her job. So, for example, maybe I want to define an “instanceOperator” role, to allow some users tostop and start Compute Engine virtual machines but not reconfigure them. Custom roles allow me to do that

InstanceAdmin Role, can set the set of custom permission.

compute.instances.start
compute.instances.stop

Comments

Post a Comment

Popular posts from this blog

Container and Container Orchestration

What is container? Container contain application code and dependencies into single Unit. So, what is Container orchestration? Container orchestration is about to managing life cycle of container. Container orchestration to control and automate task: Provisioning and deployment of container Scaling up and removing container as per application load Allocation the resource between Container Health check of container Kubernetes open Source is the example of Container Orchestration
Post a Comment
Read more

Cloud Storage and Cloud IAM or ACLs or Signed URLs

Cloud Storage offers layers of increasingly granular access control. For most purposes, Cloud IAM is sufficient, and roles are inherited from project to bucket to object. Access control lists (ACL) offer finer control. And for detailed control, signed URLs provide a cryptographic key that gives time-limited access to a bucket or object. A signed policy document further refines the control by determining what kind of file can be uploaded by someone with a signed URL Cloud IAM Works with Cloud Storage just as with using Cloud IAM with any other resource. Project Owners are automatically granted Bucket Owner role for all buckets in the project. Note that ACLs and Cloud IAM are independent, so Project-level Cloud IAM permissions will not appear in bucket or object ACLs. Signed URLs A signed URL gives you the ability to grant access to a bucket without Cloud IAM user authentication for a limited period of time. e.g., when you don’t want to require users to have Goog...
2 comments
Read more

Service Accounts

What if you want to give permissions to a Compute Engine virtual machine rather than to a person? That’s what service accounts are for. For instance, maybe you have an application running in a virtual machine that needs to store data in Google Cloud Storage. But you don’t want to let just anyone on the Internet have access to that data; only that virtual machine. So you’d create a service account to authenticate your VM to Cloud Storage. Service accounts are named with an email address, but instead of passwords they use cryptographic keys to access resources. Service Accounts control server-to-server interactions: Provide an identity for carrying out server-to-server interactions in a project Used to authenticate from one service to another Used to control privileges used by resources                 So that applications can perform actions on behalf of authenticated end users Identified with an ...
Post a Comment
Read more