Members
1. Members
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 Google Workspace domain represents a virtual group of all the Google Accounts that have been created in an organization's Google Workspace account. Google Workspace domains represent your organization's internet domain name, such as example.com, and when you add a user to your Google 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 Google 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 Google Workspace 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 Google 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 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.2. Let's practice!
Create Your Free Account
or
By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.