Request to add `SecretReference` support for the `serviceUri` field in `ActionGroup` `WebhookReceiver` to enable secure management of webhook URIs containing sensitive credentials (API keys, tokens)

[pkum83]

Describe the current behavior

The WebhookReceiver.serviceUri field currently only accepts a plain string type, requiring sensitive authentication credentials to be embedded directly in the ActionGroup manifest:

apiVersion: insights.azure.com/v1api20230101
kind: ActionGroup
metadata:
  name: my-action-group
  namespace: monitoring
spec:
  webhookReceivers:
  - name: my-webhook
    # ❌ Sensitive API key exposed in plain text
    serviceUri: "https://api.example.com/webhook?apiKey=super-secret-key-133&token=xyz289"

Describe the improvement

Add SecretReference Support (Preferred)

Allow serviceUri to accept either a string OR a SecretReference, maintaining backward compatibility:

apiVersion: insights.azure.com/v1api20230101
kind: ActionGroup
metadata:
  name: my-action-group
  namespace: monitoring
spec:
  webhookReceivers:
  - name: my-webhook
    # ✅ New: Reference a Kubernetes Secret
    serviceUri:
      name: webhook-credentials
      key: uri
    # OR maintain backward compatibility
    # serviceUri: "https://direct-url.com"  # Still works

With the corresponding Secret:

apiVersion: v1
kind: Secret
metadata:
  name: webhook-credentials
  namespace: monitoring
type: Opaque
stringData:
  uri: "https://api.example.com/webhook?apiKey=super-secret-key-123"

Option 2: Component-Based SecretReference

Alternatively, support separate SecretReferences for URI components:

apiVersion: insights.azure.com/v1api20230101
kind: ActionGroup
spec:
  webhookReceivers:
  - name: my-webhook
    serviceUri:
      baseUrl: "https://api.example.com/webhook"
      queryParams:
        apiKey:
          secretRef:
            name: webhook-credentials
            key: api-key
        token:
          secretRef:
            name: webhook-credentials
            key: token

Additional context

ASO already has established patterns for SecretReference in other resources like StorageAccount

Environment

• ASO Version: v2.x (all versions)
• Kubernetes Version: 1.25+
• Azure API Version: insights/2023-01-01

[theunrepentantgeek]

Our usual approach for properties like this is to explicitly mark the property as a secret and accept the breaking change, on the precept that secrets should never be held in plain YAML files.

But this property is a little different - because it's not always a secret. In fact, the presence of secrets in the URL is likely to be the exception, not the rule.

We need to do some design work to make sure we solve this properly.

[matthchr]

We discussed this in our weekly triage meeting and agree that we can improve this by allowing the user to pass a secret via an additional property (similar to your option 1 w/ back-compat).

One thing we should double-check is that there are cases where this isn't a secret. If the 90-95% case is that this value contains a secret, we could consider just taking a breaking change.