This document in the Google Cloud Architecture Framework provides best practices for managing identity and access.
The practice of identity and access management (generally referred to as IAM) helps you ensure that the right people can access the right resources. IAM addresses the following aspects of authentication and authorization:
- Account management, including provisioning
- Identity governance
- Access control (authorization)
- Identity federation
Managing IAM can be challenging when you have different environments or you use multiple identity providers. However, it's critical that you set up a system that can meet your business requirements while mitigating risks.
The recommendations in this document help you review your current IAM policies and procedures and determine which of those you might need to modify for your workloads in Google Cloud. For example, you must review the following:
- Whether you can use existing groups to manage access or whether you need to create new ones.
- Your authentication requirements (such as multi-factor authentication (MFA) using a token).
- The impact of workload identities on your current policies.
- If you're using Google Cloud for disaster recovery, maintaining appropriate separation of duties.
Within Google Cloud, you use Cloud Identity to authenticate your users and resources and Google's Identity and Access Management (IAM) product to dictate resource access. Administrators can restrict access at the organization, folder, project, and resource level. Google IAM policies dictate who can do what on which resources. Correctly configured IAM policies help secure your environment by preventing unauthorized access to resources.
For more information, see Overview of identity and access management.
Use a single identity provider
Many of our customers have user accounts that are managed and provisioned by identity providers outside of Google Cloud. Google Cloud supports federation with most identity providers and with on-premises directories such as Active Directory.
Most identity providers let you enable single sign-on (SSO) for your users and groups. For applications that you deploy on Google Cloud and that use your external identity provider, you can extend your identity provider to Google Cloud. For more information, see Reference architectures and Patterns for authentication corporate users in a hybrid environment.
Protect the super admin account
The super admin account (managed by Google Workspace or Cloud Identity) lets you create your Google Cloud organization. This admin account is therefore highly privileged. Best practices for this account include the following:
- Create a new account for this purpose; don't use an existing user account.
- Create and protect backup accounts.
- Enable MFA.
For more information, see Super administrator account best practices.
Plan your workload identities
Unlike your user accounts, workload identities are created and managed within Google Cloud. Workload identities are required by VMs, by Cloud Functions, and by all applications that make calls to Google APIs. You must consider an appropriate segregation of duties during your design process. Note the API calls that you require, and determine the workload identities and associated roles. For example, if you're setting up a BigQuery data warehouse, you probably need identities for at least the following processes and services:
- Cloud Storage or Pub/Sub, depending on whether you're providing a batch file or creating a streaming service.
- Dataflow and Cloud DLP to de-identify sensitive data.
Google Cloud workloads that call Google APIs typically use service accounts to get access to data. A service account is a Google account that belongs to your application or to a VM instead of to an individual end user. Your workloads use service accounts to call the Google API of a service. For more information, see Best practices for working with service accounts.
Alternatives to service accounts
Service accounts require you to download a service account key, which means that you need to secure and manage all copies of the key. If managing the key isn't practical for one of your scenarios, you can do the following:
- Limit the lifetime of the service account key by using short-lived service account credentials. This option is a good solution for testing environments.
- Use Workload identity federation or Workload Identity for Google Kubernetes Engine (GKE) applications. This option is good for production environments.
Not all Google Cloud services support these alternatives. For details, check the documentation of the services that you plan to use.
Update your identity processes for the cloud
Identity governance lets you track access, risks, and policy violations so that you can support your regulatory requirements. This governance requires that you have processes and policies in place so that you can grant and audit access control roles and permissions to users. Your processes and policies must reflect the requirements of your environments—for example, test, development, and production.
Before you deploy workloads on Google Cloud, review your current identity processes and update them if appropriate. Ensure that you appropriately plan for the types of accounts that your organization needs and that you have a good understanding of their role and access requirements.
To help you audit Google IAM activities, Google Cloud creates audit logs, which include the following:
- Administrator activity. This logging can't be disabled.
- Data access activity. You must enable this logging.
If necessary for compliance purposes, or if you want to set up log analysis (for example, with your SIEM system), you can export the logs. Because logs can increase your storage requirements, they might affect your costs. Ensure that you log only the actions that you require, and set appropriate retention schedules.
Set up SSO and MFA
Your identity provider manages user account authentication. Federated identities can authenticate to Google Cloud using SSO. For privileged accounts, such as super admins, you should configure MFA. Titan Security Keys are physical tokens that you can use for two-factor authentication (2FA) to help prevent phishing attacks.
Google Cloud supports authentication for workload identities using the OAuth 2.0 protocol or signed JSON Web Tokens (JWT). For more information about workload authentication, see Authentication overview.
Implement least privilege and separation of duties
You must ensure that the right individuals get access only to the resources and services that they need in order to perform their jobs. That is, you should follow the principle of least privilege. In addition, you must ensure there is an appropriate separation of duties.
Overprovisioning user access can increase the risk of insider threat, misconfigured resources, and non-compliance with audits. Underprovisioning permissions can prevent users from being able to access the resources they need in order to complete their tasks.
Be aware that when a Google Cloud organization is created, all users in your domain are granted the Billing Account Creator and Project Creator roles by default. Identify the users who will perform these duties, and revoke these roles from other users. For more information, see Creating and managing organizations.
For more information about how roles and permissions work in Google Cloud, see Overview and Understanding roles in the IAM documentation. For more information about enforcing least privilege, see Enforce least privilege with role recommendations.
To monitor the activities of privileged accounts for deviations from approved conditions, use Cloud Audit Logs. Cloud Audit Logs records the actions that members in your Google Cloud organization have taken in your Google Cloud resources. You can work with various audit log types across Google services. For more information, see Using Cloud Audit Logs to Help Manage Insider Risk (video).
Use IAM recommender to track usage and to adjust permissions where appropriate. The roles that are recommended by IAM recommender can help you determine which roles to grant to a user based on the user's past behavior and on other criteria. For more information, see Best practices for role recommendations.
To audit and control access to your resources by Google support and engineering personnel, you can use Access Transparency. Access Transparency records the actions taken by Google personnel. Use Access Approval, which is part of Access Transparency, to grant explicit approval every time customer content is accessed. For more information, see Control cloud administrators' access to your data.
Automate your policy controls
Set access permissions programmatically whenever possible. For best practices, see Organization policy setup. The Terraform scripts for this example foundation are in the example foundation repository.
Google Cloud includes Policy Intelligence, which lets you automatically review and update your access permissions. Policy Intelligence includes the Recommender, Policy Troubleshooter, and Policy Analyzer tools, which do the following:
- Provide recommendations for IAM role assignment.
- Monitor and help prevent overly permissive IAM policies.
- Assist with troubleshooting access-control-related issues.
Set restrictions on resources
Google IAM focuses on who, and it lets you authorize who can act on specific resources based on permissions. The Organization Policy Service focuses on what, and it lets you set restrictions on resources to specify how they can be configured. For example, you can use an organization policy to do the following:
- Limit resource sharing based on domain.
- Limit the use of service accounts.
- Restrict the physical location of newly created resources.
In addition to using organizational policies for these tasks, you can restrict access to resources using one of the following methods:
- Use tags to manage access to your resources without defining the access permissions on each resource. Instead, you add the tag and then set the access definition for the tag itself.
- Use IAM Conditions for conditional, attribute-based control of access to resources.
- Implement defense-in-depth using VPC Service Controls to further restrict access to resources.
For more about resource management, see Resource management.
Learn more about IAM with the following resources:
Implement compute and container security (next document in this series)