GCP Security Services

Cloud IAM is the foundational security service for controlling access to GCP resources. It uses a unified system of who (identity), what (role), and which (resource) to define permissions. Identities can be Google Accounts, Service Accounts, Google Groups, or Cloud Identity domains. Roles are collections of permissions; there are three types: primitive roles (Owner, Editor, Viewer), predefined roles (fine-grained, managed by Google), and custom roles (user-defined). Resources are organized hierarchically: Organization > Folder > Project > Resource. Permissions are inherited down the hierarchy.

Key Mechanism: When a request is made, IAM evaluates all policies that apply to the resource and the requester's identity. The effective permission is the union of all granted permissions minus any denied permissions (if using deny policies). IAM uses a deny-by-default model: no access unless explicitly granted.

Important Defaults: - New projects have no IAM members except the creator (who gets Owner role). - Service accounts are automatically created for Compute Engine and App Engine with Editor role on the project by default (can be restricted). - Primitive roles are broad and not recommended for production.

Commands:

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member='user:email@example.com' \
    --role='roles/compute.instanceAdmin'
gcloud iam roles describe roles/compute.instanceAdmin

VPC Service Controls (VPC-SC) provide a security perimeter around Google Cloud managed services (like BigQuery, Cloud Storage, Bigtable) to mitigate data exfiltration risks. They work by creating service perimeters that define which projects and services are protected. Requests crossing the perimeter are evaluated against access levels (based on IP, device, etc.) and ingress/egress rules.

How it works internally: 1. A service perimeter is defined with a set of projects (the protected project set). 2. All services within those projects are considered "inside" the perimeter. 3. When a request is made to a protected service, VPC-SC checks if the request originates from inside the perimeter (based on source project and network). 4. If the request crosses the perimeter (e.g., from a VM outside), it is either blocked or allowed based on ingress rules. 5. Dry-run mode allows testing policies without enforcement.

Key Defaults: - By default, no perimeters exist; all services are open. - When a perimeter is created, all projects inside it are restricted: no data can be copied out to non-perimeter projects. - Access levels can use IP ranges, device policies, or time constraints.

Commands:

gcloud access-context-manager perimeters create PERIMETER_NAME \
    --title='My Perimeter' \
    --resources='projects/PROJECT_NUMBER' \
    --restricted-services='bigquery.googleapis.com' \
    --spec-dry-run

Cloud Armor is a web application firewall (WAF) that protects HTTP(S) load-balanced applications from DDoS attacks and web attacks. It uses security policies with rules that match on characteristics like IP, geo-location, or layer 7 attributes. It integrates with Cloud CDN and Cloud Load Balancing.

Key Components: - Security policies: Attached to a backend service or target proxy. - Rules: Each rule has a condition (e.g., source IP range) and action (allow or deny). Rules are evaluated in priority order (lower number = higher priority). - Preconfigured rules: Google provides rules for OWASP Top 10 (SQL injection, XSS, etc.) called WAF rules. - Rate limiting: Can limit requests per client IP.

Defaults: - Default rule at priority 2147483647 allows all traffic if no explicit deny matches. - WAF rules are evaluated after custom rules. - Cloud Armor is only available with HTTP(S) Load Balancing (external or internal).

Commands:

gcloud compute security-policies create my-policy \
    --description='My security policy'
gcloud compute security-policies rules create 1000 \
    --security-policy=my-policy \
    --src-ip-ranges='192.0.2.0/24' \
    --action=deny-403

Cloud KMS manages cryptographic keys for encrypting data at rest. It supports symmetric and asymmetric keys, and integrates with Cloud Storage, BigQuery, Compute Engine (disk encryption), and other services. Keys are stored in a key ring within a location (global or regional).

Key Mechanism: 1. Create a key ring (logical grouping). 2. Create a crypto key inside the key ring (the actual key material). 3. Use key versions for rotation; each version has a state (enabled, disabled, destroyed). 4. To encrypt data, a client calls Cloud KMS API; the service encrypts the data with the key and returns ciphertext. The key never leaves Cloud KMS. 5. Customer-managed encryption keys (CMEK) allow you to control key lifecycle.

Defaults: - Key rotation period: 90 days (can set from 1 day to 1,000,000 days). - Key rings are location-scoped; keys cannot be moved between key rings. - Key material is protected by FIPS 140-2 Level 3 validated HSMs.

Commands:

gcloud kms keyrings create my-keyring --location=global
gcloud kms keys create my-key --location=global --keyring=my-keyring --purpose=encryption
gcloud kms encrypt --plaintext-file=./plain.txt --ciphertext-file=./encrypted.enc \
    --location=global --keyring=my-keyring --key=my-key

Secret Manager stores API keys, passwords, certificates, and other sensitive data. It provides a centralized place to manage secrets with versioning, access control via IAM, and automatic replication across regions.

How it works: 1. Create a secret with a name and payload (the secret value). 2. Access secrets via API or gcloud command; the secret is decrypted and returned in plaintext. 3. Secrets are versioned; you can access by version ID or use the latest. 4. IAM roles (Secret Manager Secret Accessor) control who can read secrets.

Defaults: - Secrets are replicated to the region where they are created unless you specify multiple regions. - Secret payload is encrypted at rest with AES-256. - There is no automatic rotation; you must manually create a new version.

Commands:

gcloud secrets create my-secret --replication-policy=automatic
echo -n 'my-password' | gcloud secrets versions add my-secret --data-file=-
gcloud secrets versions access latest --secret=my-secret

Security Command Center (SCC) is a centralized security and risk management platform. It provides visibility into misconfigurations, vulnerabilities, and threats across GCP resources. It uses findings generated by built-in services (e.g., Cloud Asset Inventory, Web Security Scanner) and third-party integrations.

Key Components: - Assets: GCP resources like VMs, buckets, datasets. - Findings: Security issues (e.g., open firewall ports, public buckets, IAM over-privilege). - Sources: Built-in and third-party providers that generate findings. - Notifications: Can send findings to Pub/Sub, Cloud Functions, or Security Operations.

Tiers: - Standard (free): Basic security health analytics, asset discovery, and vulnerability scanning. - Premium: Includes Event Threat Detection, Container Threat Detection, and more.

Defaults: - SCC is enabled at the organization level. - It automatically discovers all projects in the organization. - Findings are retained for 7 days (Standard) or 30 days (Premium).

Commands:

gcloud scc assets list --organization=ORGANIZATION_ID
gcloud scc findings list --organization=ORGANIZATION_ID --source=SOURCE_ID

Cloud Audit Logs record administrative actions, data access, and system events. There are four types: - Admin Activity: Logs API calls that modify configuration (retained 400 days). - Data Access: Logs API calls that read or modify user-provided data (retained 30 days). - System Event: Logs GCP actions that modify resources (retained 400 days). - Policy Denied: Logs when a request is denied due to IAM deny policies (retained 30 days).

Key Mechanism: 1. Audit logs are generated automatically for all services. 2. They are stored in Cloud Logging buckets (default: _Required bucket for Admin Activity and System Event, _Default bucket for Data Access). 3. You can export logs to Cloud Storage, BigQuery, or Pub/Sub for long-term retention. 4. Data Access logs are disabled by default; you must enable them per service.

Defaults: - Admin Activity logs are always enabled and free. - Data Access logs are disabled by default; enabling them incurs costs. - Retention: 400 days for Admin Activity and System Event; 30 days for Data Access and Policy Denied.

Commands:

gcloud logging read 'logName="projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Factivity"' --limit=10
gcloud logging buckets create my-bucket --location=global --retention-days=365

These services work together. For example, Cloud Armor protects load-balanced apps; VPC-SC prevents data exfiltration from BigQuery; Cloud KMS encrypts secrets in Secret Manager; SCC aggregates findings from all; audit logs capture actions. A typical secure architecture uses IAM for access control, VPC-SC for data boundaries, Cloud Armor for edge security, and SCC for monitoring.

A bank uses BigQuery to store transaction data. They must comply with PCI DSS and SOC 2. They deploy VPC Service Controls with a perimeter around the BigQuery project. Only applications running in authorized VPCs can query the data. They use Cloud KMS with CMEK to encrypt the data at rest, rotating keys every 90 days. Cloud Audit Logs track all queries, and SCC alerts on any public bucket or over-privileged IAM role. Misconfiguration: Initially, they forgot to add the data ingestion pipeline's service account to the perimeter's ingress rules, causing all writes to fail. They resolved by adding an ingress rule from the pipeline's project.

An online retailer uses HTTP(S) Load Balancing with Cloud Armor. During a flash sale, they expect high traffic but also want to block bots. They configure rate limiting at 100 requests per second per IP. They also block traffic from known malicious IP ranges using a deny rule. Cloud Armor logs show that 95% of blocked traffic came from automated scripts. They also use Cloud CDN to cache static content, reducing load on backend. The security policy is updated dynamically via Cloud Functions when new threat intelligence is received.

A SaaS company uses GCP for data processing and AWS for frontend. They store API keys in Secret Manager with automatic replication to multiple regions for low latency. They use IAM to grant access to the keys only to specific service accounts. They enable Data Access audit logs for Secret Manager to detect unauthorized access attempts. A common issue: developers hardcode secrets in code; Secret Manager prevents this by providing a centralized, auditable store.