Feature Requests

Request: Provide a unified HAR authentication flow: one CLI login (using harness auth login --sso) stores a HAR-compatible user credential in the native OS credential store, and HAR config configures package-manager-specific integrations that reference that single credential. Expected Behavior: Reuse an active Harness browser session during login when security policy permits, avoiding redundant sign-in. Store the credential in macOS Keychain, Windows Credential Manager, or Linux Secret Service, with no plaintext fallback. Automatically configure supported credential integrations for pnpm, pip, Docker, and other package managers. Ordinary package-manager commands should work without token exports, plaintext credentials, or a CLI execution wrapper. Allow developers to configure only the registries and package types they need, all referencing the shared credential. Apply credential rotation across integrations. Removing a registry configuration must not delete the shared credential; explicit logout should remove it. Preserve existing HAR permissions and clearly document package-manager limitations, including npm’s lack of a native credential-helper hook. Benefit: One login enables secure, consistent access across permitted HAR registries, with minimal manual setup.

I am trying to set up a Harness SMP cluster. While the business side (Leidos) is working out licensing details, I'd like to request credentials to access the harnesssecure repository to complete my POC installation of Harness SMP.

We need HAR to proxy release artifacts hosted on a GitHub Enterprise instance that requires authentication. Current authentication methods available in HAR do not allow the proper use of a GitHub PAT.

The cleanup policy currently allows specifying the number of versions to retain through the Cleanup Rule, while the Retention Rule allows defining tag patterns but does not provide an option to specify the number of versions to retain. The requested enhancement is to support independent retention counts for production and non-production versions. For example: Cleanup Rule: Retain the latest 5 non-production versions (versions not matching . prod. ) Retention Rule: Retain the latest 5 production versions (versions matching . prod. ) This would ensure that the registry independently retains the latest 5 production and 5 non-production versions.

Overview The Dependency Firewall dashboard "double-counts" blocked violations for the same package version within a single execution. This is particularly prevalent when using virtual registries (e.g., npm_local_account_level) configured with an upstream proxy (e.g., npm-upstream-proxy). The dashboard logs separate events for the fetch attempt at the proxy level and the subsequent CLI dependency graph evaluation. The Problem The duplication is triggered by the multi-phase evaluation flow in the Harness CLI: The Registry Context: The package is requested through a virtual registry (npm_local_account_level) that proxies to an upstream source. Native Fetch Pass: When npm install requests the tarball directly from the upstream proxy, the firewall returns a 403 Forbidden. This is logged as a violation. CLI Fallback Pass: If a lockfile is missing, the CLI resolves the full tree and bulk-submits the package (e.g., registry-url@7.2.0) for evaluation again. This is logged as a second violation. Because the dashboard does not deduplicate by registry or execution ID, one actual policy hit appears as two separate security events. Customer Impact Metric Inflation: Customers see inflated violation counts, making it difficult to assess the true volume of blocked packages. Registry Ambiguity: Without deduplication, it isn't always clear that multiple dashboard entries refer to the same package being pulled through the same virtual registry endpoint. Operational Noise: Security teams spend unnecessary time triaging "duplicate" hits that stem from the same single user action. Proposed Solution Update the Dependency Firewall reporting logic to deduplicate entries. The dashboard should group violations by: Package Name & Version Target Registry (to ensure legitimate violations across different registries are still caught) Execution/Pipeline ID If a package is blocked multiple times while being pulled from the same registry during the same pipeline run, it should render as a single dashboard entry.

Our requirement is to have a Yarn equivalent of the existing npm command: hc artifact npm install Specifically, we are looking for support for: hc artifact yarn install The objective is to standardize dependency installation in our Harness pipelines and ensure that Yarn dependencies are resolved through the Harness Artifact Registry and Dependency Firewall during the install process.

Context: Currently, Harness Lifecycle Rules perform a "soft deletion" of artifacts, moving them to a Deleted tab within the Artifact Registry rather than removing them permanently. Problem: The Deleted tab lacks a UI option to perform permanent deletions in bulk. For users managing large registries with numerous soft-deleted artifacts, cleaning them up requires significant manual effort, as each must be handled individually. Proposed Solution: Introduce a Bulk Permanent Delete option under the Deleted tab. This would allow users to select multiple soft-deleted artifacts and remove them permanently from the registry in a single action. Benefit: This enhancement would significantly simplify artifact lifecycle management, reduce manual maintenance toil, and streamline registry cleanup for large-scale environments.

Hello Harness Support, We are trying to configure an Jfrog Artifactory connector using OIDC authentication in Harness. We are receiving the following message: This feature is behind the feature flag CDS_ARTIFACTORY_OIDC_AUTHENTICATION. Contact Harness Support to enable the feature. Could you please enable the following feature flag for our Harness account? Feature Flag: CDS_ARTIFACTORY_OIDC_AUTHENTICATION Harness Account ID: YzRhNTgyNzEtNjIyZi00ND This is required for us to configure OIDC authentication with our JFrog Artifactory connector. Please let us know if you need any additional information. Thanks, Naveen

I am actually trying to trigger my Playwright Automation Test Cases from Harness where I don't see any image with Node JS + Playwright Tool + Python pre baked in the available images. I have to set them install for every run which would be cumbersome. If I can have a readily available image i can use it to save time . Can you please create one with asked tech stack ?

Module: Artifact Registry — Upstream Proxy Registry type affected: npm Problem: The current upstream proxy only supports Basic authentication or anonymous access. npm's registry API ( https://registry.npmjs.org/ ) requires Authorization: Bearer <token> for authenticated requests. Basic auth returns 401. Impact: Private scoped packages (e.g., @payloadcms/*) cannot be resolved through a Harness npm upstream proxy. Root cause: npm permanently revoked classic tokens in December 2025; only granular access tokens sent as Bearer tokens are supported. Requested feature: Either: A native Bearer token authentication type for upstream proxies, with the token stored in Harness Secret Manager, or A custom static Authorization header per upstream proxy, sourced from Harness Secret Manager.