Security Best Practices for Google Cloud
In the Google Cloud ecosystem, security is not a bolted-on feature but a foundational layer. For the Associate Cloud Engineer (ACE) exam, security revolves primarily around Identity and Access Management (IAM), resource hierarchy, and the Shared Responsibility Model. Understanding how to restrict access while enabling productivity is the core challenge of a Cloud Engineer.
The “Airport Security” Analogy
Think of Google Cloud security like an international airport:
- The Passport (Authentication): Confirms who you are (User account/Service account).
- The Boarding Pass (Authorization/IAM): Confirms where you are allowed to go (Terminal A, but not the Cockpit).
- The Security Gate (VPC Service Controls): Ensures that even with a boarding pass, you can’t carry restricted items between different zones.
- The Luggage Lock (Encryption): Ensures that if someone steals your bag, they can’t see what’s inside (Cloud KMS).
Core Concepts: Defense in Depth
Google Cloud follows the Principle of Least Privilege (PoLP). This means giving a user or service only the exact permissions they need to perform their job, and nothing more. This is achieved through:
- Resource Hierarchy: Applying policies at the Organization, Folder, Project, or Resource level. Permissions inherit downwards.
- IAM Roles: Moving away from “Primitive” roles (Owner, Editor, Viewer) toward “Predefined” roles (e.g., Storage Object Viewer).
- Service Accounts: Identities for applications rather than humans, used to interact with GCP APIs securely.
Comparison: IAM Role Types
| Role Type | Granularity | Best Use Case | ACE Exam Consideration |
|---|---|---|---|
| Primitive | Coarse (Project-wide) | Development/Sandbox only. | Avoid in production; too much permission. |
| Predefined | Fine-grained (Service-specific) | Standard production tasks. | The “Correct” answer for most scenarios. |
| Custom | Ultra-fine (Permission-specific) | When Predefined roles are still too broad. | Requires maintenance; don’t use if Predefined exists. |
Scenario-Based Decision Matrix
| If the requirement is… | Then use… |
|---|---|
| Granting a developer access to only one specific GCS bucket | IAM Policy Binding at the Resource level. |
| An application on GCE needs to upload files to Cloud Storage | A Service Account with roles/storage.objectCreator. |
| Preventing any project in the org from having public IP addresses | Organization Policy constraints. |
| Auditing who did what and when in a project | Cloud Audit Logs (Admin Activity and Data Access). |
Exam Tips: Golden Nuggets
- Inheritance is Key: If a user is an “Editor” at the Folder level, you cannot “deny” that permission at the Project level. Permissions are additive.
- Never use Service Account Keys in code: Use Application Default Credentials (ADC) or attach the Service Account to the resource (VM/Function).
- The “Least Privilege” Rule: If an exam question offers “Owner” and “Storage Object Admin,” and the user only needs to manage files, “Storage Object Admin” is the correct choice.
- Audit Logs: Admin Activity logs are always on (free); Data Access logs must be manually enabled (cost associated).
Visualizing GCP Security Architecture
Layers of Protection & Identity Flow
The request flow: Identity -> IAM Check (Roles/Permissions) -> Access to Resource Hierarchy
Key GCP Services
- Cloud IAM: Identity management.
- Identity-Aware Proxy (IAP): Access apps without VPNs.
- Cloud KMS: Manage encryption keys.
- Cloud Armor: WAF and DDoS protection.
Common Pitfalls
- Using Primitive Roles in production.
- Leaving Default Service Accounts with Editor access.
- Storing JSON keys in GitHub repositories.
- Ignoring Firewall Rules (0.0.0.0/0).
Quick Patterns
- Shared VPC: Centralize network security.
- Bastion Host: Secure SSH access to private VMs.
- Workload Identity: Link GKE pods to IAM.