9. Infrastructure as Code, Containers and Kubernetes Security

Introduction and Context

Modern DevOps systems increasingly represent infrastructure, application packaging, deployment configuration, and operational policy as code. Terraform-style Infrastructure as Code (IaC) defines networks, identities, storage, compute resources, and managed services in version-controlled files. Container images package applications and their dependencies into portable artifacts. Kubernetes then orchestrates those containers across clusters. These capabilities improve repeatability and delivery speed, but they also enlarge the security boundary. A vulnerable base image, an overprivileged Terraform resource, an exposed registry, or a permissive Kubernetes admission policy can create a path from source code to production compromise.

Security must therefore be integrated across the entire infrastructure supply chain. Scanning alone is insufficient. A secure implementation combines preventive controls, such as policy validation and admission rules, with detective controls, such as image scanning and audit analysis, and corrective controls, such as credential rotation, workload isolation, and automated remediation. The objective is not simply to make deployment fail more often; it is to establish a risk-informed process that permits rapid delivery while maintaining confidentiality, integrity, availability, and regulatory accountability.

This chapter examines security for Terraform-style IaC, container images and registries, container execution, and Kubernetes clusters. It connects technical controls with governance, operational decision-making, and CIS-aligned hardening practices.

Learning Objectives

After completing this chapter, a learner should be able to:

1. Explain the security risks associated with IaC, containers, registries, and Kubernetes.

2. Apply secure design and review principles to Terraform-style configurations.

3. Describe image provenance, vulnerability scanning, signing, and registry protection.

4. Assess container runtime configuration, privileges, secrets, and filesystem exposure.

5. Design Kubernetes security using RBAC, admission control, network policies, and runtime monitoring.

6. Relate practical controls to CIS-aligned cluster and host-hardening objectives.

7. Evaluate trade-offs among security, availability, usability, and delivery speed.

8. Recommend an integrated DevSecOps control strategy for a realistic organization.

The Infrastructure Supply Chain as a Security System

An infrastructure supply chain is the sequence through which a desired system is specified, built, approved, provisioned, deployed, and operated. A typical path is:

IaC source → validation and policy checks → cloud resources and cluster → image build → registry → Kubernetes admission → runtime operation → monitoring and response.

Each stage has a distinct trust question. IaC review asks whether the requested resources and permissions are appropriate. Build security asks whether the image contains known vulnerabilities or malicious alterations. Registry security asks whether artifacts are authentic, protected, and traceable. Admission control asks whether a workload is permitted to enter the cluster. Runtime security asks whether actual behavior matches the approved design.

This layered view is important because security defects can be transformed as they move through the pipeline. A hard-coded cloud key in Terraform may become an active identity. A vulnerable library in an image may become exploitable service code. A Kubernetes service account with excessive permissions may turn a compromised pod into a cluster-level threat. Controls must therefore preserve evidence and context across stages, including commit identity, review history, build provenance, artifact digest, deployment identity, and runtime events.

Securing Terraform-Style Infrastructure as Code

IaC improves consistency and enables peer review, but code is not automatically secure merely because it is version controlled. The security of IaC depends on the provider resources selected, their configuration, the state-management process, variables, modules, execution identity, and approval workflow.

Secure design and review

A secure Terraform-style configuration follows least privilege and explicitness. Network security groups should permit only required traffic; public IP addresses should be exceptional rather than default; storage should use encryption and restricted access; administrative interfaces should not be exposed directly to the internet; and identity policies should avoid wildcard actions and resources where narrower permissions are possible.

Reusable modules can reduce inconsistency, but a poorly designed module can multiply an insecure default across many environments. Modules should have documented inputs, secure defaults, version constraints, tests, ownership, and change review. Production modules should not silently create public resources, broad firewall rules, or long-lived credentials.

State, secrets, and execution identity

Terraform state may contain resource identifiers, network details, passwords, tokens, or other sensitive values. State should therefore be stored in a secured remote backend with encryption in transit and at rest, access control, versioning, locking, and audit logging. State files should never be committed to a public or broadly accessible repository. Encryption does not replace authorization: an encrypted state store still requires carefully limited access.

Secrets should not be placed in source files, variable defaults, plan output, or state where avoidable. Secret-management systems, short-lived credentials, workload identities, and external data references are preferable. If a secret must pass through IaC, its exposure should be understood, minimized, and monitored. Sensitive flags can reduce accidental display, but they do not necessarily prevent storage.

The identity executing IaC is another high-value control point. Continuous integration jobs should use federated or short-lived credentials, narrowly scoped roles, environment separation, and explicit approval for production changes. A compromised pipeline identity with account-wide administrative access can bypass many application-level controls.

IaC security workflow

A mature workflow normally includes formatting and syntax validation, provider and module verification, static security analysis, secret detection, policy-as-code evaluation, plan review, controlled application, and post-deployment assessment. Static tools can identify public storage, unrestricted security groups, missing encryption, excessive IAM permissions, and insecure Kubernetes resources. They cannot fully determine business intent, so human review remains necessary.

Policy-as-code expresses organizational rules in a machine-evaluable form. Examples include “production databases must use encryption,” “no security group may allow unrestricted administrative ports,” and “all workloads must specify a non-root security context.” Policies should distinguish blocking violations from warnings and should provide an exception process with an owner, justification, expiration date, and compensating control.

Drift detection compares declared configuration with deployed reality. Drift may arise from emergency console changes, provider behavior, failed automation, or unauthorized modification. Reconciliation should not blindly overwrite every difference; destructive changes require impact assessment and, in sensitive environments, explicit approval.

Container Images and Registries

A container image is an immutable-looking artifact composed of layers, metadata, application code, libraries, and an entrypoint. In practice, images can be rebuilt, retagged, or replaced, so security depends on digest identity, provenance, and registry controls rather than tags alone.

Building trustworthy images

Secure image construction begins with a maintained and minimal base image. Fewer packages reduce attack surface and simplify vulnerability management, although minimality must not remove essential monitoring or certificate functionality. Multi-stage builds keep compilers, test tools, and source files out of the production image. Build instructions should avoid embedding credentials, and logs should be reviewed for accidental secret disclosure.

Images should run a single logical service where practical, use a clear entrypoint, define health behavior, and set an appropriate user. Dependency versions should be reproducible and regularly updated. Software bills of materials (SBOMs) identify components and versions, enabling organizations to assess newly disclosed vulnerabilities. An SBOM is an inventory, not proof that an image is safe; it must be combined with vulnerability analysis and provenance verification.

Vulnerability and malware scanning

Image scanning commonly identifies operating-system packages, language dependencies, configuration weaknesses, and sometimes malicious indicators. Findings should be prioritized using severity, exploitability, exposure, compensating controls, and whether the affected component is reachable. A critical library vulnerability in an internet-facing service deserves different treatment from an unexploitable package in an isolated build image.

Scanning should occur at build time, on registry push, before deployment, and periodically after deployment. A scan is time-dependent: an image judged acceptable yesterday may become vulnerable after a new disclosure. Exceptions need documented rationale and expiry. Teams should avoid treating every scanner result as equally urgent, because indiscriminate blocking creates alert fatigue and encourages bypass behavior.

Provenance, signing, and registry governance

Image tags such as `latest` are mutable labels and should not be the sole deployment reference. Production deployments should use immutable digests or a controlled promotion mechanism. Image signing associates an artifact with an identity and build context; verification at deployment can prevent unapproved images from entering a cluster. Provenance attestations can record source revision, builder, dependencies, and process parameters.

Registries should require strong authentication, role-based access, encrypted connections, audit logs, retention policies, and separation between build, promotion, and deployment permissions. Pull access should be limited where possible. Unused images and stale credentials should be removed. A registry compromise is particularly serious because it can distribute malicious software to many environments.

Container Runtime Security

Container isolation is based on operating-system mechanisms, not on the assumption that a container is a virtual machine. Kernel vulnerabilities, excessive capabilities, host-mounted paths, insecure sockets, and privileged execution can weaken isolation.

A secure workload should normally run as a non-root user, use a read-only root filesystem when feasible, drop unnecessary Linux capabilities, prohibit privilege escalation, and avoid host networking and host process or filesystem namespaces unless justified. The container should receive only the CPU, memory, and device access it requires. Resource limits also reduce denial-of-service risk caused by runaway processes.

The container runtime and host kernel must be patched and configured securely. Access to the container engine socket must be tightly controlled because it may provide effective host-level control. Logs, process activity, file changes, network connections, and unusual system calls can support runtime detection. Runtime policies should be designed with application behavior in mind; an overly restrictive policy can cause outages, while an overly permissive one offers little protection.

Secrets should be delivered through managed mechanisms and mounted only where needed. Environment variables may be exposed through process inspection, debugging, crash reports, or accidental logging. Rotation, access logging, and workload-specific identity are more reliable than placing static credentials in an image.

Kubernetes Security Architecture

Kubernetes security is distributed among the control plane, worker nodes, API server, admission process, network layer, workload specification, and operational practices. A weakness in one layer can undermine another. For example, strong image scanning does not compensate for an exposed API server, and restrictive RBAC does not prevent an application from exploiting a vulnerable kernel.

Control plane and node protection

The Kubernetes API server is the primary control interface and should be protected by strong authentication, authorization, encrypted communication, network restriction, and audit logging. Anonymous access and unnecessary unauthenticated endpoints should be disabled. The etcd data store contains cluster state and often secrets; it requires encryption, restricted network access, strong credentials, backups, and careful key management.

Worker nodes should use supported operating systems, timely security patches, hardened configurations, restricted administrative access, and protected kubelet endpoints. Cloud-provider metadata services must be appropriately restricted so that a compromised pod cannot obtain node or instance credentials. The cluster should separate administrative, system, and application responsibilities where the threat model requires it.

Namespaces, RBAC, and service accounts

Namespaces provide organizational and policy boundaries, not complete security isolation. Role-Based Access Control (RBAC) assigns permissions to users, groups, and service accounts. Permissions should be granted to specific resources and verbs rather than through broad cluster-admin access. Applications should use dedicated service accounts, and token automounting should be disabled when a workload does not need API access.

RBAC review should consider privilege escalation paths, including permission to create pods, modify role bindings, read secrets, use privileged workloads, or impersonate identities. A user who cannot directly read secrets may still obtain them indirectly if allowed to create a pod that mounts those secrets.

Admission control and policy enforcement

Admission controls inspect API requests before objects are persisted or accepted for execution. They can require approved registries, signed images, non-root execution, resource limits, restricted capabilities, labels, network policies, and permitted host access. Policy engines can operate in audit mode initially, allowing organizations to measure impact before enforcement.

A practical admission policy should be risk-based. Blocking a production deployment because it lacks a label may be appropriate, but emergency response procedures may require a controlled break-glass path. Exceptions should be logged, time-limited, reviewed, and automatically revoked where possible. Admission policies must also be protected against tampering and tested during Kubernetes upgrades.

Network segmentation

By default, Kubernetes networking can permit broad pod-to-pod communication. NetworkPolicy objects can implement segmentation by namespace, pod labels, ingress sources, and egress destinations. A sound design begins with deny-by-default where operationally feasible, then permits explicitly required flows. Policies should address both ingress and egress; unrestricted egress can enable data exfiltration and command-and-control communication.

Network policies are only effective if the cluster network plugin enforces them. They should be tested as part of deployment validation. Service meshes may provide identity-aware traffic control, encryption, and observability, but they add operational complexity and do not replace host, image, or API security.

Secrets and workload security

Kubernetes Secrets are objects, not automatically secure vaults. Access should be restricted through RBAC, encryption at rest should be enabled, and external secret managers may be used for stronger lifecycle control. Secret values should not appear in manifests, source repositories, or logs.

Pod security standards and security contexts should require non-root execution, disallow privileged containers, restrict host namespaces and host paths, drop capabilities, and prohibit privilege escalation unless a documented exception exists. Resource requests and limits improve scheduling and reduce resource exhaustion. Readiness and liveness probes must be designed carefully; poorly configured probes can create cascading restarts during partial failures.

CIS-Aligned Hardening and Assessment

CIS Benchmarks provide prescriptive configuration recommendations for systems and platforms. A CIS-aligned Kubernetes assessment typically examines API-server configuration, etcd protection, controller and scheduler settings, authentication and authorization, audit logging, kubelet security, network configuration, and workload controls. The benchmark is a useful baseline, but it is not a complete threat model or a substitute for organizational risk analysis.

Assessment should combine automated checks, configuration review, interviews, evidence collection, and remediation tracking. Findings should be classified by impact and exploitability rather than treated as a simple percentage score. A control may be intentionally different from the benchmark because of a documented architectural requirement; such variance should include risk acceptance, compensating controls, and review dates.

An Illustrative Applied Case: Securing a Financial Services Delivery Platform

Background

A fictional financial services company, Northstar Payments, operates customer-facing APIs in a managed Kubernetes environment. Infrastructure is provisioned with Terraform-style modules, images are built by a continuous integration platform, and deployments are promoted through separate development, staging, and production namespaces.

Situation and problem

An internal review finds that production images use mutable tags, several Terraform modules create public load-balancer rules by default, developers share a service account with broad permissions, and the cluster permits unrestricted egress. Vulnerability scanning occurs only after deployment, and the registry has long-lived developer credentials. No formal exception process exists.

Analysis

The risks are systemic rather than isolated. Mutable tags weaken traceability and allow an image to change without a manifest change. Public network defaults increase exposure. Shared permissions make attribution difficult and allow compromise of one workload to affect others. Unrestricted egress increases the impact of a stolen credential or compromised pod. Post-deployment scanning delays detection and allows vulnerable artifacts to operate.

Approach and solution

Northstar first maps identities, artifacts, infrastructure resources, and deployment approvals. It replaces developer registry passwords with short-lived federated identities and separates build, promotion, and deployment roles. Images are rebuilt using maintained base images and multi-stage Dockerfiles, scanned during build and before promotion, assigned SBOMs, signed, and deployed by digest.

Terraform modules are revised so that private networking, encryption, and restricted access are secure defaults. Static analysis and policy-as-code block public administrative ports, unencrypted storage, and wildcard administrative permissions. State is moved to a locked, encrypted backend with audit logging.

In Kubernetes, each application receives a dedicated service account. Admission policy requires approved signed images, non-root execution, resource limits, and restricted capabilities. Namespaces use default-deny network policies with explicitly documented service flows. Audit logs are centralized, and a CIS-aligned review identifies remaining control-plane and kubelet gaps. Emergency exceptions require an owner, reason, expiry, and post-event review.

Outcome

The organization gains stronger artifact traceability, clearer accountability, reduced lateral movement, and earlier detection of insecure changes. Some teams initially report slower deployment because policies expose previously hidden assumptions. Northstar addresses this by providing secure templates, local policy testing, and staged enforcement rather than weakening the controls.

Learning points

The case demonstrates that security is most effective when implemented as a connected chain. Image scanning without provenance is incomplete; RBAC without workload restrictions leaves escalation paths; and benchmark compliance without ownership does not produce durable security. Developer experience, exception governance, and measurable remediation are essential to sustaining technical controls.

Challenges, Limitations, and Common Mistakes

Security tooling can produce false positives, miss context, or fail to detect novel attacks. IaC scanners may not understand runtime relationships, while image scanners may report vulnerable packages that are not reachable. Kubernetes policies can be fragmented across admission, RBAC, network, and runtime systems, creating inconsistent results.

Common mistakes include storing state in source control, using mutable image tags, granting cluster-admin for convenience, assuming namespaces are hard isolation boundaries, exposing the Docker or container runtime socket, permitting unrestricted egress, placing secrets in manifests, and treating a CIS score as the complete security posture. Another mistake is enforcing policies without migration support, causing teams to bypass controls or request permanent exceptions.

Security controls also have availability costs. Deny-by-default networking can interrupt undocumented dependencies; aggressive image updates can introduce incompatibilities; and restrictive runtime profiles may conflict with legacy software. These risks should be managed through testing, progressive rollout, rollback plans, and explicit risk ownership.

Governance, Ethics, and Professional Responsibility

Infrastructure decisions can affect customer privacy, financial integrity, service continuity, and employee accountability. Organizations should define ownership for images, modules, clusters, policies, exceptions, and vulnerabilities. Audit data must be protected because it may reveal identities, customer interactions, or system architecture.

Security professionals should not conceal exceptions, manipulate compliance evidence, or deploy intrusive monitoring without legitimate purpose and appropriate safeguards. Regulatory requirements may mandate encryption, access logging, retention, separation of duties, incident reporting, or evidence of change control. These requirements should be translated into automated controls where possible, while recognizing that automation does not eliminate professional judgment.

Automation, Analytics, and Emerging Developments

Policy-as-code, automated SBOM generation, signed provenance, continuous configuration assessment, and runtime detection increasingly connect development and operations evidence. Analytics can correlate a code change, image digest, Kubernetes deployment, identity event, and network anomaly to support faster investigation. Machine learning may assist prioritization, but it should not replace validated security rules or human review, particularly when false negatives could affect critical services.

Emerging practice emphasizes software supply-chain frameworks, stronger workload identity, confidential computing, automated certificate rotation, and identity-aware network controls. Ephemeral environments can reduce persistent exposure, while platform engineering teams increasingly provide secure “golden paths” that package approved Terraform modules, image bases, admission policies, and observability defaults. The central trend is moving from optional security guidance toward verifiable, continuously enforced platform capabilities.

Best-Practice Decision Framework

A practical implementation can be evaluated through five questions:

1. Can the organization identify what is being deployed? Use version control, SBOMs, digests, provenance, and ownership records.

2. Can it prove that the artifact and configuration were approved? Use signed artifacts, protected branches, policy checks, and auditable promotion.

3. Is the workload limited to what it requires? Apply least-privilege identities, restricted capabilities, resource limits, and network segmentation.

4. Can compromise be detected and contained? Use audit logs, runtime monitoring, egress controls, backups, and incident playbooks.

5. Can the control be maintained? Provide secure defaults, upgrade processes, exception expiry, testing, and measurable remediation.

This framework supports both technical and managerial decisions. The correct control is not necessarily the most restrictive one; it is the control that reduces material risk while remaining enforceable, observable, and compatible with the service’s operational requirements.

Chapter Summary

IaC, containers, registries, and Kubernetes form a connected infrastructure supply chain whose security must be managed end to end. Terraform-style configurations require secure modules, protected state, least-privilege execution identities, policy checks, drift management, and secret discipline. Container security depends on maintained minimal images, reproducible builds, vulnerability assessment, SBOMs, provenance, signing, registry governance, and immutable deployment references. Runtime security requires non-root execution, restricted capabilities, resource controls, protected hosts, and managed secrets.

Kubernetes security combines control-plane protection, RBAC, service-account governance, admission control, pod security, network segmentation, secret protection, audit logging, and node hardening. CIS Benchmarks provide valuable baselines but must be interpreted through organizational risk and documented exceptions. Effective DevSecOps integrates preventive, detective, and corrective controls, supported by automation, governance, progressive enforcement, and professional accountability.

Key Terms

Infrastructure as Code (IaC): Management of infrastructure through machine-readable, version-controlled definitions.

Terraform state: Data recording the relationship between declared IaC resources and deployed infrastructure.

Policy as code: Machine-evaluable rules that enforce organizational or security requirements.

Drift: A difference between declared infrastructure configuration and its deployed state.

Container image: A packaged filesystem and metadata used to create a container.

Image digest: A content-derived identifier that uniquely references an image artifact.

Software bill of materials (SBOM): An inventory of software components and dependencies in an artifact.

Image provenance: Evidence describing an artifact’s source, builder, process, and inputs.

Image signing: Cryptographic association of an artifact with a trusted identity.

Registry: A service that stores and distributes container images.

Least privilege: Granting only the permissions required for an identity or workload.

Kubernetes RBAC: Authorization controls that assign permissions to users, groups, and service accounts.

Admission control: A Kubernetes mechanism that validates or mutates API requests before acceptance.

NetworkPolicy: A Kubernetes object that controls permitted network traffic to or from workloads.

Service account: A Kubernetes identity used by a workload to access cluster resources.

Capability: A granular operating-system privilege that can be granted or removed from a process.

CIS Benchmark: A prescriptive security-hardening recommendation set for a technology platform.

Runtime security: Protection and monitoring of workloads while they are executing.

Immutable deployment: Deployment by a stable artifact identity, commonly a digest, rather than a mutable tag.

Break-glass access: Exceptional, controlled emergency access used when normal procedures are insufficient.

Review Questions

Short Answer Questions

1. Why is Terraform state considered sensitive, and what controls should protect it?

2. Distinguish an image tag from an image digest.

3. What is the purpose of Kubernetes admission control?

4. Why should container capabilities be minimized?

5. What does a default-deny network policy achieve?

Long Answer Questions

1. Explain a secure Terraform-style IaC workflow from code commit through post-deployment drift detection.

2. Discuss how image construction, vulnerability scanning, SBOMs, signing, and registry governance combine to protect the container supply chain.

3. Describe a layered Kubernetes security architecture covering the control plane, nodes, RBAC, workloads, secrets, and networks.

4. Explain the value and limitations of using CIS Benchmarks for Kubernetes hardening.

5. Design a governance process for security exceptions in a DevSecOps platform.

Analytical / Application Questions

1. A production deployment uses a signed image but grants its pod host networking, a writable root filesystem, and a service account with permission to create cluster roles. Identify the principal risks and propose a prioritized remediation plan.

2. An IaC scan reports an unrestricted administrative port, while the application owner claims it is required for temporary support access. How should the security and platform teams evaluate, control, and document this exception?

3. A compromised pod is suspected of communicating with an external command-and-control server. Explain which Kubernetes, network, registry, identity, and runtime evidence should be collected and how containment could proceed without destroying forensic value.

22. Multiple Choice Questions with Answers

Question 1

Which control most directly prevents a production deployment from silently changing when a mutable image tag is reused?

A. Deploying the image by content digest

B. Increasing pod CPU limits

C. Adding a Kubernetes namespace label

D. Disabling container health probes

Correct Answer: A. Deploying the image by content digest

Question 2

A Terraform state file contains a database password. Which response is most appropriate?

A. Commit the state file to the application repository for transparency

B. Store it in a protected encrypted backend and reduce secret exposure through managed secret services

C. Rename the password variable so scanners cannot find it

D. Print the state during every deployment for auditability

Correct Answer: B. Store it in a protected encrypted backend and reduce secret exposure through managed secret services

Question 3

Which Kubernetes permission creates a significant indirect privilege-escalation risk?

A. Permission to view pod labels

B. Permission to create pods that can mount sensitive secrets

C. Permission to read a public service endpoint

D. Permission to list namespaces without secrets access

Correct Answer: B. Permission to create pods that can mount sensitive secrets

Question 4

What is the main security value of an SBOM?

A. It guarantees that the image contains no vulnerabilities

B. It identifies components so vulnerabilities and licensing exposure can be assessed

C. It encrypts the image layers

D. It replaces the need for image provenance

Correct Answer: B. It identifies components so vulnerabilities and licensing exposure can be assessed

Question 5

Which configuration best reflects a restricted container runtime posture?

A. Root user, privileged mode, and host filesystem access

B. Non-root user, dropped capabilities, read-only filesystem where feasible, and no privilege escalation

C. Host networking and unrestricted device access

D. Shared administrative service account and writable host mounts

Correct Answer: B. Non-root user, dropped capabilities, read-only filesystem where feasible, and no privilege escalation

Question 6

What is the primary purpose of a Kubernetes admission policy requiring signed images from approved registries?

A. To increase application CPU performance

B. To prevent unapproved or unverifiable artifacts from being accepted

C. To replace network segmentation

D. To automatically patch the worker operating system

Correct Answer: B. To prevent unapproved or unverifiable artifacts from being accepted

Question 7

Why is unrestricted egress from a Kubernetes cluster a security concern?

A. It prevents all internal service discovery

B. It can enable data exfiltration or command-and-control communication after compromise

C. It guarantees that images cannot be pulled

D. It disables RBAC enforcement

Correct Answer: B. It can enable data exfiltration or command-and-control communication after compromise

Question 8

Which statement best characterizes CIS Benchmarks?

A. They are useful hardening baselines but do not replace threat modeling and risk assessment

B. They guarantee that an organization is compliant with every regulation

C. They apply only to application source code

D. They eliminate the need for audit logging

Correct Answer: A. They are useful hardening baselines but do not replace threat modeling and risk assessment

Question 9

A secure IaC pipeline should treat a production change differently from a development change primarily because production changes:

A. Never require automated testing

B. Have greater potential impact and normally require stronger approval and identity controls

C. Cannot use version control

D. Must always be performed manually

Correct Answer: B. Have greater potential impact and normally require stronger approval and identity controls

Question 10

Which response best represents a mature approach to a legitimate security exception?

A. Allow it indefinitely without documentation

B. Block every exception regardless of service impact

C. Record its owner, justification, compensating controls, expiry, and review requirements

D. Hide it from audit logs to reduce operational friction

Correct Answer: C. Record its owner, justification, compensating controls, expiry, and review requirements