[MUSIC PLAYING]
SPEAKER: As your Google Cloud deployment grows,
so can your permissions management needs.
With fixed time and resources, you
may be looking to find a more efficient way
to manage permissions and strengthen the security
of your expanding deployment.
For example, let's say you have development, staging,
and prod instances to manage.
Efficiency might lead you to grant
every developer at your company the view,
edit, and even delete privileges for services in your production
environment.
Strengthening security, on the other hand,
means limiting the number of principals, or users,
who can make changes to a prod environment
to only those necessary, such as some select service accounts
and users from certain groups.
It can seem like these two goals are opposing forces.
To solve for security, you could create a complex hierarchy
of roles that allows you to have different permissions
for different instances and apply them
to different users on an ad hoc basis.
But that is time consuming and does not scale.
Or you can lock everything down.
But locking everything down is not an option
for you to run your business.
Thankfully, with Google Cloud IAM,
you can use a combination of IAM allow rules
and IAM deny rules to craft permission solutions tailored
to your needs.
This approach leads to a permission set
that is much easier to understand and implement
security policies at scale.
And it protects you from granting
overly permissive roles.
Let's dive in a bit deeper into how
to use these rules when setting permissions for users.
This is done by assigning them roles
that have certain permissions.
An IAM allow rule lets you clearly
state the general idea of what a set of users can do.
IAM allow policy lets you grant granular access to Google Cloud
resources.
As an example, you can create a rule
that gives roles that give read, edit, and delete permissions
on all instances to a principle set of all your developers.
IAM deny policies are more coarse grained that let you
explicitly prohibit access to certain resources,
regardless of existing allow rules.
IAM deny rules are a useful addition that
allow you to state the exceptions to allow rules.
For example, you can clearly state no developers
other than those identified as site reliability
engineers, SREs, have roles with read,
edit, and delete permissions on prod server.
IAM deny does this by gatekeeping
the input to the IAM allow tests.
IAM deny policies always supersede
IAM allow policies and override conflicting IAM allow rules.
It runs before the allow listing is even checked.
So if the users are denied by a deny rule,
then they will not even check if they pass allow rules.
So let's take a look at how to use these IAM rules, starting
with the allow bindings, which are made up of principles
and the permission roles they are allowed
and, optionally, the conditions under which they
receive those roles.
The allow rules also utilize metadata
that contains many other important bits of information
that you may use.
See our documentation for the current types of metadata used.
IAM policies include deny rules that compliment allow rules.
Deny rules are made of the users who
will be denied permissions, shown as denied principles
here; users who will not be denied by this rule, shown
as exception principles here; the permissions which
are denied and the conditions when this rule will be applied.
The metadata that goes with deny rules
also contains many other important bits of information
that you may use.
See our IAM documentation for the current types
of metadata used.
When planning your IAM policy, remember that the permissions
hierarchy flows from organizations, to folders, then
to projects.
Permissions on projects don't affect
folders or organizations, while permissions on organizations
affect all folders within them and all their projects.
As you plan out your permissions,
keep your permissions as granular as you can,
following the principle of least privilege.
If you'd like to know more about IAM allow and deny,
please check out the links listed in the description
below.
And don't forget to subscribe to our channel for more
tips on IAM and org policy.
Until next time, thanks for watching.
[MUSIC PLAYING]