Feature Requests

Currently only for pipeline entities, gitconfig is available for policy evaluation. The feature request is to make this available for all entities backed by git manifest. This will allow use cases such as "disabling direct commits to main branch" or allowing pushes only on feature or release branches.

As a security measure, users should not be allowed to create or use personal API Tokens. All user authentication must go through MFA.

Description: We need a second layer of protection for our Harness tenant that goes beyond validating client certificates via the root of trust (i.e., CA-based validation). Specifically, we require support for client identity authorization based on Subject Alternative Name (SAN) fields in the client certificate. Current Behavior: Harness’s Envoy-based mTLS implementation performs certificate validation via CA trust (root of trust), but does not currently verify the client identity (e.g., via SAN). Requested Enhancement: Add support to authorize client identity via SAN fields in the client certificate. Allow customers to configure an allowlist of permitted identities (e.g., specific SAN values) via a tenant-level setting. This configuration should be exposed through existing elevated privilege mechanisms, such as those used for managing tenant-wide properties (like IDP integrations). Harness should enforce that incoming requests to the customer tenant originate from a pre-authorized identity, not just a certificate issued by the customer's CA. Business Justification: This feature will help prevent unauthorized internal services (with valid customer-issued certs) from accessing the Harness tenant without explicit identity-level authorization.

We'd like to control the creation of Scheduled Delivery of Dashboard events via API. There is no information about how we can do so in the API Docs, and doesn't appear to be a method to do so.

A number of functionalities across the Harness product would benefit from key changes. Ability to review / extend the default Harness behaviours (IACM for example to allow additional cli tooling for use on self hosted k8s infrastructure) Stop reliance on the "home" folder for all operations - if the home user is not set correctly due to security restrictions and alternate users applied - this results in attempted root file system modification which renders the image useless Provide and publicize non-root users outside of key ranges for all functionality (over the reserved user ids up to 1000 at a minimum) A number of the Harness current offerings do not work for us on our Openshift clusters due to security restrictions particularly with SE lInux contexts

would like to use the functionality of Delegate Selector List and I want to do with an OR condition. Namely, I have delegates tags: ec2-<+pipeline.variables.account> vm-<+pipeline.variables.account> And I want to select the one available based on the variable <+pipeline.variables.account>.

We need a full replica of our production account in the Prod 0 environment to effectively test our pipelines and other features. Currently, we lack the capability to replicate data across different account IDs, which hinders our testing process. It would be beneficial if we could replicate our production data to the Prod 0 account to ensure a seamless testing experience.

Description: On the DORA Metrics dashboard in Harness, we are currently unable to list more than 50 projects. Additionally, when cloning a DORA Metrics dashboard and manually selecting advanced options (model explore and fields) for Continuous Delivery, GitOps, Deployment, and Service V2, the same 50-project limit applies. This limitation restricts users from being able to list and work with more than 50 projects. Requested Improvement: Allow more than 50 values to be listed and displayed on the DORA Metrics dashboard, both when viewing and cloning the dashboard. This would improve flexibility and usability, especially for users managing larger sets of projects. Steps to Reproduce: Navigate to the DORA Metrics dashboard in Harness. Attempt to list projects – only 50 projects are displayed. Clone the dashboard and try to manually select advanced options for Continuous Delivery, GitOps, Deployment, and Service V2 – again, only 50 projects are available. Acceptance Criteria: The DORA Metrics dashboard should support listing and displaying more than 50 projects. When cloning the dashboard, the same number of projects should be selectable, beyond the current 50-project limit.