Support for injecting custom environment variables via values.yaml

[barucijah]

Describe the current behavior

The current Helm chart for AzureServiceOperator does not support passing additional environment variables to the operator container via values.yaml. This limits flexibility when users want to configure runtime environment variables such as DD_ENV, DD_SERVICE, HTTP_PROXY, or any other application-specific settings.

Describe the improvement

Enhance the Helm chart by adding support for an optional extraEnv field in values.yaml, allowing users to define custom environment variables that will be injected into the main container of the Deployment.

Additional context

This change would not affect existing users, as extraEnv would be optional. It provides an easy and idiomatic Helm-based mechanism to extend configuration without forking the chart or patching the rendered manifests externally.

[theunrepentantgeek]

Can you expand on your use case here? Since the ASO pod won't be looking for environment variables like DD_ENV or DD_SERVICE we're not sure why specifying those would be useful.

We're not opposed to making the change but want to understand the desired scenarios first.

[barucijah]

Thanks for the clarification, I am happy to elaborate.
@theunrepentantgeek

In my case, I need to inject environment variables dynamically into the pod based on its metadata — specifically labels like environment name, service name, and version. This is essential for Datadog monitoring and tagging, where variables like DD_ENV, DD_SERVICE, and DD_VERSION must align with the pod's current metadata to ensure accurate telemetry, log correlation, and environment scoping.

Since these values can vary per deployment and are managed through Kubernetes labels, I can't rely on static key-value pairs via a ConfigMap. Instead, I need to use valueFrom with fieldRef in the env section of the Pod spec. For example:

env:
  - name: DD_ENV
    valueFrom:
      fieldRef:
        fieldPath: metadata.labels['tags.datadoghq.com/env']
  - name: DD_SERVICE
    valueFrom:
      fieldRef:
        fieldPath: metadata.labels['tags.datadoghq.com/service']
  - name: DD_VERSION
    valueFrom:
      fieldRef:
        fieldPath: metadata.labels['tags.datadoghq.com/version']

This approach ensures the injected environment variables are always consistent with the pod's metadata, without needing to hardcode or maintain separate ConfigMaps per environment or service.

Let me know if you’d like a concrete example or if I can help test compatibility with ASO in this context.

You can also check my PR for this issue, #4745

[theunrepentantgeek]

Thanks for the contribution, we've merged your PR.