Feature Requests

plugins/cache plugins/sto plugins/s3

Description When Harness issues OIDC tokens for pipelines, the token currently includes claims like account_id, organization_id, project_id, pipeline_id, and connector_id. Please add environment-related claims (for example environment_id and optionally environment_name) to these tokens. This would allow customers to: Use environment-aware conditions in their GCP (or other cloud) IAM/WIF policies (e.g., only allow certain roles when environment_id = prod, stage, etc.). Strengthen their security posture by tying cloud access more tightly to Harness deployment context without having to bolt on separate metadata or side channels. Impact / Value Improves least-privilege and environment-segregation controls in cloud IAM. Aligns OIDC token contents across multiple scenarios where environment context is security-relevant. Reduces the need for custom glue logic (extra metadata and mapping) between Harness and cloud IAM policies.

Customer wants to have a feature in harness which helps them to see the delegate references and their corresponding pipelines or any entities. This feature is needed in both UI and also through APIs.

Hi Team- We have a request to correlate a delegate taskId back to the pipelineExecutionId that initiated the task. Scenarios: log throw resource threshold and rejection, we want to look which pipeline execution is running these tasks on the delegate that’s potentially consuming the resources data lost prevention (dlp) block data on have taskID, we want to be able to know which pipeline execution is causing the block to be able provide context to team to resolve the issue

Right now the rollback steps can only run on certain types of non-successes (namely Failures and I believe Expiries), which leaves some potential issues unkept/unattended when pipelines are aborted or otherwise. Ideally, we want to be able to optionally perform some kinds of rollback steps on any type of status of the pipeline other than success.

PR_CHECK Pipeline webhook execution git lable change Need your availiability.

It would be highly beneficial to enable searching and filtering of Harness OPA Policies by their configured action type (e.g., Warn & Continue or Error & Exit). Currently, policies can only be searched by name, which makes it difficult to quickly identify those set to Error & Exit. Adding this capability would greatly improve policy management and visibility.

Our current requirement is to drive adoption of these policies like the vulnerability count of New critical/high, and we want every developer to be aware when their pipeline has warnings. Requiring users to switch off the console view and manually check the Policy Enforcement section defeats this purpose, as it adds unnecessary steps and reduces visibility. Additionally, even if developers switch to the normal view, they would first need to know that a step-level policy exists and that it can generate warnings or errors. Expecting this level of awareness isn’t practical and limits the effectiveness of policy enforcement. Ideally, these warnings should be displayed directly in the pipeline UI or logs, ensuring developers can easily notice and act on them without having to change views.

We have a security requirement that needs us to utilize Bearer tokens instead of other authentication. Harness JFrog Connectors do not seem to support bearer authentication.

See the attached diagram depicting the multiple identity model as we envisioned it. Recommended Process: 1) User Selects/Inputs the UAMI client ID in the Workflow. 2) The Specified UAMI is passed to the Golden Pipeline 3) Golden Pipeline is triggered using Project level connector which is created as part of the bootstrapping pipeline. 4) On AKS cluster, Delegate spins up a NAKED POD using the specified UAMI. 5) A resource can be created on the subscription using the same UAMI