Feature Requests

The serviceDefinition YAML of an service types K8s,ECS etc is not fully expanding to the harness pipeline YAML.

The "core_usergroup_manageUsers" permission grants acces to add users to groups, but it also also grants access to binding roles/resource groups on users AND groups. Ideally this permission would be 3 separate permissions one for managing group membership (adding/removing members of groups), one for managing role bindings on groups, and one for managing role bindings on users. This came up as we would like grant access for users to add users to their project, add them to pre-set groups with pre-set role bindings as there are many permissions we don't want to allow users to have for maintaining our security model. Since adding users to groups comes bundles with managing role bindings, users with this permission can bypass the access controls we've put in place and grant themselves or anyone else any role/permissions in the platform.

Hi, My team (or individuals?) is (are?) limited to 5 data export report generations per day. Recently I misclicked report generation. I did not actually need the output, but had no means of cancelling it. It would be nice to be able to cancel an ongoing data export - even if it was just a 1-2 min grace period in the initial phase of data export generation where one could do so. Thanks, PB

I would like to request a new feature to allow audit log streaming directly to Google Chronicle SIEM. Currently, the only supported endpoint for audit log streaming is an AWS S3 bucket. As a customer who uses Google Cloud services extensively, having a native integration with Google's SIEM solution would be highly beneficial for our security and compliance workflows. Given that the Harness platform is built on GCP, we believe that adding support for Google Chronicle would be a straightforward enhancement. This would improve the security posture for customers in the GCP ecosystem and provide a more seamless integration experience. For more information on Google Chronicle, please see their documentation: https://docs.cloud.google.com/chronicle/docs/overview Thank you for considering this request. Best Regards, Sridhar

To help maintain existing customer login flows during the authentication process ( https://developer.harness.io/docs/platform/harness-ai/cursor-plugin/#authenticate ) for the Cursor plugin, SSO support would be a great help.

Problem Statement Currently, personal API tokens created by users in their profile settings can only be deleted by the token owner. This creates a security control gap where administrators have no ability to revoke a user’s API access in scenarios where immediate token revocation is necessary (e.g., compromised accounts, departing employees, security incidents, policy violations). Current State Service account tokens: RBAC controls exist for deletion User profile tokens: Only the user can delete their own tokens No admin override capability exists Requested Functionality Enable account administrators and authorized service accounts to delete user API tokens created at the user profile level. Specific Requirements: Admin users should be able to delete any regular user’s API tokens Service accounts with appropriate account-level permissions should be able to delete regular user’s API tokens Should maintain audit trail of token deletions (who deleted, when, which token) Use Cases Security Incident Response: Immediately revoke tokens for compromised accounts Offboarding: Ensure complete access revocation when users leave Compliance: Enforce token rotation policies Policy Enforcement: Revoke tokens that violate security policies

For SMP, we are trying to manage RBAC fully at the account level using existing roles and account-scoped resource groups. Their intended access model is: DevOps users should have access to project-level resources DevOps users should not be able to edit organization-level resources Org admins should continue to have full access to organization-level resources We are correctly using the model where: the Role defines the permissions/actions the Resource Group defines the scope where those permissions apply A key requirement for this use case is that RBAC management must remain centralized at the account level. We are not looking for a workaround that depends on creating or maintaining additional bindings, roles, or resource-group configurations separately at the organization or project scopes. Their goal is to: manage access centrally from the account scope grant access to all projects under selected orgs exclude organization-level resources avoid ongoing per-project or per-org maintenance outside the account-level RBAC model Because of that, solutions that rely on additional configuration at org or project scope would not meet the intended operational requirement. This is not only a usability issue, but also a scalability issue for customers who intentionally manage RBAC centrally at the account level. In this case, the requirement is to keep the access model fully managed from the account scope. A solution that requires additional RBAC configuration or maintenance at the org or project scopes would not satisfy that requirement. The customer has 100+ projects, so maintaining access by manually selecting each project under Specified Projects is not feasible, even as a workaround. Today, the current resource-group behavior appears to force customers into one of these two options: include org-level resources even when they do not want to manually maintain large project lists Neither option satisfies the customer’s intended centralized RBAC model. Please support an account-scoped resource group configuration that allows: selecting one or more organizations including all current and future projects under those selected organizations excluding organization-level resources without requiring manual selection and maintenance of each project

Many of the OOTB pipelines/preconfigured steps are vulnerable to dockerhub rate limiting because the default docker connector is for anonymous access to dockerhub. As you know, this limits an organization to 100 Pulls over 6 hours from each distinct outbound ip address. Instead, it seems like a better approach would be to have on out of the box mechanism for designating a default docker connector (such as an account variable), and configure OOTB pipelines (especially those in IaCM and IDP) to use that mechanism by default We have implemented a prototype of this in our account, using one of our artifactory docker registries as the connector endpoint. It works, but it stil requires us to manually edit potentially every OOTB pipeline in order to select the variable we use to hold our default connector. Not only does this approach, coupled with appropriately configured OOTB pipelines, allow us to avoid a very common error, but it allows us to mass-reconfigure those pipelines if the connector needs to be replaced or updated.

In a POV, and customer is raising a concern before purchase. Other vendors use OAUTH in their GHA integrations to controls repo access and other RBAC. Customer says we are one of the only ones who does not do this. It would be useful as it would reduce the number of connectors, especially in enterprise accounts that have 100s or even 1000+ GH orgs. This becomes and implementation issue for us.

Requesting an enhancement to allow users to use/reference account-level templates in pipelines without being able to view the underlying template YAML/code. Currently, granting template access enables read-only visibility of the template definition. We need a finer-grained permission model that supports use-only template consumption, while restricting template code visibility for security and governance purposes. This capability would help protect centralized and sensitive deployment logic while still enabling standardized reuse across teams.