Configuring access

Managing Cloud Identity

Cloud Identity is Google's service for managing users, groups, and devices across an organization. It serves as the central identity provider that connects people to Google Cloud resources. Cloud Identity can sync with on-premises Active Directory or work as a standalone identity solution. It supports multi-factor authentication (MFA), which adds an extra security layer beyond just passwords. Organizations use Cloud Identity to control who can access what resources and to manage the complete user lifecycle from onboarding to offboarding.

Managing Service Accounts

Service accounts are special identities used by applications and virtual machines to authenticate to Google Cloud services. Unlike user accounts, service accounts do not require human login credentials; instead, they use cryptographic keys. When an application needs to access cloud resources, it presents the service account's credentials, and IAM checks whether that account has permission to perform the requested action. Organizations should follow the principle of least privilege by granting only the permissions the application actually needs. Service account keys should be rotated regularly and never stored in source code repositories.

Managing Authentication

Authentication verifies who is trying to access Google Cloud before deciding what they can do. Google Cloud supports several authentication methods: users can sign in with email and password combined with MFA, while applications use service account keys or workload identity. OAuth 2.0 is the standard protocol for granting API access, and Identity-Aware Proxy (IAP) adds an extra verification layer for browser-based applications. The authentication flow always begins with the caller presenting credentials, which the platform validates before any authorization decisions are made.

Managing and Implementing Authorization Controls

IAM (Identity and Access Management) is Google's system for deciding what authenticated identities can do with specific resources. An IAM policy consists of bindings that connect a principal (who), a role (what they can do), and a resource (where the permission applies). Roles come in three types: primitive roles that are broad, predefined roles designed for specific services, and custom roles for specialized permission sets. Policies flow down the resource hierarchy, meaning a permission granted at the organization level applies to all folders, projects, and resources beneath it. Conditional IAM grants access only when certain attributes are met, such as time of day or IP address.

Defining the Resource Hierarchy

Google Cloud organizes resources in a hierarchical structure with the organization node at the top, followed by folders, then projects, and finally individual resources like virtual machines or storage buckets. The organization node represents the company and is where organization-wide policies live. Folders can contain multiple projects or nested folders, useful for separating departments or environments. Projects group related resources together and are the level where billing and permissions are most commonly managed. Because policies inherit downward, a permission granted at a higher level automatically applies to everything below it.