Skip to main content

IaCM Security

Last updated on

Harness IaCM integrates security measures to safeguard your infrastructure state. It uses the Harness Platform’s authentication, RBAC, resource groups, pipelines, Audit Trail, connectors, secrets, and licensing, consistent with the practices summarized on Harness Trust & Security. For Infrastructure as Code Management (IaCM), Harness provides the following:

  • Data encryption in transit using TLS 1.3.
  • Data encryption at rest with AES 256.
  • Regular security testing and vulnerability scanning.
  • Logical and physical data segmentation.

Addressing common security concerns​

Harness protects customer infrastructure and data through access controls, encryption (TLS 1.3 in transit and AES-256 at rest where applicable), and separation of customer data. You can integrate your identity provider, constrain access with RBAC, and use IP allowlisting and delegate networking so outbound and inbound patterns match your enterprise standards. For broader connectivity options (including private access patterns), see Private network connectivity.

During planning and execution, Harness can enforce policy on infrastructure changes (for example via Open Policy Agent (OPA) and plan and cost policies) and maintain copies of plan and state for visibility and controls as described below.

For cost estimation, Harness can use Infracost when the feature is enabled on the workspace; supported behavior and licensing follow that topic and What’s supported in IaCM.

Drift detection and IaC security scanning (STO) are complementary capabilities for ongoing posture and code review — they extend the core plan/apply flow rather than replacing it.

Platform AI and automation features evolve on their own roadmap; they use the same RBAC and pipeline audit patterns as other Harness execution. For current IaCM-specific integrations (for example MCP), see What’s supported in IaCM.

Security components​

The operational model is comprised of three components:

Manage state storage​

All executed commands follow your defined backend, dictating where your infrastructure state is stored and managing OpenTofu or Terraform operations like apply and destroy.

default backend

If no plan file is specified, IaCM defaults to its own backend implicitly.

Network egress and allowlisting​

IaCM execution typically runs on infrastructure you control (for example a Kubernetes delegate). Plan your network so that:

Contact Harness Support for region- and product-specific allowlist guidance if you are locking down egress or ingress.

Audit trail, retention, and export​

Harness Audit Trail records many configuration and lifecycle actions (who did what, when, and on which resource). The UI supports filtered views and date ranges; audit data is retained up to two years in Harness. To keep logs longer or feed a SIEM, use audit log streaming.

Pipeline execution events are optional: enable Pipeline Execution Audit Events at account scope if you need start/end and stage events in the audit trail (see the Audit Trail overview). IaCM workspace and module changes appear under the Infrastructure as Code Manager category in audit documentation.

Operational model​

In infrastructure management, security depends on controlling who can change state, what runs in the pipeline, and how plans and policies are evaluated before apply.

The diagram below illustrates the high-level operational security flow. Harness continues to add capabilities (additional scanners, drift workflows, policies, and integrations); treat this as the core plan/apply path — refer to Get started with IaCM and What’s supported for the latest feature set.

  1. Run the plan command: The plan runs in your pipeline environment and compares proposed changes with state from your configured backend.
  2. Cost estimation and policy checks: When enabled, plan output can be used for cost estimation (Infracost-based) and evaluated against OPA policies and plan / cost policies on the plan entity.
  3. Plan storage: A copy of the plan can be stored in Harness Cloud for pipeline history and tracking.
  4. Confirm apply/destroy parameters: Before mutating infrastructure, IaCM validates the proposed operation against the expected backend state.
  5. Apply/destroy execution: After checks pass, changes run in the pipeline environment; policies and approvals you configure still apply.
  6. State storage and historical tracking: State is maintained per your backend; Harness also retains copies as described in Cloud-based security measures for product features.

IaCM Security Diagram: Flow from pipeline execution, through state storage, to Harness Cloud security