Professional Cloud Developer
Gauge your current knowledge
Gauge your current knowledge
Google Cloud manages three main types of identities: corporate identities for employees, customer identities for app users, and service identities for applications. Identity and Access Management (IAM) is the framework that controls which individuals can access which resources, and centralized identity management lets organizations enforce security policies like multi-factor authentication across all user types.
When applications need to communicate, they use different types of tokens to prove who they are. OAuth 2.0 access tokens are used for authorization, letting an application access specific API resources. In contrast, OpenID Connect (OIDC) ID tokens are used for authentication to verify the identity of the user. Choosing the correct token type is essential for maintaining a secure cloud-native architecture.
Identity Platform provides customer identity and access management (CIAM) for managing end-users. It supports multi-tenancy, which creates isolated groups of users and configurations within a single project. This service handles social sign-on (letting users log in with Google or Facebook), multi-factor authentication for extra security, and custom claims for fine-grained access control.
Applications running on Google Cloud use Application Default Credentials (ADC) to automatically find credentials without hardcoding secrets. ADC relies on service accounts, which act as the identity for a workload rather than a person. It is a best practice to attach service accounts to resources like virtual machines and follow the principle of least privilege, granting only the permissions necessary for each task.
For external services from other clouds like AWS or Azure, developers use Workload Identity Federation (WIF). This method lets external workloads access Google Cloud resources without storing risky service account keys. WIF uses the Security Token Service (STS) to exchange external tokens for short-lived Google Cloud tokens, reducing the risk of credential leakage.
Application Default Credentials (ADC) is a strategy Google client libraries use to automatically find credentials for authenticating with Google Cloud services. This process allows developers to write code that works across different environments, such as a local laptop or a cloud server, without changing the authentication logic. ADC searches for credentials in a specific order, starting with the GOOGLE_APPLICATION_CREDENTIALS environment variable and ending with the internal metadata server.
For local development, you can set up ADC using your own user account by running the gcloud auth application-default login command, which creates a local credential file that client libraries can use. Using your own credentials for local testing is more secure than creating and downloading service account keys, which can be easily lost or stolen.
If you need to test specific permissions, use service account impersonation, which allows a principal to temporarily act as a service account without needing a static JSON key. The user must be granted the Service Account Token Creator role to use this feature. This method significantly reduces security risks by providing short-lived access instead of permanent credentials.
When running applications in production on Google Cloud, the preferred method is to use an attached service account. ADC automatically communicates with the metadata server to retrieve credentials for the resource, such as a virtual machine or container. This ensures your application is securely identified without requiring manual secret file management.
Secure application design follows the principle of least privilege, granting only the minimum permissions required for a specific task. To maintain security, avoid static JSON keys to prevent credential leakage, create single-purpose service accounts for each application for clear auditing, and use Workload Identity Federation for applications running on-premises or on other cloud providers.
The Cloud SQL Auth Proxy and AlloyDB Auth Proxy establish secure, encrypted connections to managed databases. These proxies create a secure TCP tunnel that handles authentication through IAM, removing the need for manual SSL configuration. Using these proxies ensures database traffic is automatically encrypted and authorized without exposing the database to the public internet.
These proxies provide strong encryption by automatically handling TLS certificates, integrate with IAM to control who can connect using existing Google Cloud permissions, and simplify networking by eliminating the need to manage complex firewall rules. IAM Database Authentication lets applications connect using Google Cloud identities instead of traditional static passwords, providing unified access control across all cloud resources. Using short-lived access tokens significantly reduces the risk of credential theft compared to long-term database credentials.
Workload Identity Federation (WIF) enables keyless authentication for workloads running outside Google Cloud, such as on-premises servers or other cloud providers. Instead of using risky long-lived service account keys, WIF allows external systems to exchange their own identity tokens for temporary Google Cloud credentials. This approach follows the OAuth 2.0 token exchange specification to provide a secure way for multicloud applications to access Google services.
For managing end-user identities, Identity Platform offers a robust CIAM solution supporting various authentication protocols and providing advanced security features like Multi-Factor Authentication (MFA). Implementing these tools helps developers build secure login flows that integrate with Google's security intelligence and protect against automated attacks.
Securing the network layer involves using VPC Service Controls and Transport Layer Security (TLS) to protect data as it moves between services. Private Service Connect allows traffic to stay within the Google Cloud network, avoiding risks associated with the public internet. Maintaining a defense-in-depth strategy ensures that even if one security layer is bypassed, the database and its sensitive data remain protected through multiple levels of authorization.