Feature Requests

The KMS connector only accepts KMS AR stored in Harness Secret Manager. We need an ability to pull those ARN from AWS secret manager.

The custom measures created in the Dashboard Visuzlizations cannot be added and graphed in the Visializations. Only the predefined metrics could be graphed. Could you please allow to add them as well as the predefined ones?

As of today, the AWS KMS Connector in Harness does not support the sign/verify use case. Currently, being a secret manager connector, it only supports encryption and decryption.

Currently, the platform assumes a standard client ID for OAuth, which cannot be customized. It would be beneficial to have the ability to configure a custom client ID, similar to other software vendors like Harbor. This feature would enhance flexibility and integration capabilities with different OAuth providers.

I would like to have the alerting feature integrated with external alerting engines, webhooks, or teams. This integration would enhance our ability to manage alerts more effectively by allowing us to use our existing systems and workflows.

I need a feature that allows us to control who can use account-level delegates in specific projects without having to explicitly grant permissions. This would help in managing access more efficiently and prevent unauthorized usage of delegates.

I would like the ability to send data to HEC forwarders or other streams beyond the current options of GCP, AWS, and Splunk. Expanding the range of supported streams would enhance flexibility and integration capabilities.

This stemmed from our conversation with our Cybersecurity Team asking us to prove how we are restricting access to KMS while using CoSign. Situation: From out understanding, at the moment, if users at the project level decided to write their own signing step to access our account level delegates, they could grab our KMS private key and verify and sign artifacts/evidence. This is not only for KMS but for other features in AWS like AWS Secret. At the moment, there is nothing preventing users at the project level from using our account level delegates to grab our AWS account level services.

We need to have mTLS implemented on API calls, not just Delegates. Currently, mTLS is supported for the Delegate only, this is a feature request to extend mTLS support for API calls.

The PEM key secret is currently required to be stored in the built-in Harness secret manager. Please add support for storing it in the Vault secret manager.