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
(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
is added to the users in Active Directory, and GCDS
on that attribute. In the example.com domain, Google Cloud-specific
groups are prefixed with
grp-gcp- (for example,
grp-gcp-security-reviewer) and a filter is applied to sync only those
groups. The example.com GCDS filters are shown in
|Filter type||Filter rule|
Table 2.6.1 GCDS user and group filters
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.
||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|
||Members have the ability to view resource information across the Google Cloud organization.||Viewer||organization|
||Members are part of the security team responsible for reviewing cloud security.||Security Reviewer||organization|
||Members are part of the networking team and review network configurations.||Compute Network Viewer||organization|
||Members are part of an audit team and view audit logs in the logging project.||Logs Viewer
Private Logs Viewer
BigQuery Data Viewer
||Members can administer Security Command Center.||Security Center Admin Editor||SCC project|
||Members are responsible for putting secrets into Secrets Manager.||Secret Manager Admin||global secrets project
production secrets project
||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|
||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 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 that has Google Cloud super administrator permissions.||Super Administrator|
||Identity that has organization administrator permissions within example.com.||Organization Administrator|
||Identity that can create billing accounts.||Billing Account Creator|
||Identity that has billing administrator permissions within example.com.||Billing Account Administrator|
||Identity (one per folder) that has folder administrator permissions.||Folder Administrator|
||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.