Infrastructure as code security¶
Infrastructure as code defines who can reach a service, read data, assume identities, or execute privileged workloads. A syntactically valid plan can still create an unsafe environment. Trust boundary: a public request, compromised workload, or untrusted build must not inherit infrastructure privileges beyond its purpose.
Configuration review must consider resolved variables, modules, provider defaults, account policies, and the deployed environment. These examples are educational configuration patterns; they do not assert that every installed Offensive360 version checks every IaC format or resource.
Terraform: protect a private S3 bucket¶
For a bucket intended to contain private attachments, disabling public-access controls permits future public ACLs or policies to expose data. It does not, by itself, make the bucket public.
# Unsafe posture for the existing private attachments bucket.
resource "aws_s3_bucket_public_access_block" "attachments" {
bucket = aws_s3_bucket.attachments.id
block_public_acls = false
block_public_policy = false
ignore_public_acls = false
restrict_public_buckets = false
}
# Safer posture for that same private bucket.
resource "aws_s3_bucket_public_access_block" "attachments" {
bucket = aws_s3_bucket.attachments.id
block_public_acls = true
block_public_policy = true
ignore_public_acls = true
restrict_public_buckets = true
}
The example assumes a separately declared aws_s3_bucket.attachments resource and the HashiCorp AWS provider. Review bucket policies, access points, account-level settings, and authorized application roles together. AWS's public-access documentation explains the combined controls; the Terraform resource reference documents these arguments. Intentionally public assets require a different, explicit design.
Kubernetes: restrict container privileges¶
These fragments belong to a container in a Pod specification; they are not complete manifests.
# Unsafe for an ordinary API container.
securityContext:
privileged: true
runAsUser: 0
# Safer if the image supports this non-root identity and read-only filesystem.
securityContext:
privileged: false
allowPrivilegeEscalation: false
runAsNonRoot: true
runAsUser: 10001
readOnlyRootFilesystem: true
capabilities:
drop: ["ALL"]
seccompProfile:
type: RuntimeDefault
Provide narrowly scoped writable volumes if the application needs them. Apply corresponding checks to init and ephemeral containers. Also review host namespaces and mounts, network policies, service-account token use, RBAC, and resource limits. Enforce the intended policy at admission so a later manifest cannot silently bypass it. Kubernetes Pod Security Standards define workload restrictions; read-only root filesystems are an additional application-specific control.
Other files to review¶
- Dockerfiles: build with a trusted, maintained base, avoid embedding credentials, use a non-root runtime where feasible, and review what enters each image layer.
- CloudFormation: inspect IAM actions and resources, ingress rules, storage exposure, encryption configuration, and parameters after substitution.
- State and CI: protect Terraform state and plan files, review changes before applying, and give deployment identities only the permissions needed for that environment.
Regression test¶
Validate configuration and inspect a generated plan in an isolated test environment. Assert that the private bucket's public-access flags remain enabled and that unexpected wildcard permissions fail policy checks. For a local Kubernetes test namespace, verify the workload starts with the intended UID and required writable mounts; a deliberately privileged fixture should fail the configured admission policy. A clean static scan does not prove there is no deployment drift.
Related: hardcoded secrets, dependency and build security, and resource exhaustion.
References: CWE-732 — incorrect permission assignment for a critical resource and CWE-250 — execution with unnecessary privileges.