11. Security, Secrets and Policy as Code

Introduction and Context

Infrastructure as Code (IaC) changes infrastructure from a manually operated environment into a system described, reviewed, tested, and executed through machine-readable definitions. This improves consistency and repeatability, but it also changes the nature of security risk. A password placed in a Terraform variable, an overly broad cloud role, an unverified Ansible collection, or an unprotected state file can expose an entire organization even when the infrastructure itself appears correctly configured.

Security in IaC is therefore not a final inspection activity. It is a property of the complete delivery system: source repositories, developer workstations, CI/CD pipelines, state storage, cloud identities, providers, modules, collections, policies, and runtime infrastructure. The central objective is to make the secure path the normal path while preserving sufficient flexibility for legitimate engineering work.

This chapter examines least privilege, secrets management, state security, encryption, software supply-chain controls, provenance, policy as code, compliance automation, vulnerability scanning, and secure coding practices. Terraform and Ansible are used as representative technologies, but the principles apply to infrastructure automation generally.

Learning Objectives

After studying this chapter, the learner should be able to:

• distinguish infrastructure secrets, credentials, sensitive data, and configuration;
• design least-privilege identities for Terraform and Ansible automation;
• secure Terraform state and understand why marking a value as sensitive is not encryption;
• select appropriate secret-management and encryption approaches;
• evaluate providers, modules, roles, and collections for provenance and supply-chain risk;
• apply policy as code, static analysis, vulnerability scanning, and compliance automation;
• construct a secure IaC workflow that prevents accidental disclosure;
• analyse governance, ethical, regulatory, and operational implications of IaC security decisions.

Security as a Property of the IaC System

A useful security model considers four related dimensions. Confidentiality prevents unauthorized disclosure of credentials, keys, personal data, and state. Integrity ensures that infrastructure definitions, policies, providers, and execution plans have not been altered improperly. Availability protects the ability to provision, recover, and manage infrastructure. Accountability makes actions attributable through identity, approvals, logs, and version history.

These dimensions interact. Encrypting a state file protects confidentiality, but does not prevent an administrator with write access from changing it. A signed module improves integrity, but does not guarantee that the module’s author followed secure coding practices. A highly restrictive policy may improve security but damage availability if it blocks emergency recovery. Professional design therefore balances control, operational resilience, and justified business requirements.

The principle of least privilege is the foundation. An identity should have only the permissions needed for a defined task, for the shortest practical duration, and within the narrowest applicable scope. Least privilege applies to cloud roles, CI runners, state backends, repository users, secret engines, Ansible become privileges, and human break-glass access. It is not equivalent to giving an automation account administrator access because administration is convenient.

A mature implementation separates identities by function. Planning may use read-only permissions, whereas applying changes requires narrowly scoped write permissions. Development, testing, and production should not share credentials. A CI job that deploys a network should not automatically be able to read database passwords. Where supported, short-lived federated credentials are preferable to long-lived static access keys.

Secrets, Sensitive Values, and State

A secret is information whose disclosure could enable unauthorized access or cause harm. Examples include passwords, API tokens, private keys, database connection strings, signing keys, and bootstrap credentials. Sensitive business data may not be a credential but still requires protection. A value marked `sensitive` in Terraform is commonly hidden from ordinary CLI output; it is not thereby removed from the plan or encrypted in state.

Terraform state records the relationship between configuration and real infrastructure. It may contain resource attributes, generated passwords, endpoint details, and values that are not obvious in configuration files. Consequently, state must be treated as confidential and authoritative operational data. Recommended controls include:

• use a remote backend with encryption at rest and in transit;
• restrict read, write, and administrative permissions separately;
• enable versioning and carefully controlled recovery;
• use locking to reduce concurrent modification and corruption;
• audit access to the backend;
• avoid storing state in unprotected local workstations;
• limit state contents by separating environments or components when appropriate;
• prevent state files, plans, and debug logs from entering source control or build artifacts.

A plan file can also contain sensitive values. It must receive controls comparable to state. Log masking is useful but imperfect: secrets can appear through error messages, shell tracing, provider diagnostics, or encoded output. Secure pipelines should disable command tracing for secret-bearing commands, use ephemeral workspaces, and define retention periods for logs and artifacts.

Ansible introduces related risks through variables, inventory files, fact gathering, registered task output, and become credentials. `no_log: true` can suppress task output, but it should be used carefully because excessive suppression reduces auditability and troubleshooting capability. Secrets should be retrieved at execution time from a managed secret store rather than committed to inventories or variable files. Ansible Vault can protect encrypted files, but its key-management process, rotation, access control, and CI integration remain organizational responsibilities.

Secret Management and Encryption Architecture

A secret-management system should provide controlled storage, identity-based retrieval, rotation, auditing, and—where practical—dynamic credentials. Examples include cloud secret managers, enterprise vault platforms, and dedicated key-management services. The automation tool should receive only the secret required for the current operation. It should not export an entire secret database to a job.

Secret retrieval can follow a pull model, in which a trusted workload authenticates to a secret service, or a brokered model, in which a CI platform injects a temporary value. In both cases, authentication must be stronger than possession of a repository file. Workload identity federation, short-lived tokens, and environment-specific authorization reduce the impact of compromise.

Encryption has three distinct uses. Encryption in transit protects communication between clients, backends, secret stores, and target systems. Encryption at rest protects persisted data such as state, backups, and logs. Application-level or field-level encryption protects especially sensitive values even when storage systems are accessed. Key management must address generation, storage, rotation, access, separation of duties, backup, revocation, and destruction. Encryption is not a substitute for access control: an authorized process with a decryption capability can still disclose data.

A sound design also distinguishes encryption keys from data-encryption keys and records which identities may use each key. Key policies should be reviewed like source code. Emergency access must be logged and periodically examined.

Supply-Chain Security and Provenance

IaC depends on external components: Terraform providers, modules, Ansible roles, collections, container images, plugins, and action scripts. These dependencies create a software supply-chain risk. A compromised or malicious component may execute code, exfiltrate credentials, alter resources, or introduce a backdoor into every environment that consumes it.

Provenance is evidence about where an artifact came from, how it was built, and whether it is the expected artifact. Useful controls include trusted registries, provider and collection signatures where supported, checksum verification, version pinning, dependency lock files, internal mirrors, software bills of materials, and review of release ownership. Pinning a version improves reproducibility, but a pinned malicious version remains malicious; selection and provenance are both necessary.

Modules and roles should be treated as software products. They require documentation, tests, change review, security scanning, ownership, and a deprecation process. Organizations should prefer minimal dependencies and avoid copying opaque code into production pipelines. A private registry or curated collection repository can reduce uncontrolled external consumption, but it must itself be secured and maintained.

A secure pipeline separates dependency acquisition from execution. It can verify signatures and checksums before downloading, scan the selected versions, and prevent unapproved sources. Credentials should not be available while untrusted dependency-installation scripts run. This is especially important when tools or plugins can execute local code during initialization or deployment.

Policy as Code and Compliance Automation

Policy as code expresses organizational, security, or regulatory rules in machine-evaluable form. Instead of relying solely on a document stating that storage must be encrypted, a policy can reject a Terraform plan that creates an unencrypted storage resource. Policy therefore converts intent into an enforceable control.

Policies may be applied at several points:

1. Source stage: detect insecure patterns before review.

2. Plan stage: evaluate the proposed infrastructure before changes occur.

3. Admission stage: prevent unauthorized deployment.

4. Runtime stage: identify drift or non-compliance in deployed resources.

5. Evidence stage: retain decisions, exceptions, and remediation records.

A policy should identify the rule, scope, rationale, severity, decision, and exception process. Examples include requiring encryption, prohibiting public administrative ports, restricting regions, requiring approved tags, preventing unrestricted identity permissions, and requiring backup or logging controls.

Policies can be implemented through Terraform validation rules, Sentinel or Open Policy Agent-style engines, Rego policies, cloud-native controls, Ansible lint rules, and CI checks. Different mechanisms have different visibility and enforcement points. A variable validation rule may ensure a value is well formed, while a plan policy can assess relationships among multiple resources.

Effective compliance automation is risk-based. A blocking rule is appropriate for a high-impact violation, whereas a warning may be suitable for a low-risk development exception. Exceptions must be explicit, time-bound, approved by an accountable owner, and periodically reviewed. Otherwise, exceptions become an ungoverned alternative deployment path.

Secure IaC Coding and Verification Workflow

Secure coding begins with safe defaults. Modules should create private resources unless public exposure is explicitly requested. Variables should have type constraints and validation. Resource names, regions, and environment identifiers should be restricted to approved values. Dynamic construction of policy documents, shell commands, or templates should be handled cautiously to avoid injection and unintended privilege.

Terraform configurations benefit from formatting, validation, provider locking, static analysis, secret scanning, and plan review. Tools such as Terraform-native validation, linters, security scanners, and policy engines can identify insecure configurations, but no scanner understands every organizational context. Ansible projects benefit from syntax checking, linting, molecule-style testing where appropriate, inventory validation, safe handling of privilege escalation, and review of shell or command tasks.

A representative pipeline may contain these stages:

• authenticate using a short-lived workload identity;
• fetch approved dependencies and verify their versions and provenance;
• scan source for secrets and unsafe patterns;
• format and syntactically validate configuration;
• run unit or module tests and static security analysis;
• generate a plan without exposing it in public logs;
• evaluate policy and compliance controls;
• obtain peer approval for sensitive environments;
• apply through a controlled runner;
• record audit evidence and perform post-deployment checks.

Vulnerability scanning should cover both IaC definitions and the systems they create. IaC scanning may detect public storage or weak security groups; image and package scanning may identify vulnerable operating-system components; runtime tools may detect drift or exposed services. Findings must be prioritized by exploitability, exposure, asset value, and compensating controls rather than by scanner count alone.

A Strategic Control Framework

A practical governance framework can be organized into five control layers. Identity controls govern who or what may execute actions. Content controls govern the safety and provenance of code and dependencies. Execution controls govern where and how plans are applied. Data controls protect state, secrets, logs, and backups. Assurance controls test, monitor, document, and improve the other layers.

This model supports separation of duties. One team may maintain reusable modules, another may approve production policies, and a platform team may operate the execution environment. Excessive separation can create delays and encourage bypasses, so responsibilities should be explicit rather than needlessly fragmented. Managers must also fund remediation capacity; a policy that continuously produces unaddressed findings is not effective governance.

Illustrative Case Study: Securing a Multi-Environment Delivery Platform

Background

A fictional financial-services organization, Northstar Finance, used Terraform for cloud networks and managed services and Ansible for operating-system configuration. Development teams stored configurations in a central Git repository, while a CI platform performed deployments to development, staging, and production.

Situation and Problem

An internal review found three weaknesses. A cloud access key was stored in a CI variable with a long lifetime. Terraform state was held in a shared object-storage location with broad read access. Several teams downloaded public modules without version constraints. No policy check blocked public storage or unrestricted administrative ingress.

The organization had not experienced a confirmed breach, but the combination created a high-impact risk. A compromised repository account could expose credentials and state, modify dependencies, and deploy resources with excessive permissions.

Analysis

The review classified the risks by confidentiality, integrity, and blast radius. The long-lived key could be reused outside CI. Shared state access exposed secrets and enabled unauthorized changes. Uncontrolled modules created a supply-chain dependency without reliable provenance. The absence of policy enforcement allowed insecure designs to pass ordinary code review.

Approach and Solution

Northstar replaced static CI keys with workload identity federation and separate roles for planning and applying. Production apply permissions were restricted to a dedicated runner and required approval. State was moved to an encrypted remote backend with locking, versioning, access logs, and separate state boundaries for environments.

The platform team established a private module registry and required provider lock files and approved versions. Dependencies were reviewed, scanned, and periodically updated. A secret manager replaced repository and CI-file storage of credentials; jobs received short-lived, narrowly scoped values.

Policy checks were added to reject public storage, unrestricted administrative ports, unencrypted databases, missing ownership tags, and deployment to unapproved regions. A documented exception process allowed temporary deviations with an owner and expiry date. Secret scanning, IaC scanning, Ansible linting, and plan review became mandatory pipeline stages.

Outcome

The organization reduced the persistence and scope of deployment credentials, improved visibility into state access, and prevented several insecure designs before deployment. The process initially increased pipeline duration and required module remediation. Management addressed this by providing reusable secure modules, clear policy guidance, and a service-level target for exception review.

Learning Points

The case demonstrates that IaC security is systemic. No single tool solved the problem. Identity, state protection, provenance, policy, testing, and governance had to operate together. It also shows that enforcement is more successful when teams receive secure abstractions and practical remediation support rather than only rejection messages.

Challenges, Limitations, and Common Mistakes

A common mistake is assuming that a hidden console value is a protected secret. Sensitive flags, masking, and encrypted files reduce exposure but do not eliminate it. Another mistake is granting the entire deployment system administrator privileges because resource dependencies are not understood. Permissions should be iteratively narrowed using observed use, documentation, and separate roles.

Organizations also overestimate scanners. False positives produce alert fatigue, while false negatives occur when a tool lacks context or cannot evaluate runtime behavior. Scanning should be combined with architecture review, threat modelling, testing, and monitoring. Excessive policy strictness can encourage manual changes outside IaC, creating drift and reducing accountability.

Emergency access presents another challenge. A fully blocked production environment may be unsafe during a major incident. Break-glass access should therefore exist where justified, use strong authentication, be time limited, generate high-priority alerts, and require retrospective review. Finally, security controls themselves require maintenance: providers change, cloud services evolve, policies become obsolete, and cryptographic practices require periodic reassessment.

Ethical, Regulatory, and Professional Considerations

IaC decisions affect employees, customers, and the public. Exposing personal data through an incorrectly configured resource can cause harm beyond technical inconvenience. Professionals must apply data minimization, purpose limitation, appropriate retention, and access accountability. Regulatory requirements may demand evidence of access control, encryption, change management, logging, or recovery capability, but compliance should not be reduced to checkbox activity.

Security exceptions require ethical judgment. A business deadline does not automatically justify accepting an unbounded risk. Decision-makers should document the affected assets, probability, impact, compensating controls, owner, and expiration. Engineers also have a professional responsibility not to conceal insecure defaults or suppress material findings merely to achieve deployment targets.

Emerging Directions

Current practice is moving toward identity-centric automation, policy-driven platforms, signed artifacts, continuous compliance, and automated drift remediation. Software supply-chain frameworks increasingly emphasize verifiable build processes and attestations. Machine learning may assist in detecting anomalous changes or prioritizing findings, but automated recommendations require human validation because infrastructure context and business impact are difficult to infer reliably.

The strategic direction is toward secure-by-default platforms: approved modules, centrally managed identities, standardized pipelines, policy libraries, and observable execution environments. Such platforms shift security from individual expertise toward organizational capability while preserving appropriate team autonomy.

Best Practices

• Use short-lived, workload-specific identities rather than shared static credentials.
• Protect state, plans, logs, backups, and artifacts as sensitive data.
• Retrieve secrets at runtime from an audited secret-management system.
• Encrypt data in transit and at rest, and manage keys separately from protected data.
• Pin and verify providers, modules, roles, collections, and other dependencies.
• Maintain a curated registry and document component provenance.
• Scan source, dependencies, images, plans, and runtime environments.
• Enforce high-risk controls through policy as code before deployment.
• Separate planning, approval, and production application responsibilities.
• Test secure modules and provide safe defaults.
• Make exceptions explicit, time limited, and auditable.
• Monitor state access, privileged actions, drift, and emergency use.

Chapter Summary

Security in Terraform and Ansible is a system property covering identities, code, dependencies, execution, state, secrets, and operational evidence. Least privilege limits the impact of compromised accounts, while secure state backends protect the sensitive record of infrastructure. Secret managers, encryption, key governance, and short-lived credentials reduce exposure. Provider, module, role, and collection provenance controls address supply-chain risk. Policy as code converts security and compliance requirements into enforceable decisions across source, plan, admission, and runtime stages. Scanning and testing are valuable but must be combined with contextual review, monitoring, and governance. Effective organizations make secure defaults reusable, exceptions accountable, and automation auditable.

Key Terms

Least privilege: Granting only the permissions necessary for a task, identity, and time period.

Secret: Sensitive information whose disclosure may enable unauthorized access or cause harm.

Terraform state: Data recording Terraform’s knowledge of managed resources and their attributes.

Sensitive value: A value treated specially to reduce display or logging exposure; it is not automatically encrypted.

Remote backend: A service or location used to store and coordinate Terraform state outside a local workstation.

State locking: A mechanism that prevents conflicting concurrent changes to state.

Workload identity: A machine identity used by an application, runner, or automation process.

Federated identity: An identity established through a trusted relationship without storing a long-lived local credential.

Encryption at rest: Protection applied to persisted data.

Encryption in transit: Protection applied to data moving between systems.

Key management: The governance of cryptographic-key creation, use, rotation, storage, and revocation.

Provenance: Evidence describing an artifact’s origin, construction, and integrity.

Dependency pinning: Restricting a dependency to a specified version or approved range.

Policy as code: Machine-evaluable rules that express and enforce organizational requirements.

Compliance automation: Automated assessment, prevention, or evidence collection for required controls.

Drift: A difference between declared infrastructure and the actual deployed environment.

Break-glass access: Exceptional emergency access subject to heightened controls and review.

Supply-chain risk: Risk introduced through external components, tools, build systems, or dependencies.

Review Questions

Short Answer Questions

1. Why is Terraform state considered sensitive even when configuration files contain no passwords?

2. Distinguish a sensitive value from an encrypted value.

3. What is the purpose of provider or collection provenance?

4. How does workload identity improve on long-lived access keys?

5. What characteristics should a valid policy exception have?

Long Answer Questions

1. Explain how least privilege should be applied across developers, CI runners, Terraform backends, and Ansible execution.

2. Discuss a complete architecture for managing secrets and encryption in an IaC platform.

3. Explain the role of policy as code across source, plan, admission, runtime, and evidence stages.

4. Analyse the major supply-chain risks associated with Terraform providers and Ansible collections and propose controls.

5. Design a secure IaC pipeline for a production environment, including testing, scanning, approval, deployment, and monitoring.

Analytical / Application Questions

1. A CI job can read all production secrets and apply any Terraform resource. Analyse the risks and redesign its identity and execution model.

2. A policy blocks every public endpoint, but a documented business service requires one. Develop an exception and compensating-control process that preserves governance.

3. An organization uses encrypted state but stores plan files and verbose logs indefinitely in a shared artifact repository. Evaluate the weakness and recommend corrective measures.

22. Multiple Choice Questions with Answers

Question 1

Which statement most accurately describes a Terraform sensitive value?

A. It is always encrypted in the state file.

B. It is hidden from all users, including authorized administrators.

C. It reduces ordinary display exposure but may still exist in state or plans.

D. It automatically retrieves the value from a secret manager.

Correct Answer: C. It reduces ordinary display exposure but may still exist in state or plans.

Question 2

Which design best demonstrates least privilege in a CI/CD system?

A. One administrator credential is shared by all pipelines.

B. Planning and production application use separate, narrowly scoped identities.

C. Every pipeline receives permission to read all organizational secrets.

D. Developers use the production deployment identity for troubleshooting.

Correct Answer: B. Planning and production application use separate, narrowly scoped identities.

Question 3

Why must Terraform plan files be protected?

A. They are required only for formatting configuration.

B. They can contain proposed resource attributes and sensitive values.

C. They cannot be regenerated after a failed deployment.

D. They replace the need for state locking.

Correct Answer: B. They can contain proposed resource attributes and sensitive values.

Question 4

Which control most directly addresses the provenance of an external Terraform provider?

A. Increasing the CI runner’s memory.

B. Disabling state versioning.

C. Verifying approved versions, checksums, or signatures.

D. Allowing unrestricted provider downloads.

Correct Answer: C. Verifying approved versions, checksums, or signatures.

Question 5

At which stage does a policy that rejects an unencrypted database in a Terraform plan operate most directly?

A. Plan evaluation before application.

B. Employee performance review.

C. Cryptographic key destruction only.

D. Physical network cabling.

Correct Answer: A. Plan evaluation before application.

Question 6

What is the primary advantage of short-lived federated credentials?

A. They eliminate the need for authorization.

B. They reduce the persistence and reuse of stolen credentials.

C. They allow every job to become an administrator.

D. They prevent all configuration errors.

Correct Answer: B. They reduce the persistence and reuse of stolen credentials.

Question 7

An Ansible task uses `no_log: true` for every task in a playbook. What is the main concern?

A. It necessarily encrypts all inventory files.

B. It may reduce auditability and make troubleshooting difficult.

C. It grants excessive cloud permissions.

D. It verifies collection signatures.

Correct Answer: B. It may reduce auditability and make troubleshooting difficult.

Question 8

Which response is most appropriate for a high-impact policy exception?

A. Ignore the violation if deployment is urgent.

B. Make the exception permanent and undocumented.

C. Record an owner, rationale, expiry, approval, and compensating controls.

D. Move the deployment outside the IaC pipeline.

Correct Answer: C. Record an owner, rationale, expiry, approval, and compensating controls.

Question 9

Why are security scanners insufficient as the only IaC security control?

A. They cannot identify any syntax errors.

B. They always block every deployment.

C. They may lack business context and produce false positives or negatives.

D. They make state storage unnecessary.

Correct Answer: C. They may lack business context and produce false positives or negatives.

Question 10

Which control most directly reduces concurrent Terraform state corruption?

A. State locking.

B. Public state access.

C. Unpinned modules.

D. Disabling audit logs.

Correct Answer: A. State locking.