Feature Requests

Enterpris is adopting akeyless. Pls enable native secret manager for akeyless

Drift detection can be enabled in IaCM through the UI, but the Harness Terraform provider doesn't support it. Customers who manage Harness itself as code can't enable or configure drift detection for workspaces or projects. Extend the provider so users can enable drift detection, and set its schedule and related settings, on: the harness_platform_workspace resource (or equivalent), and the project-level configuration. Why it matters: Customers who manage Harness through Terraform can set up drift detection consistently across many workspaces and projects. They no longer have to enable it by hand in the UI. It also keeps their Harness configuration fully declarative and reviewable.

For workspaces with many resources, the Resources tab in the pipeline execution view can take a long time to load. Today users only see a generic loading indicator, so they can't tell whether it's working or how long to wait. Supplement the spinner with a progress indicator that shows the percentage of resource data loaded, for example "Loading resources… 45%". Why it matters: Users get an expectation of the wait time and are less likely to assume the page is stuck. They are also less likely to refresh or leave.

Every Harness IaCM workspace produces a Terraform/OpenTofu plan, but users can't see how large it is without digging into logs. Add two pieces of metadata to each workspace: Plan size: the size of the latest plan. Resource count: the number of resources managed by the workspace. These should be exposed as workspace outputs/parameters and shown in the workspace UI. They should also be available through the API. Why it matters: Teams can see at a glance which workspaces have large plans or many resources. Those workspaces are the candidates for modularization or splitting. Large plans also tend to mean slower runs and heavier resource tabs.

Restore Cache and Save Cache steps don't currently indicate whether a cache was actually restored or saved, the step reports success either way. The only related setting, failIfKeyNotFound, fails the whole stage on a miss, which isn't practical to use just for visibility. Harness Support confirmed hit/miss reporting exists for the newer "restore from Harness" cache step, but not for S3/GCS-backed cache steps on self-hosted infrastructure. We'd like the same reporting extended to those step types, including how much was actually restored. This would let us track time and cost savings from cache restores per pipeline, and identify which pipelines aren't using cache effectively so we can take action

We would like to see more granular failure types that we can use for Failure Strategies. For example, actions on 401 errors vs 403 errors vs 400 errors all fall under authentication but, we want separate actions to happen based on what error code is returned.

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.

Currently on an SMP instance using AWS S3 for logstreaming instead of Minio requires LOG_SERVICE_S3_ACCESS_KEY_ID and LOG_SERVICE_S3_SECRET_ACCESS_KEY . https://developer.harness.io/docs/self-managed-enterprise-edition/advanced-configurations/external-db/minio/configure-aws-s3-for-pipeline-logs/ This request is for having support for IRSA and IAM based authentication instead of having to specify and manage the access key and the secret access key id

USCIS is requesting for Harness SMP to also support Istio in Ambient Mode to enable lighter, more efficient service mesh deployments in EKS. Our understanding is that currently Harness SMP is only supporting Istio Envoy Gateway. Istio in Ambient Mode eliminates the need for sidecar proxies, reducing resource consumption and operational complexity. Adopting Istio in Ambient Mode also aligns with industry trends and enhances Harness’s value for EKS users. Enabling Istio in Ambient Mode will help USCIS and other Harness SMP customers optimize their cloud infrastructure and accelerate application development. It is our understanding that Matt Moran from Harness already opened a Harness internal ticket number CXE-2231 related to this USCIS request. USCIS Git Issue Ticket # for this request is 198

Environments on the flag view are in no particular order making them hard to manage. On most other pages, environments are listed alphabetically which seems reasonable to me but they don't flow like we think about feature management. Most of the time, we're enabling in a lower env then elevating incrementally through environments. I want the ability to choose the display order. In a perfect world too, I want to initialized environments shown on top in my specified order while uninitialized environments are shown below in order to keep flags clean and easy to manage.