Infrastructure as code security¶
Infrastructure files describe security boundaries as well as deployment mechanics. Review Terraform, CloudFormation, Kubernetes manifests and Dockerfiles for public access, excessive privileges, credential exposure and unsafe defaults. This guide is educational: a verified Offensive360 product-adapter coverage claim for these formats is not established here. Confirm available checks for your installed deployment.
Restrict container privileges¶
The following Kubernetes fragments belong inside one container's securityContext. They illustrate a Linux workload that does not require privileged host access.
Unsafe for this ordinary workload: grant unnecessary privilege.
securityContext:
privileged: true
allowPrivilegeEscalation: true
Safer: remove privilege and constrain the process.
securityContext:
privileged: false
allowPrivilegeEscalation: false
runAsNonRoot: true
capabilities:
drop: ["ALL"]
seccompProfile:
type: RuntimeDefault
These settings reduce privileges available to the container. The image must support running as a non-root user, and the application may need explicit access to writable directories. Review the Kubernetes Pod Security Standards before applying a policy to the complete workload. This fragment alone does not prove compliance with the full restricted profile.
Check the rendered deployment¶
Validate the final manifest produced by Helm, Kustomize or your deployment pipeline. In a disposable namespace with the intended admission policy, confirm the application starts as non-root and completes its expected operation. Check that a workload requesting unnecessary privilege is rejected. Review init containers, sidecars and ephemeral containers too; checking only the main container leaves gaps.
For Terraform, marking a variable sensitive reduces routine display but does not by itself remove the value from state. Protect state storage, restrict access and use supported secret-handling mechanisms. HashiCorp explains this distinction in managing sensitive data.
Also inspect publicly reachable storage, broad network rules, wildcard IAM permissions, image provenance and secrets embedded in build arguments. An encrypted database still needs an appropriate access policy. Continue with hardcoded credentials, information disclosure and cleartext protocols.
Configuration review, policy enforcement and actual cloud state are separate evidence. Verify changes in the intended environment without treating an educational example as a complete deployment template.