Init container missing required environment variables when agent type is Deployment and TLS + mutual TLS (clientAuth) are enabled #309
Description
Init container missing required environment variables when agent type is Deployment and TLS + mutual TLS (clientAuth) are enabled
Description
When deploying the CrowdSec Helm chart with the agent type set to Deployment and both tls.enabled and tls.agent.tlsClientAuth set to true, the init container (wait-for-lapi) fails because it is missing mandatory environment variables.
This issue does not occur when the agent type is set to DaemonSet, since the DaemonSet template correctly defines the required environment variables for the init container.
As a result, the Deployment-based agent fails to connect to the LAPI during startup and loops indefinitely while waiting for it to become available.
Steps to Reproduce
-
Deploy the Helm chart with the following configuration:
agent: isDeployment: true tls: enabled: true agent: tlsClientAuth: true -
Observe that the init container (
wait-for-lapi) in the agent deployment logs repeatedly show:waiting for lapi to start -
Inspect the generated pod manifest — the
LAPI_HOSTandLAPI_PORTenvironment variables are missing from the init container definition.
Root Cause
In the Deployment template, the environment variables for the init container are conditionally wrapped inside:
{{- if or (not .Values.tls.enabled) (not .Values.tls.agent.tlsClientAuth) }}
This condition causes all environment variables — including the mandatory LAPI_HOST and LAPI_PORT — to be omitted when both TLS and mutual TLS (clientAuth) are enabled.
However, in the DaemonSet template, the LAPI_HOST and LAPI_PORT variables are defined outside this conditional block, ensuring they are always present regardless of TLS configuration.
Proposed Fix
Update the Deployment template to follow the same logic as the DaemonSet template, ensuring that LAPI_HOST and LAPI_PORT are always defined, even when TLS and clientAuth are enabled.
Corrected snippet:
env:
{{- if or (not .Values.tls.enabled) (not .Values.tls.agent.tlsClientAuth) }}
- name: REGISTRATION_TOKEN
valueFrom:
secretKeyRef:
name: {{ include "lapi.secretName" . }}
key: {{ include "lapi.registrationTokenKey" . }}
- name: USERNAME
valueFrom:
fieldRef:
fieldPath: metadata.name
- name: LAPI_URL
value: "{{ .Values.agent.lapiURL | default (printf "http://%s-service.%s:8080" .Release.Name .Release.Namespace) }}"
{{- end }}
- name: LAPI_HOST
value: "{{ .Values.agent.lapiHost | default (printf "%s-service.%s" .Release.Name .Release.Namespace) }}"
- name: LAPI_PORT
value: "{{ .Values.agent.lapiPort | default "8080" }}"
This ensures consistent behavior between both agent modes (Deployment and DaemonSet).
Expected Behavior
When the agent is deployed as a Deployment and both tls.enabled and tls.agent.tlsClientAuth are true, the init container should correctly define LAPI_HOST and LAPI_PORT to allow it to connect to and register with the LAPI instance.
Environment
| Component | Version |
|---|---|
| Helm Chart | 0.20.1 |
| CrowdSec | 1.7.0 |
| Kubernetes | 1.33.2 |
| Deployment method | FluxCD / HelmRelease |
Additional Context
-
The issue only occurs under the following conditions:
agent.isDeployment: true tls.enabled: true tls.agent.tlsClientAuth: true -
When using
DaemonSetas agent kind, the template correctly includes all the required env vars.