Official Helm Chart version

1.18.0 (latest released)

Apache Airflow version

3.0.6

Kubernetes Version

1.33.5

Helm Chart configuration

executor: KubernetesExecutor
scheduler:
  serviceAccount:
    automountServiceAccountToken: false
  extraVolumes:
    - name: sa-token
      projected:
        defaultMode: 420
        sources:
          - serviceAccountToken:
              expirationSeconds: 3607
              path: token
          - configMap:
              items:
                - key: ca.crt
                  path: ca.crt
              name: kube-root-ca.crt
          - downwardAPI:
              items:
                - fieldRef:
                    apiVersion: v1
                    fieldPath: metadata.namespace
                  path: namespace
  extraVolumeMounts:
    - name: sa-token
      mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      readOnly: true
apiServer:
  serviceAccount:
    automountServiceAccountToken: false
dagProcessor:
  serviceAccount:
    automountServiceAccountToken: false
migrateDatabaseJob:
  serviceAccount:
    automountServiceAccountToken: false
statsd:
  serviceAccount:
    automountServiceAccountToken: false
triggerer:
  serviceAccount:
    automountServiceAccountToken: false
workers:
  serviceAccount:
    automountServiceAccountToken: false

Docker Image customizations

none

What happened

The rendered Kubernetes resources for the Scheduler service account should contain the following property:

apiVersion: v1
kind: ServiceAccount
automountServiceAccountToken: false

The rendered Kubernetes resources for the Scheduler deployment should contain the following property:

apiVersion: apps/v1
kind: Deployment
spec:
  template:
    spec:
      automountServiceAccountToken: false

Both properties are missing. This conflicts with my present Kyverno policies:

• https://github.com/kyverno/policies/raw/main/other/restrict-automount-sa-token/restrict-automount-sa-token.yaml
• https://github.com/kyverno/policies/raw/main/other/restrict-sa-automount-sa-token/restrict-sa-automount-sa-token.yaml

What you think should happen instead

In the Helm chart templates for the Scheduler service account and deployment the Value for .Values.scheduler.serviceAccount.automountServiceAccountToken is only evaluated when the executor is set to "CeleryExecutor". For the executor "Kubernetes" this is ignored. There is no way to disable the automount service account token when using the Kubernetes executor.

I would expect, that the property is also respected for the Scheduler as for the other workloads. As the Scheduler needs such a service account token, I have the option to manually provide a corresponding volume mount and the Helm chart comes with a default volume mount, when automountServiceAccountToken: false and no custom volume mount for this is defined. Something like:

scheduler:
  serviceAccount:
    automountServiceAccountToken: false
  serviceAccountTokenSpec:
    defaultMode: 420
    sources:
      - serviceAccountToken:
          expirationSeconds: 3607
          path: token
      - configMap:
          items:
            - key: ca.crt
              path: ca.crt
          name: kube-root-ca.crt
      - downwardAPI:
          items:
            - fieldRef:
                apiVersion: v1
                fieldPath: metadata.namespace
              path: namespace

How to reproduce

Deploy the Helm chart in a Kubernetes cluster with Kyverno policies restrict-automount-sa-token and restrict-sa-automount-sa-token (or similiar policy frameworks). Use the "Kubernetes" executor and try to disable automountServiceAccountToken for all workloads.

Anything else

The feature to disable service account token automounting was introduced with issue 30722 (PR 32808). There was a subsequent issue 43464 (PR 44173) that introduced the special handling for the Celery Executor and disabled the feature for the Kubernetes executor completely.

In the PR 44173, there is a suggested workaround that would have fixed the issue as well, in a more flexible way.

Are you willing to submit PR?

• Yes I am willing to submit a PR!

Code of Conduct

• I agree to follow this project's Code of Conduct