Feature Requests

We need to update specific labels/annotations in the delegate. The values are not exposed via the value file: https://github.com/harness/delegate-helm-chart/blob/1392fd3ac5c6334db529f06554fbbe6fdc4f0146/harness-delegate-ng/templates/_helpers.tpl#L44-L48 We need another setting in the values.yaml file so we can add to those tags. We are trying to add the labels and annotations shown here: https://app.datadoghq.com/apm/service-setup?architecture=container-based&collection=Helm%20Chart%20%28Recommended%29&environment=kubernetes&language=java

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.

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 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.