Members

Summary

The video script discusses Google Cloud's Identity and Access Management (IAM), focusing on member types like Google Accounts, Service Accounts, Google Groups, Workspace domains, and Cloud Identity domains. It explains IAM policies, the importance of the principle of least privilege, and how to manage permissions with role recommendations and policy insights. The script also covers deny policies, conditions, organization policies, and tools for integrating existing corporate directories with Google Cloud for seamless user and group management.

Takeaways

• 👤 Google Accounts are for individuals like developers or administrators and can be identified by any email address, even without using Gmail.
• 🔑 Service Accounts represent applications rather than individuals, allowing you to specify the identity under which your code runs on Google Cloud.
• 👥 Google Groups are collections of Google and service accounts with a unique email address, making it easy to manage access for multiple users at once.
• 🏢 Workspace domains are for organizations, representing all Google accounts within an organization and allowing new accounts to be created within this domain.
• 🌐 Cloud Identity provides similar capabilities to Workspace domains but without the collaboration tools like Gmail, Docs, etc.
• 🚫 IAM policies cannot be used to create or manage users or groups; instead, Cloud Identity or Workspace should be used for these tasks.
• 🔒 IAM policies consist of bindings that link members to roles, which are lists of permissions defined by IAM.
• 📋 The IAM policy hierarchy follows the Google Cloud resource hierarchy, meaning changes to the resource hierarchy affect the policy hierarchy.
• 🛑 Child policies cannot restrict more than parent policies, emphasizing the importance of the principle of least privilege in access control.
• 🔎 Role recommenders and policy insights help in identifying and removing excess permissions, enforcing the principle of least privilege at scale.
• 🏷️ IAM Conditions allow for conditional access control based on specific attributes, providing flexibility in granting permissions.
• 📝 Organization policies apply restrictions across the organization, folders, or projects, with inheritance down the resource hierarchy.
• 🔄 Google Cloud Directory Sync synchronizes existing corporate directories with Cloud Identity, facilitating the use of familiar credentials for Google Cloud access.
• 🔒 Single sign-on (SSO) allows for the use of existing identity systems with Google Cloud, providing a seamless authentication experience.

Q & A

What are the five types of members in Google Cloud?

The five types of members in Google Cloud are Google Accounts, Service Accounts, Google Groups, Google Workspace domains, and Cloud Identity domains.

What is a Google Account and how can it be used in Google Cloud?

A Google Account represents a developer, an administrator, or any other person who interacts with Google Cloud. Any email address associated with a Google Account can be an identity, and new users can sign up for a Google Account without receiving mail through Gmail.

What is the purpose of a Service Account in Google Cloud?

A Service Account is an account that belongs to an application rather than an individual end user. It is used when running code on Google Cloud to specify the account that the code should run as.

How does a Google Group facilitate access control in Google Cloud?

A Google Group is a named collection of Google Accounts and Service Accounts with a unique email address. It allows applying an access policy to a collection of users, enabling the granting and changing of access controls for a whole group at once instead of individual users or service accounts.

What is the role of a Workspace domain in Google Cloud?

A Workspace domain represents a virtual group of all the Google Accounts created in an organization's Workspace account. It represents the organization's internet domain name, and new Google Accounts are created for users within this virtual group.

How does Cloud Identity differ from Google Workspace for non-Workspace customers?

Cloud Identity allows non-Workspace customers to manage users and groups using the Google Admin Console without paying for or receiving Workspace's collaboration products such as Gmail, Docs, Drive, and Calendar.

What is the purpose of an IAM policy in Google Cloud?

An IAM policy is a collection of access statements attached to a resource. It contains a set of roles and role members, with resources inheriting policies from their parent, and helps in defining who can do what on which resource.

How does the principle of least privilege apply to IAM in Google Cloud?

The principle of least privilege in IAM suggests that identities, roles, and resources should always select the smallest scope necessary for the task to reduce exposure to risk. It helps enforce security by ensuring that principals have only the permissions they actually need.

What is the role of a recommender in IAM for role management?

A recommender in IAM provides role recommendations to identify and remove excess permissions from principals, improving security configurations by ensuring that principals have only the necessary permissions.

How do IAM Conditions work in Google Cloud?

IAM Conditions allow for conditional, attribute-based access control. They define and enforce access to identities (members) only if configured conditions are met, allowing for temporary access or limiting access based on specific attributes.

What is an organization policy and how is it applied in Google Cloud?

An organization policy is a configuration of restrictions applied to the organization node and all of its folders or projects. It is inherited by descendant resources in the hierarchy, and exceptions can be made by users with the organization policy admin role.

How can existing corporate directories be integrated with Google Cloud?

Google Cloud Directory Sync allows administrators to manage Google Cloud resources using existing Active Directory or LDAP systems. It synchronizes users and groups one-way from the corporate directory to the Cloud Identity domain.

What is single sign-on (SSO) and how can it be configured for Google Cloud?

Single sign-on (SSO) allows users to authenticate once in their identity system and then access Google Cloud without additional sign-in prompts. If the existing authentication system supports SAML2, SSO configuration involves setting up three links and a certificate. Otherwise, third-party solutions like ADFS, Ping, or Okta can be used.

Outlines

00:00

🔑 IAM Members and Roles Overview

This paragraph introduces the concept of members in Google Cloud IAM, which are the entities that can be assigned permissions. It covers five types: Google Accounts, Service Accounts, Google Groups, Google Workspace domains, and Cloud Identity domains. Google Accounts are for individuals, while Service Accounts are for applications. Google Groups are collections of accounts for easy access management, and Workspace domains and Cloud Identity domains are for organizing accounts within an organization. The paragraph also explains IAM roles, policies, and the importance of adhering to the principle of least privilege for security. It discusses role recommendations and policy insights for managing permissions efficiently.

05:04

🛡️ Fine-Grained Access Control and Organization Policies

The second paragraph delves into the specifics of access control in Google Cloud, focusing on IAM roles and how they can be assigned to different members through bindings. It explains the concept of fine-grained access, using Jie and Raha as examples to illustrate how permissions can be tailored to individuals. The paragraph also introduces IAM deny policies, which act as guardrails to prevent certain actions regardless of other permissions. IAM Conditions are discussed as a way to enforce conditional access based on specific criteria. Organization policies, which apply restrictions across the hierarchy, are also covered, along with the ability to make exceptions by organization policy admins. The paragraph concludes with a discussion on integrating existing corporate directories with Google Cloud through Directory Sync and Single Sign-On (SSO), providing options for maintaining existing authentication systems while accessing Google Cloud resources.

Keywords

💡Google Account

A Google Account is an email address associated with an individual user who interacts with Google Cloud. It represents developers, administrators, or any person and is essential for accessing various Google services. In the video, it is mentioned as the identity for users, including those who might not use Gmail for email services.

💡Service Account

A service account in the context of Google Cloud is an account that represents an application rather than an individual user. It is used when running code on Google Cloud to specify the account under which the code operates. The script explains that multiple service accounts can be created to represent different components of an application.

💡Google Group

A Google Group is a collection of Google accounts and service accounts with a unique email address. It serves as a convenient method for managing access controls for a group of users collectively rather than individually. The video script highlights its use for applying access policies to multiple users at once.

💡Workspace Domain

A Workspace domain is a virtual group of Google accounts created within an organization's Workspace account, representing the organization's internet domain name. When a user is added to a Workspace domain, a new Google account is created for them within this domain. The script explains how Workspace domains are used to manage organizational users in Google Cloud.

💡Cloud Identity

Cloud Identity is a service that allows non-Workspace Google Cloud customers to manage users and groups using the Google Admin Console without the need for Workspace's collaboration products. It is mentioned in the script as an alternative for managing users and groups in Google Cloud.

💡IAM (Identity and Access Management)

IAM is a framework for managing access to Google Cloud resources. It involves policies that consist of bindings which associate members with roles and permissions. The script discusses IAM's role in defining who can perform actions on which resources, emphasizing the importance of not using IAM to manage users or groups directly.

💡Policy

In the context of IAM, a policy is a collection of access statements that are attached to a resource. It contains roles and role members, and resources inherit these policies from their parent. The script explains how resource policies are a union of parent and resource policies, with the principle of least privilege guiding their application.

💡Role

A role in IAM is a named list of permissions that define what actions a member can perform. Roles are assigned to members through policy bindings. The video script provides examples of roles such as 'Organization Admin' and 'Project Creator', illustrating how they grant different levels of access.

💡Principle of Least Privilege

The principle of least privilege is a security concept emphasized in the script, which states that users should have the minimum level of access necessary to perform their tasks. This principle is applied to identities, roles, and resources to reduce risk, and the script mentions using a recommender for role recommendations to enforce this principle.

💡Policy Insights

Policy insights are machine learning-based findings about permission usage within a Google Cloud project, folder, or organization. They help identify excess permissions and are used by the recommender to suggest improvements in security configurations. The script explains how they assist in enforcing the principle of least privilege at scale.

💡Deny Policies

Deny policies in IAM are used to set guardrails on access to Google Cloud resources by specifying rules that prevent certain principals from using certain permissions, regardless of other roles they may have. The script clarifies that deny policies are checked before allow policies, thus taking precedence in access control.

💡IAM Conditions

IAM Conditions allow for conditional attribute-based access control in Google Cloud. They enable the specification of conditions under which access is granted, such as temporary access for production issues or limiting access to the corporate office. The script describes how conditions are part of role bindings in an IAM policy and must evaluate to true for access to be granted.

💡Organization Policy

An organization policy is a set of restrictions applied to an organization and its resources, including folders and projects. It is inherited by descendants in the resource hierarchy, and exceptions require the organization policy admin role. The script discusses how organization policies can be configured and applied to manage resource access across an organization.

💡Google Cloud Directory Sync

Google Cloud Directory Sync is a tool for synchronizing users and groups from an existing Active Directory or LDAP system with Cloud Identity domain users and groups. It is mentioned in the script as a way to integrate existing corporate directories with Google Cloud, allowing administrators to manage resources using familiar credentials.

💡Single Sign-On (SSO)

SSO is an authentication process that allows users to log in once and gain access to multiple systems without needing to authenticate again for each one. The script explains how Google Cloud provides SSO, enabling the use of an existing identity system for authentication, which can also be used to revoke access to Google Cloud.

Highlights

Google Accounts, Service Accounts, Google Groups, Google Workspace domains, and Cloud Identity domains are the five types of members defining access control on Google Cloud.

A Google account can represent any individual interacting with Google Cloud and can be associated with any email address, including non-Gmail domains.

Service accounts are application-specific and can be created to represent different components of an application on Google Cloud.

Google Groups facilitate the management of access policies for collections of users by assigning a unique email address to each group.

Workspace domains and Cloud Identity domains allow organizations to manage users and groups without the need for Workspace's collaboration products.

IAM policies cannot be used to create or manage users or groups; instead, Cloud Identity or Workspace should be utilized.

A policy in IAM is a collection of access statements that includes bindings of members to roles, with roles being lists of permissions.

Resource policies in IAM are inherited from their parent, and more permissive parent policies override more restrictive child policies.

Changing the resource hierarchy in Google Cloud also changes the policy hierarchy, affecting IAM policies.

The principle of least privilege should be followed to minimize risk by granting only the necessary permissions to identities, roles, and resources.

Role recommendations and policy insights help enforce the principle of least privilege by identifying and suggesting the removal of excess permissions.

IAM allow policies control access to Google Cloud resources and their descendants, binding principals with IAM roles and conditions.

Deny policies in IAM set guardrails to prevent certain principals from using specific permissions, regardless of their granted roles.

IAM Conditions enable conditional attribute-based access control, granting access only when certain conditions are met.

Organization policies apply restrictions across an organization, folders, or projects, with the ability to make exceptions by policy admins.

Google Cloud Directory Sync synchronizes existing Active Directory or LDAP systems with Cloud Identity, facilitating administrator access without modifying the original directory.

Single sign-on authentication allows the use of existing identity systems with Google Cloud, providing redirection for authentication and the ability to revoke access.

For users not interested in Gmail, Google accounts can still be created without email services.

Transcripts

Let’s talk more about members, which define the “who” part of “who can do what on

which resource.”

There are five different types of members: Google Accounts, Service Accounts, Google

Groups, Google Workspace domains, and Cloud Identity domains.

A Google account represents a developer, an administrator, or any other person who interacts

with Google Cloud.

Any email address that is associated with a Google account can be an identity, including

gmail.com or other domains.

New users can sign up for a Google account by going to the Google account signup page,

without receiving mail through Gmail.

A service account is an account that belongs to your application instead of to an individual

end user.

When you run code that is hosted on Google Cloud, you specify the account that the code

should run as.

You can create as many service accounts as needed to represent the different logical

components of your application.

A Google group is a named collection of Google accounts and service accounts.

Every group has a unique email address that is associated with the group.

Google groups are a convenient way to apply an access policy to a collection of users.

You can grant and change access controls for a whole group at once instead of granting

or changing access controls one-at-a-time for individual users or service accounts.

A Workspace domain represents a virtual group of all the Google accounts that have been

created in an organization's Workspace account.

Workspace domains represent your organization's internet domain name, such as example.com,

and when you add a user to your Workspace domain, a new Google account is created for

the user inside this virtual group, such as [email protected].

Google Cloud customers who are not Workspace customers can get these same capabilities

through Cloud Identity.

Cloud Identity lets you manage users and groups using the Google Admin Console, but you do

not pay for or receive Workspace’s collaboration products such as Gmail, Docs, Drive, and Calendar.

Now it’s important to note that you cannot use IAM to create or manage your users or

groups.

Instead, you can use Cloud Identity or Workspace to create and manage users.

A policy consists of a list of bindings.

A binding binds a list of members to a role, where the members can be user accounts, Google

groups, Google domains, and service accounts.

A role is a named list of permissions defined by IAM.

Let’s revisit the IAM resource hierarchy.

A policy is a collection of access statements attached to a resource.

Each policy contains a set of roles and role members, with resources inheriting policies

from their parent.

Think of it like this: resource policies are a union of parent and resource, where a less

restrictive parent policy will always override a more restrictive resource policy.

The IAM policy hierarchy always follows the same path as the Google Cloud resource hierarchy,

which means that if you change the resource hierarchy, the policy hierarchy also changes.

For example, moving a project into a different organization will update the project's IAM

policy to inherit from the new organization's IAM policy.

Also, child policies cannot restrict access granted at the parent level.

For example, if we grant you the Editor role for Department X, and we grant you the Viewer

role at the bookshelf project level, you still have the Editor role for that project.

Therefore, it is a best practice is to follow the principle of least privilege.

The principle applies to identities, roles, and resources.

Always select the smallest scope that’s necessary for the task in order to reduce

your exposure to risk.

You can also use a recommender for role recommendations to identify and remove excess permissions

from your principals, improving your resources’ security configurations.

Each role recommendation suggests that you remove or replace a role that gives your principals

excess permissions.

At scale, these recommendations help you enforce the principle of least privilege by ensuring

that principals have only the permissions that they actually need.

Recommender identifies excess permissions using policy insights.

Policy insights are ML-based findings about permission usage in your project, folder,

or organization.

You can grant access to Google Cloud resources by using allow policies, also known as IAM

policies, which are attached to resources.

The allow policy controls access to the resource itself and any descendants of that resource

that inherit the allow policy.

An allow policy associates, or binds, one or more principals (also known as a member

or identity) with a single IAM role and any context-specific conditions that change how

and when the role is granted.

In the example on this slide, Jie ([email protected]) is granted the Organization Admin predefined

role (roles/resourcemanager.organizationAdmin) in the first role binding.

This role contains permissions for organizations, folders, and limited projects operations.

In the second role binding, both Jie and Raha ([email protected]) are granted the ability

to create projects via the Project Creator role (roles/resourcemanager.projectCreator).

Together, these role bindings grant fine-grained access to both Jie and Raha, and Jie is granted

more access than Raha.

IAM deny policies let you set guardrails on access to Google Cloud resources.

With deny policies, you can define deny rules that prevent certain principals from using

certain permissions, regardless of the roles they're granted.

Deny policies are made up of deny rules.

Each deny rule specifies a set of principals that are denied permissions, and the permissions

that the principals are denied, or unable to use.

Optionally, you can define the condition that must be true for the permission to be denied.

When a principal is denied a permission, they can't do anything that requires that permission,

regardless of the IAM roles they've been granted.

This is because IAM always checks relevant deny policies before checking relevant allow

policies.

IAM Conditions allow you to define and enforce conditional, attribute-based access control

for Google Cloud resources.

With IAM Conditions, you can choose to grant resource access to identities (members) only

if configured conditions are met.

For example, this could be done to configure temporary access for users in the event of

a production issue or to limit access to resources only for employees making requests from your

corporate office.

Conditions are specified in the role bindings of a resource's IAM policy.

When a condition exists, the access request is only granted if the condition expression

evaluates to true.

Each condition expression is defined as a set of logic statements allowing you to specify

one or more attributes to check.

An organization policy is a configuration of restrictions,

defined by configuring a constraint with the desired restrictions for that organization.

An organization policy can be applied to the organization node, and all of its folders

or projects within that node.

Descendants of the targeted resource hierarchy inherit the organization policy that has been

applied to their parents.

Exceptions to these policies can be made, but only by a user who has the organization

policy admin role.

What if you already have a different corporate directory?

How can you get your users and groups into Google Cloud?

Using Google Cloud Directory Sync, your administrators can log in and manage Google Cloud resources

using the same usernames and passwords they already use.

This tool synchronizes users and groups from your existing Active Directory or LDAP system

with the users and groups in your Cloud Identity domain.

The synchronization is one-way only; which means that no information in your Active Directory

or LDAP map is modified.

Google Cloud Directory Sync is designed to run scheduled synchronizations without supervision,

after its synchronization rules are set up.

Google Cloud also provides single sign-on authentication.

If you have your identity system, you can continue using your own system and processes

with SSO configured.

When user authentication is required, Google will redirect to your system.

If the user is authenticated in your system, access to Google Cloud is given; otherwise,

the user is prompted to sign in.

This allows you to also revoke access to Google Cloud.

If your existing authentication system supports SAML2, SSO configuration is as simple as 3

links and a certificate, as shown on this slide.

Otherwise, you can use a third-party solution, like ADFS, Ping, or Okta.

Also, if you want to use a Google account but are not interested in receiving mail through

Gmail, you can still create an account without Gmail.