Authentication and authorization

Stay organized with collections Save and categorize content based on your preferences.

Google Cloud includes a number of services and features to support authentication and authorization. These allow for federation with existing identity providers, fine-grained access control, and security controls to manage privileged identities.

Cloud Identity, directory provisioning, and single sign-on

Google Cloud uses Google Cloud Identity for authentication and access management. Manually maintaining Google identities for each employee can add unnecessary management overhead when all employees already have an account in an existing identity store such as Active Directory. By federating user identities between Cloud Identity and Active Directory, you can automate the maintenance of Google identities and tie their lifecycle to existing identity management processes within your organization.

In the reference architecture, as shown in Figure 2.6.1, relevant users and groups are synchronized periodically from Active Directory to Cloud Identity using the Google Cloud Directory Sync tool. This process ensures that when you create a new user in Active Directory, that user can be referenced in Google Cloud. This process also ensures that if a user account is deleted or suspended, those changes are propagated. Provisioning works one way, which means changes in Active Directory are replicated to Cloud Identity but not the other way around. The sync process doesn't include passwords by default; in a federated setup, Active Directory remains the only system that manages these credentials.

Single sign-on (SSO) is used in the example.com reference architecture for user authentication. During sign on, Google Cloud delegates authentication to Active Directory Federation Services by using the Security Assertion Markup Language (SAML) protocol. This delegation ensures that only Active Directory manages user credentials and that any applicable policies or multi-factor authentication (MFA) mechanisms are being enforced. For a sign-on to succeed, the user must be provisioned in both Active Directory and Cloud Identity.

In the example.com reference architecture, the on-premises Active Directory system is used as the source of truth for users, groups, and SSO. GCDS is installed on a domain-joined host on-premises (either Windows or Linux). A scheduled job (using Task Scheduler or cron) is used to synchronize users and groups into Cloud Identity on an hourly basis. To control which users are synced to Cloud Identity, an attribute is added to the users in Active Directory, and GCDS filters on that attribute. In the example.com domain, Google Cloud-specific groups are prefixed with grp-gcp- (for example, grp-gcp-billing-viewer or grp-gcp-security-reviewer) and a filter is applied to sync only those groups. The example.com GCDS filters are shown in Table 2.6.1.

Filter type Filter rule
Group filter (&(objectCategory=group)(cn=grp-gcp-*))
User filter (&(objectCategory=user)(msDS-cloudExtensionAttribute1=googlecloud))

Table 2.6.1 GCDS user and group filters

Figure 2.6.1 The example.com identity structure

Figure 2.6.1 The example.com identity structure

Users and groups

Groups for example.com follow the naming convention defined earlier in Table 2.3.2. In the example.com organization, users are not assigned roles directly; instead, groups are the primary method of assigning roles and permissions in IAM. IAM roles and permissions are assigned during project creation through the deployment pipeline and are then updated as needed.

Users are assigned group membership through the on-premises Active Directory system; as such, group creation and membership is strictly controlled. Table 2.6.2 shows the groups setup in the example.com foundation. You can set up additional groups as needed on a workload-by-workload basis.

Group Description Roles Scope
grp-gcp-billing-viewer@example.com Members are authorized to view the spend on projects. Typical members are part of the finance team. Billing Account Viewer BigQuery Data Viewer BigQuery User organization for Billing Account Viewer billing project for BigQuery Data Viewer and BigQuery User
grp-gcp-platform-viewer@example.com Members have the ability to view resource information across the Google Cloud organization. Viewer organization
grp-gcp-security-reviewer@example.com Members are part of the security team responsible for reviewing cloud security. Security Reviewer organization
grp-gcp-network-viewer@example.com Members are part of the networking team and review network configurations. Compute Network Viewer organization
grp-gcp-audit-viewer@example.com Members are part of an audit team and view audit logs in the logging project. Logs Viewer
Private Logs Viewer
BigQuery Data Viewer
logging project
grp-gcp-scc-admin@example.com Members can administer Security Command Center. Security Center Admin Editor SCC project
grp-gcp-secrets-admin@example.com Members are responsible for putting secrets into Secrets Manager. Secret Manager Admin global secrets project production secrets project non-production project development project
grp-gcp-business-code-environment-code-developer@example.com Groups are created on a per-business code or per-environment basis to manage resources within a particular project. service- and project-specific permissions specified project
grp-gcp-platform-operator@example.com Members are responsible for platform operations, and they are added into other groups and inherit those permissions.

Table 2.6.2 Groups in example.com

There are three types of roles in IAM:

  • Basic roles include the Owner, Editor, and Viewer roles.
  • Predefined roles provide granular access for specific services and are managed by Google Cloud.
  • Custom roles provide granular access according to a user-specified list of permissions.

Google recommends using predefined roles as much as possible. The IAM recommender should be used to ensure that IAM permissions that are granted to users and groups are not overly permissive. You should eliminate or at least severely limit the use of basic roles in your Google Cloud organization because the wide scope of permissions inherent in these roles goes against the principles of least privilege. Whenever possible, you should instead use predefined roles, which are designed with inherent separation of duties, and then add custom roles as needed.

Privileged identities

Privileged identities are accessed through a firecall process, which involves users that are used only in situations that require escalated privileges. Examples of this scenario are when an automated process has broken down, or when permissions need to be elevated temporarily to manually restore a service to a functional state. Table 2.6.3 lists the privileged identities used in example.com that should be accessed through a firecall process.

Identity Description Role
gcp-superadmin@example.com Identity that has Google Cloud super administrator permissions. Super Administrator
gcp-orgadmin@example.com Identity that has organization administrator permissions within example.com. Organization Administrator
gcp-billingcreator@example.com Identity that can create billing accounts. Billing Account Creator
gcp-billingadmin@example.com Identity that has billing administrator permissions within example.com. Billing Account Administrator
gcp-environment-folderadmin@example.com Identity (one per folder) that has folder administrator permissions. Folder Administrator
gcp-business-code-environment-code-editor@example.com Identity (one per business code or per environment) that has project editor permissions for that group's projects in the environment. Editor

Table 2.6.3 Privileged identities in example.com

Because of the high-level permissions available to privilege identities, access to the privilege identities should require the consent of at least two people within your organization. For example, one person controls access to a privileged identity password, while another person controls access to the associated MFA token.