dan-osterrath commented on code in PR #59156: URL: https://github.com/apache/airflow/pull/59156#discussion_r2602324421
########## chart/docs/index.rst: ########## @@ -81,6 +82,12 @@ Features * Supported database backend: ``PostgreSQL``, ``MySQL`` * Autoscaling for ``CeleryExecutor`` provided by KEDA * ``PostgreSQL`` and ``PgBouncer`` with a battle-tested configuration +* **Security enhancements**: + + * Manual Service Account Token Volume configuration for pod-launching executors + * Defense-in-depth security with both ServiceAccount and Pod-level controls + * Compatibility with security policies like Kyverno + Review Comment: I've introduced a newsfragment for now. ########## chart/docs/production-guide.rst: ########## @@ -703,3 +703,225 @@ this behavior is deprecated in favor of explicitly defining ``.Values.imagePullS You can read more about advanced ways of setting configuration variables in the :doc:`apache-airflow:howto/set-config`. + +Service Account Token Volume Configuration +------------------------------------------ + +When using pod-launching executors (``CeleryExecutor``, ``CeleryKubernetesExecutor``, ``KubernetesExecutor``, ``LocalKubernetesExecutor``), +you can configure how Kubernetes service account tokens are mounted into pods. This provides enhanced security control +and compatibility with security policies like Kyverno. + +Background +^^^^^^^^^^ + +By default, Kubernetes automatically mounts service account tokens into pods via the ``automountServiceAccountToken`` setting. +However, for security reasons, you might want to disable automatic mounting and manually configure service account token volumes instead. + +This feature addresses Bug #59099 where ``scheduler.serviceAccount.automountServiceAccountToken: false`` was ignored +when using the KubernetesExecutor. The solution implements a defense-in-depth approach with both ServiceAccount-level +and Pod-level controls. + +Container-Specific Security +^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The Service Account Token Volume is mounted **only** in containers that require Kubernetes API access, implementing the +**Principle of Least Privilege**: + +* **Scheduler Container**: Receives Service Account Token (needs API access for pod management) +* **Init Container "wait-for-airflow-migrations"**: No Service Account Token (only performs database migrations) +* **Sidecar Container "scheduler-log-groomer"**: No Service Account Token (only performs log cleanup operations) + +This container-specific approach ensures that: + +- **Database Migration Container**: Only accesses the database for schema updates, no Kubernetes API access required +- **Log Groomer Container**: Only performs filesystem operations for log cleanup, no API access required +- **Scheduler Container**: Requires API access for launching and managing pods with pod-launching executors + +**Security Benefits:** + +* **Reduced Attack Surface**: Containers without API access cannot interact with the Kubernetes API even if compromised +* **Compliance**: Meets security policy requirements that mandate minimal privilege assignment +* **Audit Trail**: Clear separation of which containers have API access for security auditing +* **Defense-in-Depth**: Multiple layers of security controls at both ServiceAccount and container levels + +Configuration Options +^^^^^^^^^^^^^^^^^^^^^ + +The service account token volume configuration is available for the scheduler component and includes the following options: + +.. code-block:: yaml + + scheduler: + serviceAccount: + automountServiceAccountToken: false # Disable automatic token mounting + serviceAccountTokenVolume: + enabled: true # Enable manual token volume + mountPath: /var/run/secrets/kubernetes.io/serviceaccount # Mount path for the token + volumeName: kube-api-access # Name of the projected volume + expirationSeconds: 3600 # Token expiration time in seconds + audience: ~ # Token audience (optional) + +Security Implications +^^^^^^^^^^^^^^^^^^^^^ + +**When to use manual token volumes:** + +* When security policies require explicit control over service account token mounting +* When using security policy engines like Kyverno that restrict automatic token mounting +* When implementing defense-in-depth security strategies +* When you need custom token expiration times or audiences +* When compliance frameworks mandate container-specific privilege assignment + +**Security benefits:** + +* **Explicit control**: Manual configuration makes token mounting intentional and visible +* **Policy compliance**: Compatible with security policies that restrict ``automountServiceAccountToken: true`` +* **Defense-in-depth**: Provides both ServiceAccount-level and Pod-level security controls +* **Custom expiration**: Allows setting shorter token lifetimes for enhanced security +* **Container isolation**: Only scheduler container receives API access, reducing attack surface +* **Principle of Least Privilege**: Each container receives only the minimum required permissions + +**Why Init and Sidecar Containers Don't Need API Access:** + +* **Init Container (wait-for-airflow-migrations)**: + + - **Purpose**: Performs database schema migrations using ``airflow db migrate`` + - **Required Access**: Database connection only + - **Security Rationale**: Database operations don't require Kubernetes API interaction + +* **Sidecar Container (scheduler-log-groomer)**: + + - **Purpose**: Cleans up old log files from the filesystem + - **Required Access**: Local filesystem access only + - **Security Rationale**: Log cleanup is purely filesystem-based, no API calls needed + +* **Scheduler Container**: + + - **Purpose**: Manages DAG scheduling and launches task pods + - **Required Access**: Kubernetes API for pod creation, monitoring, and cleanup + - **Security Rationale**: Pod-launching executors require API access for container orchestration + +Use Cases and Examples Review Comment: done -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
