cloud-security

When this skill is activated, always start your first response with the 🧢 emoji.

Cloud Security

A practitioner's framework for securing cloud infrastructure across AWS, GCP, and Azure. This skill covers IAM, secrets management, network security, encryption, audit logging, zero trust, and compliance - with opinionated guidance on when to use each pattern and why it matters. Designed for engineers who own the security posture of a cloud environment, not just a single service.

When to use this skill

Trigger this skill when the user:

• Designs or audits IAM roles, policies, or permission boundaries
• Manages secrets, API keys, or credentials in cloud environments
• Configures VPC security groups, NACLs, or network access controls
• Implements encryption at rest or in transit for cloud resources
• Sets up audit logging (CloudTrail, Cloud Audit Logs, Azure Monitor)
• Architects a zero trust or service mesh network
• Prepares for SOC 2, HIPAA, or PCI-DSS compliance
• Hardens a cloud account, project, or subscription configuration

Do NOT trigger this skill for:

• Application-layer security (SQL injection, XSS, auth flows) - use the

backend-engineering skill's security reference instead

• On-premises or bare-metal infrastructure that has no cloud component

Key principles

1. Least privilege IAM - Every identity (human, service, CI/CD pipeline) gets

only the minimum permissions required for its specific task. Never use root or owner-level credentials in automation. Scope permissions to a resource ARN or path, not *. Review and prune permissions quarterly.

1. Encrypt at rest and in transit - All data at rest uses provider-managed KMS

keys (or customer-managed for regulated workloads). All data in transit uses TLS 1.2+ with no exceptions. Internal service traffic is not exempt. Certificate rotation is automated.

1. Never store secrets in code - No credentials, API keys, or tokens belong in

source code, Dockerfiles, CI config, or environment variables baked into images. Secrets live in a secrets manager and are fetched at runtime. Secret scanning runs in every CI pipeline. Pre-commit hooks block high-entropy strings.

1. Defense in depth - No single control is the whole security posture. Layer

network controls (VPC, security groups, NACLs), identity controls (IAM), data controls (encryption, DLP), and detection controls (audit logs, SIEM) so a failure in one layer does not compromise the system.

1. Audit everything - Every privileged action, every IAM change, every secret

access, and every configuration drift must be logged to an immutable, centralized store. Logs have value only when there is alerting on anomalies and a process to act on them.

Core concepts

Shared responsibility model

Cloud providers secure the infrastructure of the cloud (physical hardware, hypervisor, managed service internals). You secure everything in the cloud: identity, data, network configuration, OS patching, application code, and compliance posture. Misunderstanding this boundary is the root cause of most cloud breaches.

| Layer | Provider's responsibility | Your responsibility | |---|---|---| | Physical hardware | Provider | - | | Hypervisor / virtualization | Provider | - | | Managed service internals | Provider | Configuration and access | | Network configuration (VPC, SGs) | - | You | | Identity and IAM | - | You | | Data encryption | Provider tooling | Your configuration and keys | | OS patching (VMs) | - | You | | Application code | - | You |

IAM hierarchy: identity, policy, role

• Identity - who (or what) is making the request: a human user, a service

account, a Lambda function, an EC2 instance, a CI/CD pipeline.

• Policy - the document that grants or denies specific actions on specific

resources. Policies are attached to identities or roles.

• Role - a temporary identity assumed by a service or person. Roles issue

short-lived credentials. Always prefer roles over long-lived access keys.

The evaluation order: explicit deny > service control policy (SCP/org policy) > identity-based policy > resource-based policy. A single explicit deny anywhere in the chain blocks access.

Network segmentation

Isolate workloads at multiple levels:

• Account/project level - separate AWS accounts or GCP projects per environment

(prod, staging, dev) to create a hard blast-radius boundary

• VPC level - separate VPCs per environment or workload tier
• Subnet level - public subnets for load balancers only, private subnets for

compute, isolated subnets for databases with no route to the internet

• Security group level - stateful rules on each resource; restrict to minimum

source/port required

Encryption envelope pattern

KMS uses a two-layer encryption model: a Customer Master Key (CMK) in the cloud KMS encrypts a short-lived Data Encryption Key (DEK). The DEK encrypts the actual data. Store the encrypted DEK alongside the data. The CMK never leaves KMS. To decrypt, call KMS to decrypt the DEK, use the DEK in memory, then discard it. This pattern limits the blast radius of a key compromise and enables key rotation without re-encrypting all data.

Common tasks

Design IAM with least privilege

Start from the action, not the service. Ask: "What exact API calls does this identity need to make?" Then scope to specific resources.

AWS IAM policy - tightly scoped service role:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ReadSpecificS3Bucket",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::my-app-bucket",
        "arn:aws:s3:::my-app-bucket/*"
      ]
    },
    {
      "Sid": "ReadSpecificSecret",
      "Effect": "Allow",
      "Action": "secretsmanager:GetSecretValue",
      "Resource": "arn:aws:secretsmanager:us-east-1:123456789:secret:my-app/db-*"
    }
  ]
}

GCP IAM - workload identity for a Cloud Run service:

# Bind a service account to a specific role on a specific resource
# gcloud run services add-iam-policy-binding my-service \
#   --member="serviceAccount:my-svc@project.iam.gserviceaccount.com" \
#   --role="roles/run.invoker"

# Grant minimal storage access - prefer predefined roles over basic roles
# gcloud projects add-iam-policy-binding PROJECT_ID \
#   --member="serviceAccount:my-svc@project.iam.gserviceaccount.com" \
#   --role="roles/storage.objectViewer" \
#   --condition="resource.name.startsWith('projects/_/buckets/my-app-bucket')"

Never use roles/owner, roles/editor, or AdministratorAccess for service

accounts. Use permission boundaries on AWS to cap maximum effective permissions.

Manage secrets with Vault or AWS Secrets Manager

HashiCorp Vault - dynamic database credentials (no long-lived passwords):

# Enable the database secrets engine
path "database/config/postgres" {
  capabilities = ["create", "update"]
}

# Define a role that generates short-lived credentials
resource "vault_database_secret_backend_role" "app" {
  name    = "app-role"
  backend = vault_database_secrets_engine.db.path
  db_name = vault_database_secrets_engine_connection.postgres.name
  creation_statements = [
    "CREATE ROLE \"{{name}}\" WITH LOGIN PASSWORD '{{password}}' VALID UNTIL '{{expiration}}';",
    "GRANT SELECT, INSERT ON ALL TABLES IN SCHEMA public TO \"{{name}}\";"
  ]
  default_ttl = "1h"
  max_ttl     = "24h"
}

AWS Secrets Manager - fetch at runtime (never at build time):

import boto3
import json

def get_secret(secret_name: str, region: str = "us-east-1") -> dict:
    client = boto3.client("secretsmanager", region_name=region)
    response = client.get_secret_value(SecretId=secret_name)
    return json.loads(response["SecretString"])

# Usage: fetch on startup, cache in memory, never log
db_config = get_secret("prod/