Security Best Practices for Google Cloud ACE
Security in Google Cloud is a shared responsibility. While Google secures the underlying infrastructure (data centers, hardware, and global network), the customer is responsible for securing what they put “in” the cloud, such as data, identity access, and network configurations.
The “Secure Office Building” Analogy
Think of GCP Security as a high-security office building:
- Organization/Folders: The building and its floors. You define who can enter the lobby.
- Projects: Individual locked offices. Even if someone is in the building, they need a specific key for an office.
- IAM Roles: The “Access Badge.” A janitor has a badge to clean (limited access), while a CEO has a badge for everything.
- Cloud KMS: The “Safe” inside the office. Even if someone breaks in, they can’t read the documents without the safe combination.
Core Concepts: Deep Dive
1. Identity and Access Management (IAM)
IAM allows you to manage access control by defining who (identity) has what access (roles) to which resource. The Golden Rule is the Principle of Least Privilege: only give users the minimum permissions they need to do their job.
2. Resource Hierarchy
Security policies are inherited from the top down: Organization > Folder > Project > Resource. If you grant “Owner” at the Folder level, that user is an “Owner” of every Project inside that folder. Exam Tip: Always check for inherited permissions when troubleshooting access issues.
Comparison: IAM Role Types
| Role Type | Flexibility | Management Overhead | Best Use Case |
|---|---|---|---|
| Primitive (Owner, Editor, Viewer) | Low (Too broad) | Very Low | Development environments or very small teams. |
| Predefined (e.g., Storage Admin) | Medium | Low | Standard production tasks; Google-managed. |
| Custom | High | High | Specific compliance needs where Predefined roles are too broad. |
Scenario-Based Decision Matrix
| If the Requirement is… | Then Use… |
|---|---|
| Granting a service permission to write to a bucket | Service Account with roles/storage.objectCreator |
| Restricting access to GCP APIs based on IP/Location | VPC Service Controls |
| Managing encryption keys yourself | Cloud KMS (Customer-Managed Encryption Keys – CMEK) |
| Auditing who did what and when | Cloud Audit Logs |
Exam Tips: ACE Golden Nuggets
- Never use Primitive Roles in Production: The exam will often offer “Editor” as an answer; it’s almost always a distractor for a more specific Predefined role.
- Service Account Keys: Avoid downloading JSON keys. Use Workload Identity for GKE or attached Service Accounts for VM instances.
- IAM Inheritance: You cannot “restrict” a permission at a lower level if it was granted at a higher level. Permissions are additive.
- Firewall Rules: Implicit deny for ingress, implicit allow for egress. Use “Target Tags” or “Service Accounts” rather than IP ranges for internal VM-to-VM security.
GCP Security Architecture Overview
Key GCP Services
- Cloud IAM: Identity management.
- Cloud Identity: Syncing AD/LDAP users.
- Cloud KMS: Managing encryption keys.
- VPC Firewalls: Network-level control.
Common Pitfalls
- Using owner role for apps.
- Leaving Default VPC rules open (0.0.0.0/0).
- Storing API keys in public GitHub repos.
- Ignoring Cloud Audit Logs.
Architecture Patterns
- Shared VPC: Centralized network control.
- Bastion Host: Secure entry to private VMs.
- Least Privilege: Custom roles for high security.
- Data Masking: Using Cloud DLP.