IaC Misconfig Review

Infrastructure-as-code and container config fails safe review the same way a broad IAM policy does: it works. The pod schedules, the bucket serves, the instance boots — so the review waves it through. But "it works" only proves the config is permissive enough, never that it is locked down. The dangerous settings here are almost always insecure defaults: things that are wrong because a hardening field is absent, not because someone typed a bad value. A Pod with no securityContext runs as root with privilege-escalation allowed. An S3 bucket with no public-access block relies on ACLs to stay private. An instance with no http_tokens setting answers the metadata service over IMDSv1. None of these look wrong — they look empty. This skill reviews the config against a fixed catalog and, for each hit, names the misconfiguration, why it is exploitable, and the concrete field that fixes it.

When to activate

Activate when the request hands you an existing IaC or container config to review or security-check before it ships — a Terraform file/module, a Kubernetes manifest (Pod/Deployment/DaemonSet/StatefulSet), a Dockerfile, or a docker-compose file — and asks whether it is safe or what to fix.

Do not activate for: writing a new Dockerfile or manifest from scratch (that is an authoring task with its own conventions); reviewing whether an IAM/RBAC policy grants broader permissions than a workload needs (that is a least-privilege grant review, a different axis than misconfiguration); or debugging a container that is already running and misbehaving in production.

How to review

Go through the catalog surface by surface. For each resource in the config, check every applicable item — and treat an absent hardening field as a finding, not a pass, whenever the default is insecure. Report each finding as: what the misconfiguration is, why it is exploitable in one clause, and the exact field/value that fixes it. Do not invent findings on config that is already hardened, and do not flag a public listener that is meant to be public (an HTTPS/443 or HTTP/80 ingress on a load balancer is intended exposure, not a misconfiguration) — reserve world-open findings for administrative and datastore ports.

Full table: see references/misconfig-catalog.md — the body below covers the method and the high-frequency defaults; that file is the deep per-provider corpus (AWS/Azure/GCP/K8s insecure-defaults mapped to the exact fixing field, CIS/checkov/trivy style). Consult it only when the config touches a resource the three inline catalogs do not name.

Catalog A — Containers & Kubernetes

• Runs as root (default). No runAsNonRoot: true and no non-root runAsUser, or a

Dockerfile with no USER line, means the process runs as UID 0. A container breakout then lands as root on the node. Fix: set runAsNonRoot: true / a high runAsUser, and add a USER line in the image.

• Privileged. privileged: true disables almost all isolation — the container gets the

host's devices and capabilities and is effectively root on the node. Fix: remove it; grant only the specific capabilities actually needed.

• Privilege escalation allowed (default). allowPrivilegeEscalation is true unless set

false, letting a process gain more privileges than its parent (e.g. via setuid binaries). Fix: set allowPrivilegeEscalation: false.

• Host namespaces. hostNetwork, hostPID, or hostIPC: true drop the isolation

boundary — the container shares the node's network stack, process table, or IPC, enabling it to see other workloads' traffic or processes. Fix: remove unless the workload is a node agent that genuinely needs it.

• Host path mounts. A hostPath volume mounts a node directory into the container;

mounting /, /var/run/docker.sock, or /etc hands over the node. Fix: use a configMap/secret/emptyDir or a named volume instead.

• Writable root filesystem (default). Without readOnlyRootFilesystem: true an attacker

can drop tools or tamper with the image at runtime. Fix: set it true and mount an emptyDir for the few paths that need writes.

• Capabilities not dropped. Keeping the default capability set (or adding SYS_ADMIN,

NET_ADMIN, NET_RAW) is more power than most apps use. Fix: drop: ["ALL"], then add back only what is required.

• Unpinned image. An image tagged :latest (or untagged) is mutable — the running code

is not the reviewed code, and a poisoned upstream tag ships silently. Fix: pin to a version tag or, better, a digest.

• Secrets in the manifest. A password, token, or key as a literal env value: (or in a

ConfigMap) is stored in plaintext and visible to anyone who can read the object. Fix: reference a Secret via secretKeyRef, or an external secret store.

Catalog B — Terraform & cloud resources

• World-open admin/datastore ports. A security-group ingress with

cidr_blocks = ["0.0.0.0/0"] (or ::/0) on SSH (22), RDP (3389), a database port (5432/3306/6379/27017), or all ports exposes it to the entire internet. Fix: scope the CIDR to the office/VPN/VPC range, or front it with a bastion. (An HTTPS/HTTP listener open to the world is fine — do not flag it.)

• Public object storage. An acl = "public-read"/"public-read-write", or a bucket

policy with Principal: "*", or a missing aws_s3_bucket_public_access_block (with all four block flags true) leaves the bucket reachable by anyone. Fix: set the ACL private and attach a public-access block that blocks public ACLs and policies.

• Publicly reachable datastore/instance. publicly_accessible = true on an RDS instance

or database, or an instance placed in a public subnet with a public IP when it need not be, puts the datastore directly on the internet. Fix: set it false and reach it from within the VPC.

• Unencrypted at rest (default). storage_encrypted = false (or absent) on RDS,

encrypted = false on an EBS volume, or an S3 bucket with no server-side encryption leaves data unprotected if the media or a snapshot leaks. Fix: enable encryption and, where it matters, use a customer-managed key.

• Hardcoded secrets. A literal password, secret_key, access_key, or private key

string in a .tf file lands in version control and in the state file. Fix: source it from a variable, a secrets manager, or an environment reference — never a literal.

• IMDSv1 allowed (default). Instance metadata_options with http_tokens = "optional"

(the default) lets a server-side-request-forgery bug read the instance's credentials over the unauthenticated metadata service. Fix: set http_tokens = "required" to force IMDSv2.

• Audit/versioning off where it matters. Object storage with versioning disabled, or a

missing audit trail (CloudTrail / access logging) on sensitive resources, removes the ability to recover or investigate. Flag when the resource is security-relevant; do not demand it on every bucket.

Catalog C — Dockerfile & docker-compose

• No USER — runs as root. A Dockerfile that never drops from root runs the app as UID 0

inside the container. Fix: create and switch to a non-root user before the entrypoint.

• Secrets baked into layers. A credential passed via ENV or ARG, or COPYing a

.env/key file, persists in the image history even if later removed. Fix: use build secrets/mounts and keep credentials out of the image.

• Mounting the Docker socket. A compose service that mounts /var/run/docker.sock grants

full control of the host's Docker daemon — root-equivalent. Fix: remove it or use a scoped API proxy.

• Privileged / host-mapped compose service. privileged: true, network_mode: host, or

binding a sensitive port to 0.0.0.0 in compose has the same exposure as its Kubernetes analogs above. Fix: drop privileged, keep the service on an internal network, and bind admin ports to 127.0.0.1.

Output

Return a short list of findings, most severe first (host escape / world-open admin port / public datastore before missing-encryption or versioning), each with the fixing field named. If the config is already hardened on a surface, say so plainly rather than manufacturing a finding — a clean review is a valid result.