lars.bilek
10/08/2026, 12:24 PMkapa.ai
10/08/2026, 12:24 PMhostAliases into temporary job/workload pods (such as check pods) via the Airbyte Helm chart or environment variables.
In the Helm chart and configuration, dynamic workload/job pods support a limited set of customizations under global.jobs.kube, such as:
• annotations (JOB_KUBE_ANNOTATIONS / CHECK_JOB_KUBE_ANNOTATIONS) [Configuring Airbyte; Jobs-specific]
• labels (JOB_KUBE_LABELS) [Helm chart issue; Helm chart broken]
• nodeSelector (JOB_KUBE_NODE_SELECTORS / CHECK_JOB_KUBE_NODE_SELECTORS) [Jobs-specific; Upgrade to Helm chart V2]
• tolerations (JOB_KUBE_TOLERATIONS) [Configuring Airbyte]
There is no native Helm value or environment variable documented for passing hostAliases to dynamically spawned pods [Privilege escalation].
Potential Workaround When fields are not natively supported on dynamically generated pods (which are created with labels like airbyte: job-pod and job_type: check), community members typically use a Kubernetes Mutating Admission Webhook (such as Kyverno or Gatekeeper) to intercept and patch the pod manifest before it is scheduled [Container orchestrator ignores; Privilege escalation].
For example, using a Kyverno ClusterPolicy, you can inject hostAliases onto matching pods:
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: inject-hostaliases-airbyte-jobs
spec:
rules:
- name: add-host-aliases
match:
any:
- resources:
kinds:
- Pod
namespaces:
- airbyte # Update to your Airbyte namespace
selector:
matchLabels:
airbyte: job-pod
mutate:
patchStrategicMerge:
spec:
hostAliases:
- ip: "192.168.1.10"
hostnames:
- "custom-source-host.local" 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.