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.