Introduction to Cloud IAM
Articles Blog

Introduction to Cloud IAM


Ryan: Hi, I’d like to tell you
about Google Cloud Identity and Access Management. I’ll call it Cloud IAM,
or IAM for short. Cloud IAM is Google Cloud
Platform’s unified system for managing access to resources
and assigning permissions for users and services to access
those resources. Cloud IAM is designed
for organizations with many individual projects
and users. The idea is to unify control
for access for all of these projects
and the resources in one place, making it easier
for one organization to keep track of everything
they’ve got going on in Google Cloud Platform. IAM is built on a concept
called a policy. Policies answer the question, “Who can do what
to which thing?” They are made up of permissions which grant access to resources
that are bundled into roles which are assigned
to identities. The combination of identity,
role, permission, and resource determine if a given action
is allowed by IAM. In order to further understand
IAM, we need to go into more depth
on identities, resources, permissions, and roles. Identity is all about defining
the “who” part of an IAM policy. Individual people
have Google accounts that can be used as an identity
in IAM. Service accounts, which are used
for one service to connect another without
human intervention, are another type of identity. Both these types of accounts
have a username and some sort of credential. Both of these accounts can be
placed into Google Groups which can be used to simplify
assigning permissions to resources. You can also use
a Google App Domain as you would a group to give
permission to a resource to all users
in a given organization. Resources are the various
components of Google Cloud Platform to
which you can control access. Resources include things like
Cloud Platform projects, Cloud Storage Buckets,
and Pub/Sub topics. Check the documentation
for which resources are available to use with IAM
at the current time. In IAM, permissions take the
form of service, resource, verb. So if I wanted to grant
an identity the right to listen to a topic
in Pub/Sub, the correct permission would be
pubsub.topic.list. If instead I wanted to grant
the ability to write a file to a bucket in Cloud Storage, I would apply
storage.bucket.create. Check the documentation
for the service in question as to what the various
permissions are. Roles are to permissions
as groups are for identities. They allow you to bundle up
a set of logically connected
permissions in a common way and then add
them to a policy. If you are a Google Cloud
Platform veteran, then you are familiar with what we are now calling
primitive roles: owner, editor, and viewer. These roles work exactly
the same way they always have, but in many cases they can
result in being more permissive than you want to be. For example, under this model
an editor in a given project can add VMs in Compute Engine and delete storage buckets
in Cloud Storage. This may be suboptimal
for your purposes. That’s why we’ve added
curated roles. These curated roles are tied
to resources and allow for a resource centric
assigning of access rates. For example, someone with
the role appengine.admin has the equivalent of a broad
array or individual permissions that allow them to administer
a project’s entire app engine
configuration. However, someone with
appengine.deployer can only add code and push
that code to production. They could not modify the daily
quota for app engine. Furthermore, neither of these
users could modify anything to do with Compute Engine. Not unless someone had given
them access to Compute Engine separately with Compute Engine
roles. As you can see, policies
are made up of roles which are made up permissions
which are assigned to resources. We add groups or users
to that policy, and through that policy
they gain access to the specific resources
their roles give them. The last concept you should know
is hierarchy. Basically policies flow from
the top in organization down to projects
and finally to resources, which means that you can assign
organization-wide policies which can then be augmented
by policies that you set on
a particular project, which can further be added to by
policies you set on a resource. So you can assign access
to individual resources or you can go higher and apply
them to an entire project or even higher and assign them
to an entire organization, which will then apply to all
projects in that organization and those policies will cascade
down to resources in those projects, meaning you can be as permissive
or as locked down as you like. That’s the basics of Cloud IAM. You can find out more
at our documentation website, and we can’t wait to find out
what you’re gonna build next with Cloud IAM.

4 thoughts on “Introduction to Cloud IAM

  1. This is a good introductory video that is produced well. Still applies to GCP more than 2 years later. The only item missing is Folders.

  2. Is there a typical usecase explaining a JML/SLAM workflow with autoprovisioning/de provisioning flows ?

Leave a Reply

Your email address will not be published. Required fields are marked *

Back To Top