Use this skill when securing cloud infrastructure, configuring IAM policies, managing secrets, implementing network policies, or achieving compliance. Triggers on cloud IAM, secrets management, network security groups, VPC security, cloud compliance, SOC 2, HIPAA, zero trust, and any task requiring cloud security architecture or hardening.
Instrucciones de origen · Vista previa de solo lectura
name
cloud-security
version
0.1.0
description
Use this skill when securing cloud infrastructure, configuring IAM policies, managing secrets, implementing network policies, or achieving compliance. Triggers on cloud IAM, secrets management, network security groups, VPC security, cloud compliance, SOC 2, HIPAA, zero trust, and any task requiring cloud security architecture or hardening.
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
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.
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.
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.
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.
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.
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):
Enable automatic rotation in AWS Secrets Manager for RDS credentials. Set a
rotation window of 30 days or fewer. Use resource-based policies to restrict
which roles can call GetSecretValue.
Configure VPC security - security groups and NACLs
VPC Layout (3-tier):
Public subnet (10.0.1.0/24) - ALB only, ingress 443/80 from 0.0.0.0/0
Private subnet (10.0.2.0/24) - App servers, ingress from ALB SG only
Data subnet (10.0.3.0/24) - RDS/ElastiCache, ingress from App SG only, no NAT
Security group rules (stateful - return traffic is automatic):
SG
Inbound rule
Source
Port
alb-sg
HTTPS
0.0.0.0/0
443
app-sg
HTTP
alb-sg (SG id)
8080
db-sg
Postgres
app-sg (SG id)
5432
NACL rules (stateless - explicit rules for both directions):
Data subnet NACL: deny all inbound from internet (0.0.0.0/0), allow from
private subnet CIDR only. Deny all outbound to internet. This is the belt to
the security group's suspenders.
Security groups are the primary control. NACLs are a secondary blast-radius
limiter. Never expose port 22 (SSH) or 3389 (RDP) to 0.0.0.0/0 - use SSM
Session Manager or a bastion in a locked-down subnet.
For RDS: enable encryption at creation (cannot be added later without snapshot
restore). Use a customer-managed KMS key (CMK) for regulated workloads so you
control the key policy and can audit usage separately.
Set up audit logging - CloudTrail and Cloud Audit Logs
resource "aws_cloudtrail" "org_trail" {
name = "org-audit-trail"
s3_bucket_name = aws_s3_bucket.audit_logs.id
include_global_service_events = true
is_multi_region_trail = true
enable_log_file_validation = true # SHA-256 digest for tamper detection
is_organization_trail = true # covers all accounts in AWS Org
event_selector {
read_write_type = "All"
include_management_events = true
data_resource {
type = "AWS::S3::Object"
values = ["arn:aws:s3:::"] # all S3 data events
}
}
cloud_watch_logs_group_arn = "${aws_cloudwatch_log_group.cloudtrail.arn}:*"
cloud_watch_logs_role_arn = aws_iam_role.cloudtrail_cw.arn
}
GCP Cloud Audit Logs - enable data access logs at org level:
# Organization-level audit config (apply via gcloud or Terraform)auditConfigs:-service:allServicesauditLogConfigs:-logType:ADMIN_READ-logType:DATA_READ-logType:DATA_WRITE
Critical alerts to configure: root account login (AWS), IAM policy changes,
security group modifications, CloudTrail disabled, MFA disabled for privileged
accounts.
Implement zero trust network - service mesh with mTLS
Zero trust assumes the network is hostile. Every service-to-service call must be
authenticated and encrypted, regardless of whether it is "inside" the VPC.
Istio service mesh - enforce mTLS across the mesh:
# PeerAuthentication: require mTLS for all services in the namespaceapiVersion:security.istio.io/v1beta1kind:PeerAuthenticationmetadata:name:defaultnamespace:productionspec:mtls:mode:STRICT# reject plaintext connections---# AuthorizationPolicy: service A can only call specific methods on service BapiVersion:security.istio.io/v1beta1kind:AuthorizationPolicymetadata:name:allow-orders-to-paymentsnamespace:productionspec:selector:matchLabels:app:payments-servicerules:-from:-source:principals: ["cluster.local/ns/production/sa/orders-service"]
to:-operation:methods: ["POST"]
paths: ["/v1/charges", "/v1/refunds"]
Each service has its own SPIFFE identity (service account). The mesh enforces that
only authorized callers can reach each endpoint - even if an attacker compromises
the internal network, they cannot spoof a service identity.
Prepare for SOC 2 compliance - controls checklist
SOC 2 is organized around Trust Service Criteria (TSC). For a Type II audit you
must demonstrate controls operated continuously over a period (typically 6-12 months).
Common Technical Controls Checklist:
Access Controls (CC6)
[ ] MFA enforced for all human users with cloud console access
[ ] Privileged access (root/owner) has separate credentials, used only for break-glass
[ ] Access reviews conducted quarterly; terminated employees deprovisioned within 24h
[ ] Service accounts use roles, not long-lived keys
[ ] SSH/RDP access disabled in favor of SSM / IAP (Identity-Aware Proxy)
Change Management (CC8)
[ ] All infrastructure changes via IaC (Terraform/Pulumi), not manual console
[ ] IaC changes require peer review in PRs before apply
[ ] Deployment pipeline enforces approvals for production changes
[ ] Rollback procedures documented and tested
Monitoring and Alerting (CC7)
[ ] CloudTrail / Cloud Audit Logs enabled across all regions and accounts
[ ] Log retention >= 1 year (hot) + 7 years (cold/archived)
[ ] Alerts on: IAM changes, SG changes, root login, failed auth spikes, CloudTrail off
[ ] Incident response runbooks exist and are tested annually
Encryption (CC6.7)
[ ] All data at rest encrypted (KMS CMK for regulated data)
[ ] All data in transit uses TLS 1.2+
[ ] Key rotation policy documented and automated
[ ] No plaintext secrets in code, logs, or environment variables
Availability (A1)
[ ] Recovery Time Objective (RTO) and Recovery Point Objective (RPO) defined
[ ] Backups tested by restoring to a non-production environment quarterly
[ ] Multi-AZ or multi-region architecture for critical services
See references/compliance-frameworks.md for SOC 2, HIPAA, and PCI-DSS
controls comparison.
Anti-patterns
Anti-pattern
Why it's dangerous
What to do instead
Wildcard IAM policies (Action: "*", Resource: "*")
Any exploit or misconfiguration grants full account access
Scope policies to exact actions and specific resource ARNs
Long-lived access keys for service accounts
Keys can leak via logs, git history, or compromised machines; there is no expiry
Use IAM roles and instance profiles; rotate keys every 90 days if roles are impossible
Flat VPC with all resources in public subnets
Any misconfigured security group exposes databases and internal services to the internet
Three-tier subnet architecture; databases never in public subnets
Secrets hardcoded in environment variables baked into container images
Image layers persist forever; any image pull leaks the secret
Fetch secrets at runtime from a secrets manager; never bake into images
Single AWS account / GCP project for all environments
A prod incident can reach dev data; a dev mistake can delete prod resources
Separate accounts/projects per environment with SCPs to enforce boundaries
Disabling CloudTrail or audit logs to reduce cost
Audit gaps make incident investigation impossible; compliance evidence destroyed
Compress and archive logs to cheap storage (S3 Glacier); cost is negligible vs. risk
Gotchas
Service Control Policies silently block actions - An SCP at the AWS Organization level that denies an action overrides any IAM Allow in a member account. When a permission looks correct in IAM but still fails with "AccessDenied", check the SCP chain at the organization and OU level - they are often overlooked because they're managed by a separate team.
CloudTrail logging gap on multi-region trails - A trail configured as multi-region still won't capture events from services that are global (IAM, STS, CloudFront) unless include_global_service_events is explicitly set to true. Most IAM changes and assume-role events fall into this gap and disappear from audit logs without this flag.
KMS key deletion is irreversible after the waiting period - KMS imposes a 7-30 day waiting period before key deletion, but once the period expires, the key and all data encrypted with it that lacks a backup decryption path are permanently unrecoverable. Never schedule a key for deletion unless you have verified that no data encrypted with it needs to be decrypted in the future.
Security group rule accumulation - Security groups are additive - rules are only added, never automatically removed. Over months, groups accumulate stale rules (former services, debug ports, one-off access). A security group that looks fine has rules from two years ago that opened ports to long-deleted resources, some of which may overlap with new infrastructure in the same CIDR range.
Secrets in environment variables baked into container images - Setting ENV DB_PASSWORD=... in a Dockerfile bakes the secret into every image layer permanently. Anyone with docker history access or registry pull access can recover it. Secrets must be injected at container runtime from a secrets manager, never built into the image.
References
For deep-dive guidance on specific domains, load the relevant file from
references/:
On first activation of this skill in a conversation: check which companion skills are installed by running ls ~/.claude/skills/ ~/.agent/skills/ ~/.agents/skills/ .claude/skills/ .agent/skills/ .agents/skills/ 2>/dev/null. Compare the results against the recommended_skills field in this file's frontmatter. For any that are missing, mention them once and offer to install:
