Cloud Security Patterns

---

name: cloud-security-patterns description: Cloud security reference architectures and best practices for GCP, AWS, and Azure tags: [cloud, security]

Cloud Security Patterns

Overview

Cloud security operates under a shared responsibility model: the cloud provider secures the infrastructure, while the customer secures their workloads, data, and configurations. Misunderstanding this boundary is the root cause of most cloud security incidents.

This skill provides reference architectures and actionable patterns across five security domains:

Domain	Key Concerns
Identity	IAM policies, service accounts, workload identity
Network	VPC design, firewalls, private connectivity, WAF
Data	Encryption, key management, DLP, data residency
Compute	Instance hardening, container security, serverless
Logging	Audit trails, monitoring, alerting, forensics

Provider-specific guidance is included for GCP (primary for FAOS), AWS, and Azure, with emphasis on GCP patterns that directly apply to the FAOS platform.

Shared Responsibility Model

+-------------------------+------------------------------------------+
|                         |   Customer Responsibility                |
|  SaaS                   |   Data, access policies, usage config    |
+-------------------------+------------------------------------------+
|  PaaS / Containers      |   Applications, data, access, config     |
|  (GKE, EKS, AKS)       |   Workload security, network policies    |
+-------------------------+------------------------------------------+
|  IaaS                   |   OS, network config, firewall, data     |
|  (GCE, EC2, Azure VMs)  |   Patching, identity, encryption         |
+-------------------------+------------------------------------------+
|  Provider               |   Physical security, hypervisor, global  |
|  Responsibility         |   network, hardware, core services       |
+-------------------------+------------------------------------------+

When to Use This Skill

• You are designing the security architecture for a new cloud deployment
• You are migrating workloads to the cloud and need to establish security controls
• You are reviewing cloud infrastructure code (Terraform, Pulumi) for security issues
• You need to harden an existing GKE, EKS, or AKS cluster
• You are implementing IAM policies and need least-privilege guidance
• You are preparing for a cloud security audit (SOC 2, ISO 27001, CIS)

How It Works

Step 1: Classify Workloads

Before applying security controls, classify workloads by sensitivity and exposure:

Classification	Data Types	Security Controls
Public	Marketing content, docs	Basic: WAF, DDoS protection
Internal	Business data, internal APIs	Standard: VPC, IAM, encryption
Confidential	Customer PII, financial data	Enhanced: CMEK, DLP, audit logs
Restricted	Secrets, keys, auth tokens	Maximum: HSM, dedicated tenancy

This classification drives decisions for network isolation, encryption, access control, and monitoring.

Step 2: Design Network Boundaries

Implement defense-in-depth through network segmentation:

Internet
    |
[Cloud Load Balancer + WAF + Cloud Armor]
    |
[Public Subnet / DMZ]
    |--- Web tier (frontend, API gateway)
    |
[Private Subnet]
    |--- Application tier (GKE, compute)
    |--- Service mesh (mTLS between services)
    |
[Restricted Subnet]
    |--- Data tier (Cloud SQL, Redis, storage)
    |--- No internet access, VPC-SC perimeter

Key network security patterns:

• Private GKE clusters: Control plane and nodes have no public IPs
• VPC Service Controls: Create security perimeters around GCP services to prevent data exfiltration
• Private Google Access: Reach Google APIs without traversing the public internet
• Cloud NAT: Controlled egress for private instances that need internet access
• Firewall rules: Default-deny ingress, explicit allow rules with source filtering

Step 3: Implement IAM Policies

IAM is the most critical security control in cloud environments. A misconfigured IAM policy can expose an entire organization.

Principle of Least Privilege:

# GCP: Grant minimum required roles
# BAD - overly broad
gcloud projects add-iam-policy-binding $PROJECT \
  --member="serviceAccount:app-sa@$PROJECT.iam.gserviceaccount.com" \
  --role="roles/editor"

# GOOD - specific to need
gcloud projects add-iam-policy-binding $PROJECT \
  --member="serviceAccount:app-sa@$PROJECT.iam.gserviceaccount.com" \
  --role="roles/cloudsql.client"

Service Account Patterns:

Pattern	Use Case	Security Level
Workload Identity	GKE pods accessing GCP services	Highest
Attached SA	GCE instances with scoped roles	High
SA Key (JSON)	External systems (avoid if possible)	Medium
User credentials	Development only	Low

Step 4: Enable Encryption

Encryption must cover data at rest and in transit:

At Rest:

• Default encryption: All major cloud providers encrypt data at rest by default
• CMEK (Customer-Managed Encryption Keys): Use Cloud KMS to control key lifecycle
• CSEK (Customer-Supplied Encryption Keys): You manage keys entirely outside the cloud provider

In Transit:

• TLS 1.2+: All service-to-service communication
• mTLS: Service mesh (Istio/Anthos) for mutual authentication between microservices
• VPN/Interconnect: Encrypted connectivity between on-premises and cloud

# GCP: Create a CMEK key ring and key
gcloud kms keyrings create faos-keyring --location=global
gcloud kms keys create faos-data-key \
  --location=global \
  --keyring=faos-keyring \
  --purpose=encryption \
  --rotation-period=90d \
  --next-rotation-time=$(date -u -d "+90 days" +%Y-%m-%dT%H:%M:%SZ)

Step 5: Configure Logging and Monitoring

Comprehensive logging is non-negotiable for security operations and compliance:

Log Type	GCP Service	AWS Equivalent	Purpose
Admin Activity	Cloud Audit Logs	CloudTrail	Who changed what
Data Access	Cloud Audit Logs	CloudTrail Data	Who accessed what data
Network Flows	VPC Flow Logs	VPC Flow Logs	Network traffic analysis
Application Logs	Cloud Logging	CloudWatch Logs	App-level events
Container Logs	GKE Logging	EKS/CloudWatch	Container stdout/stderr
DNS Queries	Cloud DNS Logging	Route 53 Query Logs	DNS-based threat detection

Enable alert policies for critical events:

# GCP Monitoring alert for IAM policy changes
alertPolicy:
  displayName: "IAM Policy Modification"
  conditions:
    - displayName: "IAM policy changed"
      conditionMatchedLog:
        filter: |
          protoPayload.methodName=("SetIamPolicy" OR "UpdateIamPolicy")
          AND protoPayload.serviceName!="k8s.io"
        labelExtractors:
          principal: "EXTRACT(protoPayload.authenticationInfo.principalEmail)"
  notificationChannels:
    - projects/my-gcp-project/notificationChannels/security-team
  alertStrategy:
    autoClose: 604800s  # 7 days

Examples

Example 1: GKE Private Cluster with Workload Identity

This configuration demonstrates GCP security best practices:

# Terraform: Private GKE cluster with Workload Identity
resource "google_container_cluster" "faos_cluster" {
  name     = "my-gke-cluster"
  location = "asia-southeast1-a"
  project  = "my-gcp-project"

  # Private cluster configuration
  private_cluster_config {
    enable_private_nodes    = true
    enable_private_endpoint = false  # Allow kubectl from authorized networks
    master_ipv4_cidr_block  = "172.16.0.0/28"
  }

  # Authorized networks for API server access
  master_authorized_networks_config {
    cidr_blocks {
      cidr_block   = "10.0.0.0/8"
      display_name = "Internal VPC"
    }
  }

  # Workload Identity for keyless service account access
  workload_identity_config {
    workload_pool = "my-gcp-project.svc.id.goog"
  }

  # Binary Authorization for image verification
  binary_authorization {
    evaluation_mode = "PROJECT_SINGLETON_POLICY"
  }

  # Network policy enforcement
  network_policy {
    enabled  = true
    provider = "CALICO"
  }

  # Shielded GKE nodes
  node_config {
    shielded_instance_config {
      enable_secure_boot          = true
      enable_integrity_monitoring = true
    }

    workload_metadata_config {
      mode = "GKE_METADATA"  # Enables Workload Identity on nodes
    }

    # Use COS-containerd for security
    image_type = "COS_CONTAINERD"

    # Service account with minimal permissions
    service_account = google_service_account.gke_node_sa.email
    oauth_scopes    = ["https://www.googleapis.com/auth/cloud-platform"]
  }

  # Enable logging and monitoring
  logging_config {
    enable_components = ["SYSTEM_COMPONENTS", "WORKLOADS"]
  }
  monitoring_config {
    enable_components = ["SYSTEM_COMPONENTS"]
    managed_prometheus { enabled = true }
  }
}

# Workload Identity binding for application service account
resource "google_service_account" "app_sa" {
  account_id   = "my-app-sa"
  display_name = "FAOS API Service Account"
  project      = "my-gcp-project"
}

resource "google_service_account_iam_binding" "workload_identity" {
  service_account_id = google_service_account.app_sa.name
  role               = "roles/iam.workloadIdentityUser"
  members = [
    "serviceAccount:my-gcp-project.svc.id.goog[my-namespace/my-app-sa]"
  ]
}

# Kubernetes ServiceAccount annotation for Workload Identity
resource "kubernetes_service_account" "app_sa" {
  metadata {
    name      = "my-app-sa"
    namespace = "faos-api"
    annotations = {
      "iam.gke.io/gcp-service-account" = google_service_account.app_sa.email
    }
  }
}

Example 2: GCP IAM Policy for Least-Privilege Service Accounts

#!/bin/bash
# create-least-privilege-sa.sh
# Creates service accounts with minimum required permissions for FAOS components

PROJECT="my-gcp-project"

# API service account: needs Cloud SQL, Secret Manager, Cloud Storage
gcloud iam service-accounts create my-app-sa \
  --display-name="FAOS API Service Account" \
  --project=$PROJECT

# Grant only specific roles (never roles/editor or roles/owner)
declare -A API_ROLES=(
  ["roles/cloudsql.client"]="Connect to Cloud SQL instances"
  ["roles/secretmanager.secretAccessor"]="Read secrets"
  ["roles/storage.objectViewer"]="Read from Cloud Storage buckets"
  ["roles/logging.logWriter"]="Write application logs"
  ["roles/monitoring.metricWriter"]="Write custom metrics"
)

for role in "${!API_ROLES[@]}"; do
  echo "Granting ${role}: ${API_ROLES[$role]}"
  gcloud projects add-iam-policy-binding $PROJECT \
    --member="serviceAccount:my-app-sa@${PROJECT}.iam.gserviceaccount.com" \
    --role="$role" \
    --condition=None
done

# Worker service account: needs Pub/Sub, Cloud Tasks, limited Cloud SQL
gcloud iam service-accounts create faos-worker-sa \
  --display-name="FAOS Worker Service Account" \
  --project=$PROJECT

declare -A WORKER_ROLES=(
  ["roles/pubsub.subscriber"]="Consume messages from Pub/Sub"
  ["roles/pubsub.publisher"]="Publish messages to Pub/Sub"
  ["roles/cloudtasks.enqueuer"]="Enqueue Cloud Tasks"
  ["roles/cloudsql.client"]="Connect to Cloud SQL"
  ["roles/logging.logWriter"]="Write application logs"
)

for role in "${!WORKER_ROLES[@]}"; do
  echo "Granting ${role}: ${WORKER_ROLES[$role]}"
  gcloud projects add-iam-policy-binding $PROJECT \
    --member="serviceAccount:faos-worker-sa@${PROJECT}.iam.gserviceaccount.com" \
    --role="$role" \
    --condition=None
done

# Verify: list roles for each service account
echo "=== API SA Roles ==="
gcloud projects get-iam-policy $PROJECT \
  --flatten="bindings[].members" \
  --filter="bindings.members:my-app-sa@" \
  --format="table(bindings.role)"

echo "=== Worker SA Roles ==="
gcloud projects get-iam-policy $PROJECT \
  --flatten="bindings[].members" \
  --filter="bindings.members:faos-worker-sa@" \
  --format="table(bindings.role)"

Best Practices

Do This

• Use Workload Identity (GKE), IRSA (EKS), or Managed Identity (AKS) instead of service account keys
• Enable VPC Service Controls for all services handling sensitive data
• Implement network segmentation with private subnets and explicit firewall rules
• Use Cloud KMS with automatic key rotation for customer-managed encryption keys
• Enable all audit log types: Admin Activity, Data Access, System Events
• Apply the principle of least privilege to every service account and IAM binding
• Use Binary Authorization to enforce that only verified images run in production
• Implement Cloud Armor or AWS WAF for public-facing endpoints
• Set organization policy constraints to prevent common misconfigurations
• Use infrastructure as code (Terraform) for all security configurations to ensure reproducibility

Don't Do This

• Do not use primitive roles (Owner, Editor, Viewer) -- use predefined or custom roles
• Do not create service account keys unless absolutely necessary (prefer Workload Identity)
• Do not expose GKE API server to the public internet without authorized networks
• Do not disable audit logging to reduce costs -- it is essential for incident response
• Do not use default VPC networks -- create purpose-built VPCs with proper CIDR planning
• Do not store secrets in environment variables, ConfigMaps, or source code
• Do not grant allUsers or allAuthenticatedUsers access to cloud resources
• Do not skip VPC Flow Logs -- they are critical for network forensics
• Do not use self-signed certificates for production services
• Do not ignore Cloud Security Command Center findings

Security Checklist

Identity and Access

• No primitive roles (Owner, Editor, Viewer) assigned to service accounts
• Workload Identity is enabled for all GKE pods accessing GCP services
• Service account keys are not used (or have rotation policies if unavoidable)
• MFA is enforced for all human accounts accessing cloud consoles
• IAM conditions are used for time-based or resource-based access restrictions
• Regular access reviews are conducted (quarterly minimum)
• Organization policy constraints prevent public resource creation

Network Security

• GKE clusters are private (no public node IPs)
• VPC Service Controls perimeters protect sensitive services
• Default-deny firewall rules are in place with explicit allow rules
• Private Google Access is enabled for private subnets
• Cloud NAT provides controlled egress for private resources
• Cloud Armor / WAF protects public-facing endpoints
• DNS logging is enabled for threat detection

Data Protection

• Customer-managed encryption keys (CMEK) are configured for sensitive data stores
• KMS key rotation is enabled (90-day rotation recommended)
• TLS 1.2+ is enforced for all external and internal connections
• mTLS is enabled between microservices via service mesh
• Data Loss Prevention (DLP) scanning is enabled for sensitive data stores
• Backup encryption uses separate keys from production data

Logging and Monitoring

• Admin Activity audit logs are enabled (on by default, cannot be disabled)
• Data Access audit logs are enabled for all sensitive services
• VPC Flow Logs are enabled for all subnets
• Log sinks export logs to a separate project for tamper resistance
• Alert policies are configured for critical security events
• Security Command Center is enabled with Premium tier
• Log retention meets compliance requirements (minimum 90 days, 1 year recommended)

Related Skills

• @cis-benchmarks -- CIS Benchmark automated scanning for GKE, Docker, and GCP
• @container-security-guide -- detailed Docker and Kubernetes runtime hardening
• @nist-csf -- mapping cloud security controls to NIST Cybersecurity Framework

Additional Resources

• GCP Security Best Practices -- official Google Cloud security guidance
• GCP Architecture Framework: Security -- security pillar of the architecture framework
• AWS Well-Architected Security Pillar -- AWS security reference
• Azure Security Benchmark -- Microsoft security guidance
• GKE Hardening Guide -- GKE-specific security recommendations
• NIST SP 800-210 -- General Access Control Guidance for Cloud Systems