Core Services
IAM — Identity and Access Management
Google Cloud IAM is the foundational security layer that controls who can perform which actions on specific resources within your cloud environment. It matters because it enforces the principle of least privilege, preventing unauthorized access and minimizing the impact of potential security breaches. You reach for IAM whenever you need to provision access for users, service accounts, or external identities to interact with your cloud infrastructure.
Understanding Principals and Roles
At the heart of IAM are three core concepts: the principal, the resource, and the role. A principal is the 'who'—an individual user, a group, or a service account—requesting access. A resource is the 'what'—a bucket, a virtual machine, or an entire project. The role is the 'how,' a collection of individual permissions that define what actions are allowed. Unlike traditional systems where you grant permissions directly to a user, GCP mandates using roles to group these permissions. This abstraction is critical because it decouples the identity of the actor from the capability of the action. By assigning roles rather than raw permissions, you gain the ability to update authorization logic across your entire organization simply by modifying the role definition, rather than hunting through individual user accounts. This structure ensures that your security policy remains modular and manageable as your infrastructure grows in complexity and scale.
# Example of creating a custom role via gcloud CLI
# This defines a new role with specific permissions instead of using primitive ones
gcloud iam roles create "CustomComputeReader" \
--project=my-project-id \
--title="Compute Reader" \
--permissions=compute.instances.get,compute.instances.listThe Hierarchy of Policy Inheritance
IAM policies in GCP follow a hierarchical inheritance model, cascading downwards from the Organization level to Folders, Projects, and finally individual Resources. When a request is evaluated, GCP checks the policy at the resource level, then moves up the tree. If an access policy is granted at the project level, it automatically applies to all resources within that project unless explicitly restricted or overridden. This inheritance design is the primary reason for architectural simplicity; you can define broad security guardrails at the Organization level that govern thousands of projects without needing to repeat configuration. However, this also introduces risk: a misconfigured policy at a parent level creates a 'hidden' security vulnerability for every resource below it. Understanding this hierarchy allows you to reason about access gaps by tracing the chain of inheritance to see where a permission was granted and whether it was restricted further down the tree.
# Binding a role to a user at the project level
# This grants access to all resources within the specific project
gcloud projects add-iam-policy-binding my-project-id \
--member="user:engineer@example.com" \
--role="roles/storage.objectViewer"Service Accounts and Identity Delegation
Service accounts represent a special type of principal designed for non-human entities like applications, compute instances, or automated scripts. Because human users have passwords and multi-factor authentication, they are unsuitable for server-to-server communication. Service accounts bridge this gap by providing an identity for your code, allowing it to authenticate against GCP APIs. Crucially, you should never share or hard-code service account keys. Instead, use Identity Delegation, where a compute resource is 'attached' to a service account. This allows the application to automatically obtain short-lived tokens, reducing the risk of credential leakage. By assigning granular roles to specific service accounts rather than the instances themselves, you ensure that even if an application is compromised, the attacker is limited strictly to the permissions granted to that unique service account. This pattern of 'Workload Identity' is the modern standard for secure cloud-native application communication.
# Creating a dedicated service account for a microservice
gcloud iam service-accounts create "order-processor-sa" \
--display-name="Service account for processing orders"Conditions and Context-Aware Access
Static IAM policies are often too blunt, granting access regardless of the situation. IAM Conditions provide a way to add 'context' to a role binding, such as time, date, or specific request attributes. You can restrict access to a resource based on the source IP address or whether the request occurred during specific working hours. By embedding conditions into your policy, you move beyond identity-based security into policy-based access control. For example, you can grant a developer access to a database bucket, but add a condition that this access is only valid if the request originates from your corporate VPN. This works by evaluating the request context in real-time before granting access, adding an extra layer of defense against credential theft where the identity might be correct but the context is suspicious. This reasoning is vital for protecting sensitive production environments from access outside of authorized networks.
# Binding a role with a condition to restrict access by time
gcloud projects add-iam-policy-binding my-project-id \
--member="user:analyst@example.com" \
--role="roles/bigquery.dataViewer" \
--condition="expression=request.time < timestamp('2025-01-01T00:00:00Z'),title=Expires2025"Auditing and Policy Analysis
Even with perfect design, security requires continuous verification. GCP provides the Policy Troubleshooter and IAM Recommender to help identify 'over-privileged' principals. The Policy Troubleshooter allows you to simulate a request to understand exactly why a user was denied or granted access, effectively de-bugging the inheritance tree. The Recommender goes a step further, analyzing usage patterns to identify roles that are assigned but never used, or service accounts that have more permissions than their actual activity suggests. This is the 'why' of effective lifecycle management: as roles evolve and project scope changes, human error often results in permission creep. Regular automated auditing allows you to shrink the attack surface by identifying and removing unused permissions, ensuring that your environment remains compliant with the principle of least privilege over the long term, preventing security drift in dynamic cloud environments.
# Using the Policy Troubleshooter to diagnose an access issue
# This identifies why a specific user is failing to list instances
gcloud beta iam policy-troubleshoot \
--principal="user:dev@example.com" \
--resource="compute.googleapis.com/projects/my-project/zones/us-central1-a/instances/my-vm" \
--permission="compute.instances.list"Key points
- Principals are the identities of users or services that interact with GCP resources.
- Roles act as collections of permissions that are assigned to principals.
- IAM policy inheritance flows downwards from the Organization to specific resources.
- Service accounts should be used for all automated processes instead of human user credentials.
- The principle of least privilege dictates granting only the minimum permissions necessary for a task.
- IAM Conditions allow for dynamic access control based on context like time or request source.
- Policy Troubleshooter helps debug access denials caused by complex hierarchical policies.
- Regular auditing is essential to identify and remove unused or excessive permissions from principals.
Common mistakes
- Mistake: Granting the Owner primitive role to every user. Why it's wrong: Owner provides full access to all resources and billing, violating the principle of least privilege. Fix: Use predefined or custom roles scoped to the specific tasks a user needs to perform.
- Mistake: Assigning permissions to individual user accounts instead of groups. Why it's wrong: It creates an administrative nightmare when people join or leave the team. Fix: Assign roles to Google Groups and manage membership within the group.
- Mistake: Confusing Service Accounts with User Accounts. Why it's wrong: Service accounts are for non-human identities; using them for human access bypasses security audits. Fix: Use User accounts for humans and Service accounts for virtual machines or applications.
- Mistake: Applying IAM policies at the organization level when they should be at the project level. Why it's wrong: Broad policies inherit downwards, exposing sensitive resources accidentally. Fix: Apply policies at the most granular level possible (resource or project).
- Mistake: Not rotating Service Account keys. Why it's wrong: Stale, leaked keys provide permanent backdoors into your infrastructure. Fix: Use Workload Identity or rotate keys regularly and delete unused ones.
Interview questions
What is the basic purpose of Cloud IAM in Google Cloud, and what are the three components of an IAM policy?
Cloud IAM in Google Cloud is a unified service that allows you to manage access control by defining who can do what on which specific resources. It provides a centralized security model for your entire cloud infrastructure. The three components of an IAM policy are the 'member', which identifies who is granted access, such as a user, a service account, or a Google group; the 'role', which is a collection of permissions that define what actions can be performed; and the 'resource', which is the specific GCP asset, like a Compute Engine instance or a Cloud Storage bucket, to which the access is applied.
Can you explain the difference between Primitive roles and Predefined roles in Google Cloud IAM?
Primitive roles—specifically Owner, Editor, and Viewer—are legacy roles that apply across an entire project. They are extremely broad and should be avoided in production environments because they violate the principle of least privilege. In contrast, Predefined roles are managed by Google Cloud and offer more granular access to specific services. For example, a 'Storage Object Viewer' role grants read access only to Cloud Storage objects, whereas a Primitive Viewer role would grant broad visibility across every service in the project. You should always prefer Predefined roles to ensure that identities only have the permissions necessary for their specific tasks.
What is a Service Account in Google Cloud, and why is it preferred over using user credentials for application code?
A Service Account is a special type of Google account that belongs to your application or a virtual machine rather than to an individual end-user. It is used to authenticate application-to-application interactions. Using a service account is critical because it decouples your application from personal user identities, which may change or be deleted. By assigning a service account to a compute resource, you can use Application Default Credentials to allow the code to call Google Cloud APIs securely. This eliminates the need to manage static credentials or API keys, which are prone to leaks and security vulnerabilities.
Compare using Custom Roles versus Predefined roles for your organization's security requirements.
Predefined roles are maintained by Google and are updated automatically as new features are added to services, making them the default choice for most use cases. However, if your security policy requires very specific, fine-grained access that isn't covered by predefined roles—or if you need to adhere to strict 'least privilege' compliance—you should use Custom Roles. Custom Roles allow you to bundle only the specific permissions needed for a job function. The downside is the administrative overhead; you must manually update the Custom Role permissions if new API features are required for your workflow, unlike Predefined roles which are managed centrally by Google Cloud.
What is IAM Conditions, and how does it change the way we evaluate access control?
IAM Conditions allow you to define and enforce conditional access to your Google Cloud resources based on specific attributes like request time, request source, or resource name. Before IAM Conditions, access was binary; if you had the role, you had the access at all times. With conditions, you can implement logic such as 'Allow this service account access to this bucket only if the request originates from a specific IP range.' You define these in the policy using Common Expression Language (CEL). This is essential for zero-trust architectures where identity alone is not sufficient to guarantee that a request is safe or authorized.
Explain the GCP IAM policy inheritance model and how you can override access at lower levels in the hierarchy.
In Google Cloud, IAM policies are inherited downward through the resource hierarchy, from Organization to Folders, then to Projects, and finally to individual resources. If you grant a role at the Project level, that permission is automatically granted to all child resources within that project. To override or restrict access, you can use 'Deny Policies', which take precedence over 'Allow Policies'. Furthermore, because policies are additive, removing access at a lower level isn't possible if a parent-level policy explicitly grants it; you must instead refine the policy at the top level or utilize the resource hierarchy effectively to ensure that high-level permissions are limited to administrators while specific resources maintain restricted access lists.
Check yourself
1. An application running on a Compute Engine instance needs to read files from a Cloud Storage bucket. What is the most secure way to grant this access?
- A.Create a service account, assign the 'Storage Object Viewer' role to it, and attach it to the instance.
- B.Store a JSON service account key in the instance's metadata and read it from code.
- C.Grant the 'Storage Object Viewer' role directly to the Compute Engine default service account.
- D.Make the Cloud Storage bucket public so the instance can access it without authentication.
Show answer
A. Create a service account, assign the 'Storage Object Viewer' role to it, and attach it to the instance.
Attaching a custom service account is correct because it uses Workload Identity. Storing keys is insecure. Granting the default service account broad access violates least privilege. Making the bucket public is a security vulnerability.
2. A developer needs the ability to start and stop Compute Engine instances but should not be able to delete them. How should this be handled?
- A.Grant the developer the 'Compute Admin' role.
- B.Create a custom role containing only 'compute.instances.start' and 'compute.instances.stop' permissions.
- C.Grant the 'Viewer' role to the developer.
- D.Assign the 'Owner' role to the developer.
Show answer
B. Create a custom role containing only 'compute.instances.start' and 'compute.instances.stop' permissions.
Custom roles are the only way to satisfy the specific constraint of allowing stop/start without deletion. Compute Admin and Owner include delete permissions. Viewer only allows reading, not performing actions.
3. Which statement best describes the hierarchy of IAM policy inheritance in Google Cloud?
- A.Policies defined at the resource level override policies at the project level.
- B.Policies at the Organization, Folder, and Project levels are additive.
- C.Policies at lower levels override policies at the Organization level.
- D.Permissions are only effective if defined at the project level.
Show answer
B. Policies at the Organization, Folder, and Project levels are additive.
IAM policies are additive; an identity receives the union of all permissions granted at the Organization, Folder, Project, and Resource levels. They do not override each other, and they are not restricted to just the project level.
4. Your team needs to allow an external auditor read-only access to a specific project for one week. What is the best practice?
- A.Create a shared service account and give the auditor the credentials.
- B.Grant the auditor the 'Viewer' role at the project level and remove it after a week.
- C.Grant the auditor the 'Owner' role to ensure they can see everything, then remove it.
- D.Use a temporary 'Owner' role at the folder level.
Show answer
B. Grant the auditor the 'Viewer' role at the project level and remove it after a week.
Granting the 'Viewer' role provides necessary read-only access. Sharing service accounts is a security breach. Owner is excessive and violates least privilege, and folder-level access is too broad.
5. What happens if a user is granted the 'Storage Object Admin' role on a bucket and the 'Viewer' role on the project containing that bucket?
- A.The user only has 'Viewer' permissions because the project level is higher.
- B.The user only has 'Storage Object Admin' permissions because specific resource policies override general ones.
- C.The user has the combined permissions of both roles.
- D.The user is denied access because of conflicting role levels.
Show answer
C. The user has the combined permissions of both roles.
IAM permissions are additive. The user receives all permissions from both roles. There is no conflict or override mechanism; the result is the union of all granted rights.