Infrastructure configuration: from repository default to deployed impact

Trace IaC, charts, Compose and image packaging into supported deployments, including exposed services and sensitive artifacts.

Used in these playbooks#

Setup and invariant#

Choose one supported deployment path: Terraform workspace, Helm chart, Docker Compose stack or image build. Pin the repository commit, lockfiles, provider/chart versions, image digest and documented values. Use an isolated environment with synthetic credentials and no workstation cloud credentials. A supported configuration must preserve its documented trust boundaries and keep deployment secrets away from unintended readers. A linter warning is a hypothesis until the affected deployment and boundary are established.

Procedure#

1. Reconstruct the real defaults. Read quick-start instructions, production overrides, environment-variable precedence and optional features. Record which configuration a normal user actually follows. Compare the default deployment with the maintainer-recommended secure profile. A development-only example is not automatically a production vulnerability.

2. Render trusted configuration. Render supplied charts or Compose files with synthetic values, then inspect resulting listeners, host publications, identities, volumes and access policies. Keep rendered files private: interpolation can materialize credentials. Rendering is useful evidence of intended resources, but it does not prove deployment reachability. Helm template, Compose configuration

3. Trace secret lifetime. Follow a synthetic marker from input variable through plan, state, output, image layer, artifact archive and logs. Ask which principal can read each artifact. Terraform's sensitive designation mainly controls display; state or JSON output can still contain values. Prefer a known fixture plan over reading live state. Do not run unreviewed initialization, provider binaries or provisioning hooks on a credentialed workstation. Terraform sensitive data, Terraform show

4. Inspect packaging separately from runtime. For an owned image containing synthetic inputs, review build history and layers against the build recipe. A secret removed from a later filesystem layer may still exist in earlier content. Check whether build arguments or environment variables carry credentials where a build-secret mechanism is appropriate. Record the exact image digest and artifact accessibility; a random string match does not establish a live credential. Docker build secrets

5. Confirm one deployed consequence. In the disposable deployment, test one known canary from the intended allowed location and an owner-controlled disallowed location. For exposed databases, reuse network-service boundaries. For broad roles or storage policies, reuse cloud IAM and storage delivery. Change only the relevant setting, redeploy the lab fixture and repeat the pair.

Command card#

Use a reviewed, already initialized Terraform fixture and trusted chart. These examples write only local evidence; commands are not instructions to initialize an arbitrary repository.

umask 077

helm template bounty ./trusted-chart \
  --values ./fixture-values.yaml > ./fixture-rendered.yaml

terraform -chdir=./lab-iac show -json ./fixture.tfplan \
  > ./fixture-plan.json

docker image history OWNED_SYNTHETIC_IMAGE \
  --no-trunc --format '{{.CreatedBy}}' \
  > ./fixture-history.txt

rg --files-with-matches --fixed-strings \
  'BB_SYNTHETIC_SECRET_2026' \
  ./fixture-plan.json ./fixture-history.txt ./fixture-rendered.yaml

A returned filename proves only that the chosen marker is present in that file. The security result also needs unintended artifact access and the intended confidentiality rule. Restrict provider execution to the disposable lab even for inspection commands that may need installed plugins. Image history reference

Interpretation, cleanup and checklist#

The report should connect supported input → rendered setting → deployed resource → unintended reader or actor → canary result. Include the secure comparison and minimum affected configuration. Avoid claiming that every deployment is exposed when a particular override is required. Public ports without usable privilege, fake example secrets, intentional debug builds and unreachable rules are common false positives.

• Supported mode and exact dependency versions pinned.
• Default values separated from operator overrides.
• Synthetic data used throughout artifacts.
• Actual artifact reader or service boundary identified.
• Remediated comparison reproduces the expected denial.
• Only fixture resource IDs destroyed; volumes, plans, logs and disposable credentials cleaned up.

Vulnerability reverse references#

• Container exposes unintended host files or privileges — A supported container configuration gives an untrusted workload access to host resources outside the documented isolation boundary.
• Sensitive values exposed through state or plan artifacts — A deployment artifact readable by an unintended principal contains credentials or equivalent confidential material.
• Secrets retained in container build artifacts — A build places confidential inputs in image history, layers or artifacts available outside their intended audience.
• Supported deployment default exposes a protected service — A supported installation path creates permissive service exposure or permissions that contradict the product's stated deployment boundary.

Nearby shared procedures#

Object, function, and property authorization · Authentication, recovery, federation, and session lifecycle · Trace input into queries, commands, and templates · Server-side fetching and network trust boundaries · Browser execution, cross-origin reads, and forged actions · Uploads, downloads, paths, archives, and XML · Workflow invariants, replay, idempotency, and races · REST, GraphQL, gRPC, WebSocket, and SSE permission parity