Feature Requests

Anonymous

Feature Requests for Harness. Select 'Category' based on the module you are requesting the feature for.
Support Account-Level Pod Spec Overlay Configuration for IaCM Kubernetes Execution Pods
Use Case Customers running IaCM pipelines with KubernetesDirect infrastructure need to apply Kubernetes pod-level settings consistently to the build execution pods created for Terraform operations such as Plan and Apply. For example, the customer needs to configure: spec: terminationGracePeriodSeconds: 600 tolerations: - key: "<key>" operator: "Equal" value: "<value>" effect: "NoSchedule" IaCM currently supports podSpecOverlay when it is configured directly on the individual IaCM stage through pipeline YAML: infrastructure: type: KubernetesDirect spec: connectorRef: <connector> namespace: <namespace> podSpecOverlay: |- spec: terminationGracePeriodSeconds: 600 tolerations: - key: "<key>" operator: "Equal" value: "<value>" effect: "NoSchedule" Current Gap We do not want to configure this separately in every IaCM pipeline/stage. For CI, customers can configure a default Pod Spec Overlay centrally under: Account Settings → Default Settings → Pod Spec Overlay We would like equivalent functionality for IaCM so that Kubernetes pod configuration can be defined once at the account level and automatically inherited by temporary IaCM execution pods. Requested Enhancement Add an account-level/default Pod Spec Overlay configuration for IaCM, similar to the existing CI capability. Ideally, customers should be able to define an IaCM Pod Spec Overlay under account settings and have it automatically applied to IaCM KubernetesDirect execution pods, while still allowing stage-level configuration/overrides where appropriate.
1
·
IACM
·
under review
Policy as Code: Run IaCM OPA policy evaluation as its own pipeline step, separate from the plan step
Current behavior In IaCM pipelines, OPA policies are evaluated as a post-plan hook (afterTerraformPlan). They run inside the same step as terraform plan / tofu plan, as soon as the plan finishes. That same step does two jobs: it generates the plan and evaluates it against every policy set in scope. Problems Hard-to-read logs. Plan output and policy evaluation output share one console log. For large plans, reviewers have to scroll through thousands of plan lines to find the policy results, or the plan changes past the policy output. It's hard to review either one. Plan steps sized for the peak. The plan step's container needs enough CPU and memory for both plan generation and OPA evaluation of the full plan JSON. Every plan step has to be sized for that combined peak, even though the two jobs never run at the same time. For workspaces with large plans or many policies, that means raising workspace-wide resource limits, which affects every run of the workspace, not just policy evaluation. Request Make policy evaluation a separate step that runs after the plan step, in its own container. Its own step: in the pipeline graph and execution view, with its own console log, status and duration. Its own resources: configurable separately from the plan step, so each step can be sized for its own work. Same inputs as today: it consumes the plan output (plan JSON) produced by the plan step. Same outcome as today: a deny policy still blocks the pipeline before apply, and warnings are still reported. Ideally, backward compatible: an opt-in setting per pipeline or workspace, or a new step type, so existing pipelines keep working unchanged. Business impact Faster, more reliable reviews. Plan and policy results can be read, linked to and shared on their own, which speeds up change review and incident investigation. Lower resource cost. Plan steps no longer carry OPA's memory and CPU. Resources can be sized per step instead of for the worst case. Clearer failures. A policy failure shows up as a failed policy step, not a failed plan step, so users and automation can tell "the plan failed" from "a policy blocked the change". Scales with policy adoption. As organizations add more policy sets, evaluation cost grows without making every plan step bigger.
0
·
IACM
Deployment Freeze Windows for IaCM (Infrastructure as Code Management)
Problem IaCM currently has no equivalent of CD's Deployment Freeze Window. Freeze windows today can only be configured for CD modules (services/environments) — there's no option to freeze IaCM workspaces/pipelines. Customer use case Twilio periodically performs maintenance on Harness delegates (destroying and recreating them), during which delegates are unavailable for ~1 hour. Their IaCM pipelines (plan/apply) depend on those delegates, so any pipeline triggered during that window fails. They want a way to prevent IaCM pipelines from being triggered while delegate maintenance is in progress — i.e., a scheduled freeze window scoped to IaCM workspaces/pipelines, matching the capability CD already has. Current workarounds: OPA + Manual Approval gates — requires custom policy authoring per workspace/pipeline; not a first-class scheduled freeze. Queue + Barrier steps with Approvals — same limitation; approval-based, not time-window-based, and puts the onus on manual intervention during the freeze rather than blocking automatically. Manually locking the workspace — only viable if the freeze is workspace-scoped, and requires manual toggling before/after every maintenance window rather than a scheduled window. None of these give a native, scheduled "no pipelines will run in this window" guarantee the way CD's freeze feature does. Ask Add Deployment Freeze Window support for IaCM, scoped at the workspace (and ideally pipeline/org/project) level, consistent with the existing CD freeze window model — so customers doing infra/delegate maintenance can block plan/apply execution for a defined time range without custom OPA policies or manual gating.
0
·
IACM
Load More
→