Feature Requests

When rotate an api key and select expiration date, it will be less chance to make mistakes if there is date selection we could click on

Description: NAB has a requirement to set a Time-To-Live (TTL) on a delegate token while managing delegates using Terraform. Currently, our Terraform provider does not support any parameter that allows configuring TTL for delegate tokens. Requested Enhancement: Introduce a configurable parameter in the Terraform provider to allow users to define a TTL for delegate tokens during delegate creation or update.

Is there any way to restrict what stage or step goes into certain Insert Stage? Use case includes but not limited to: Ensure user does not insert an incorrect stage for purpose For sequential stages, gets inserted with a correct order

Need a feature to access file store from dashboard to get data from their and show it on UI.

Add tags to recommendations table in dashboards. The current fields available are not sufficient for adding value and slicing and dicing information. Cloud Accounts can be created and deleted all the time, which requires significant overhead to maintain dashboards for senior leaders. Ideally tags would come from the cloud account level.

When I hover on the left menu items Account Settings, Organization Settings...etc which then pop-out a submenu of selections, those selections appear is what look to be just a random order. The options are not categorized, or listed alphabetically, or organized in any other way that I can tell. This makes it difficult to find the selection I'm looking for so I resort to clicking the settings option and using the settings page to find what I'm looking for. Some intuitive organization of the pop-out options would be helpful.

The ask is to have the platform act as an OIDC Identity Provider, so it can issue short lived tokens that other systems can validate and grant access based on combination of parameters such as workspace/pipeline/environment/workflow/event/repo. Here is workload identity documentation from HCP: https://developer.hashicorp.com/terraform/cloud-docs/workspaces/dynamic-provider-credentials https://developer.hashicorp.com/terraform/cloud-docs/workspaces/dynamic-provider-credentials/workload-identity-tokens and here is another example from github explaining it: https://docs.github.com/en/actions/security-for-github-actions/security-hardening-your-deployments/about-security-hardening-with-openid-connect We would use this to grant roles and access in a secret management platforms such as HashiCorp Vault or Akeyless. This would enable workflows to either access secrets directly or configure access for other systems, all while avoiding hard coded, long lived secrets.

There is no ability to sign SAML request or response/assertion currently, only the ability to encrypt the assertion.

Currently, Harness defaults to running all pods and containers in privileged mode, which is not aligned with container security best practices. In most use cases, elevated privileges are unnecessary and introduce avoidable security risks. Problem: Privileged containers have unrestricted access to the host system, which increases the attack surface and violates the principle of least privilege. Many enterprise environments enforce strict security policies that prohibit privileged workloads, requiring additional configuration or workarounds to use Harness. This default behaviour can lead to non-compliance with internal security standards and external regulatory requirements. Proposed Solution: Change the default behaviour so that all pods and containers launched by Harness run in non-privileged mode by default. Allow users to explicitly opt-in to privileged mode only when required, with clear documentation and warnings about the associated risks. Provide configuration options at the account, org, and project levels to enforce non-privileged execution as a policy. Benefits: Aligns Harness with Kubernetes and container security best practices. Reduces the risk of privilege escalation and host compromise. Improves compatibility with hardened environments and security-conscious organisations. Enhances trust and adoption among security and compliance teams.

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.