Feature Requests

Currently, the Shell Script step does not automatically inherit or use permissions associated with a configured connector. Users must manually handle authentication, for example by writing scripts to assume roles when using OIDC. Problem Statement: This creates additional overhead and inconsistency compared to other steps that already leverage connector credentials natively. Users expect the Shell Script step to seamlessly use the same connector permissions without needing to manually replicate the authentication logic. Requested Feature: Enable the Shell Script step to optionally use connector credentials automatically (similar to how other steps handle authentication). This could be implemented via a toggle or configuration field that allows users to select an existing connector for credential context. Example Use Case: A user wants to run a script in an AWS environment using OIDC. Today, they must add logic in the script to assume the IAM role manually. With this feature, the step would automatically inherit the connector’s OIDC permissions, eliminating that extra scripting.

I need a way to prevent the platform from assigning arbitrary tasks to a delegate. It would be helpful if the platform could restrict delegate usage to specific tasks by either assigning users to it via RBAC or requiring a delegate selector to be specified. This would ensure that delegates are only used for their intended purposes and not for unrelated tasks.

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

When setting the report on a quarterly frequency. Currently, only the last month's cost can be provided in the report. This doesn't match the frequency and period needed. UKRI would like to be able to use custom dates such as last 3 months or custom period

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