Feature Requests

Currently, the user experience for a developer to leverage IDP in order to take advantage of Harness' shift-left capability with IDP+CI+STO is 1) log into IDP 2)see a vulnerability in IDP (The Vulnerabilities tab for a service) 3) Map the vulnerability to a pipeline execution in the CI/CD tab and click into it 4) Click into vulnerabilities tab of the particular pipeline execution 5) Click into the same vulnerability they saw in step 2 6) Finally click "Create PR" or gain access to AI recommended fix It would be great to be able to go from step 2 to step 6 while staying in IDP. Or, surface a hyperlink that maps the IDP "Vulnerabilities" tab scan results to pipeline execution's vulnerability tab.

Problem: Currently, Harness Resource Groups support "By Tag" for Pipelines, but this option is not available for Catalog (IDP) entities. Request: Add a By Tag option for the Catalog resource so access to IDP entities can be managed based on tags.

Currently, IDP Impersonation can only be assigned to individual users who are members of the Account Admin team. This creates a limitation for organizations that have dedicated IDP Admins who are responsible for troubleshooting identity and user-related issues but are not part of the Account Admin team. Our IDP Admins often need the ability to impersonate users for troubleshooting purposes, such as reproducing user-specific issues, validating configurations, investigating authentication problems, and confirming the user experience. However, requiring these administrators to be added to the Account Admin team in order to gain impersonation access can provide broader permissions than are necessary for their role. Our Ask We would like IDP Impersonation to support group-based assignment rather than restricting the capability to the Account Admin team. For example, administrators could be granted impersonation privileges by adding them to a designated group such as IDP Support Admins or User Troubleshooting Admins. Anyone who is a member of that group would then have the appropriate impersonation capability without needing to be granted full Account Admin access. Benefits Supporting group-based assignment would: Provide greater flexibility in managing impersonation permissions. Allow IDP Admins and support teams to troubleshoot users without requiring Account Admin privileges. Follow the principle of least privilege by granting only the permissions necessary for troubleshooting. Make access management easier by allowing organizations to manage permissions through existing groups. Reduce the need to add users to the Account Admin team solely to provide impersonation capabilities. Make it easier to onboard or remove administrators as team responsibilities change. Overall, our request is to allow IDP Impersonation to be assigned to a specific group, giving organizations more granular control over who can impersonate users while avoiding the need to grant full Account Admin access.

Build a feature to support Multiple Github Repository or Sub Github Repository using TechDocs. If this feature is not available then developer have to move all their documents to one master repository.

Description The Direct Push step currently supports pushing to repositories within the same Harness project where the pipeline is executing. It would be useful to extend Direct Push to support repositories located in other Harness projects, provided the executing identity has the required permissions to access the target repository. This would allow pipelines and templates to be centrally managed and reused across projects without requiring the Direct Push step and target repository to exist within the same project. Requested Enhancement Allow the Direct Push step to: Select or reference a repository from another Harness project. Specify the appropriate organization/project scope for the target repository. Use the executing identity’s RBAC permissions to authorize access to the target project/repository. This would make Direct Push more reusable for centralized pipelines and templates that operate across multiple Harness projects.

today, it does not appear to let you do BOTH inputSetName + inputset in IDP workflow action. inputsets let you group entities that are defaulted for say an environment (e.g. envIdentifier, infraIdentifier), but a user will want to be able to override some inputs and pass in a parameter for a artifact version or location.

I can set the actionButton to "warning" and have the button be red, but this does not reflect in any way in the catalog. It would be nice to have the catalog workflow list at least change the play button color or in some way reflect the warning placed on the button.

Description Organizations with a large number of GitHub repositories currently have difficulty using the GitHub Pull Requests and GitHub Insights plugins in Harness IDP. Today, after authenticating with GitHub OAuth, the repository selector only displays the initial set of repositories (currently around 100). For organizations with thousands of repositories, this means many repositories cannot be selected even though the user has permission to access them. It would be valuable if the repository selector supported capabilities such as: Pagination through all available repositories. Repository search. Lazy loading or similar mechanisms to efficiently browse large organizations. This would significantly improve the experience for enterprise customers with large GitHub organizations and make the GitHub integrations usable at scale. Example use case In a scenario where a GitHub organization contains approximately thousands of repositories. Authentication and permissions are working correctly, but only the first ~100 repositories are available for selection, preventing them from configuring the integrations for the repositories they need.

Problem: We are building an API Governance Dashboard using Harness HD Dashboards and need to filter and report APIs based on their lifecycle and domain. These fields are available in the API catalog entity YAML under spec: apiVersion: backstage.io/v1alpha1 kind: API metadata: name: example-api spec: type: openapi lifecycle: production domain: domain:cards owner: group:account/card_services_team However, the l:idp:catalog entity currently exposes only the following fields for HQL queries: kind name type owner tags identifier entity_ref created_at last_updated_at The nested spec.lifecycle and spec.domain values are ingested into the catalog but are not available as queryable fields. We also noticed that idp:api contains a lifecycle field in its schema, but the field currently does not return any data. Requested Enhancement: Expose the following fields as top-level queryable fields on l:idp:catalog: lifecycle — sourced from spec.lifecycle domain — sourced from spec.domain Alternative: Populate the idp:api entity with the corresponding catalog data so that the existing lifecycle field can be queried and a domain field can also be exposed. Business Need: This capability is required to build an API Governance Dashboard that can: Filter APIs by lifecycle — production, experimental, deprecated Filter APIs by domain — cards, payments, accounts, etc. Identify APIs that are missing lifecycle or domain metadata Track API governance and metadata compliance across the organization Expected Outcome: API lifecycle and domain information should be available as HQL-queryable fields in Harness HD Dashboards, allowing customers to build governance dashboards without maintaining a separate data source or duplicating catalog metadata.

Currently, when a develepor registers their Harness CD service into into the IDP catalog utilizing service auto-discovery it only grabs 4 pieces of information. the ability to read add and read a "metadata" block from the actual service object would allow developers to maintain both their IDP catalog entities as well as their actual service in one space, minimizing human toil and creating one source of truth for the service object. custom parsers for the metadata would be an additional ask to allow for seamless updates of the idp catalog without needing to run manual steps every deployment. The same request would be asked for IACM workspaces, allowing for more seamless cross product data fusion.