Feature Requests

Currently the "From email" exists on the SMTP setting which is generally at the account level Ref: https://developer.harness.io/docs/platform/notifications/add-smtp-configuration/#step-2-details . There are requests from internal customers to have this from email customizable. For instance, any setting at the Org/project level or the email/notification step level. It would help to have this feature and would be beneficial for the teams that operate at the Org/project level

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.

For Enterprises that have thousands of users registered in Harness, we would like for the Subscriptions/usage details page to be available only for Account Admins.

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.

Support Built In Akamai Connector In Harness To add Akamai net storage connectivity with Harness? and deploy in that using Harness Can you kindly support the Built-In Akamai Connector In Harness

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>.