Astro Private Cloud platform components support granular security contexts by using the component Helm values. These configurations apply security policies, like runAsNonRoot or dropping capabilities, across an entire Pod or in a specific container. When you configure these settings to meet your organization’s security requirements, it allows you to add elevated permissions to particular components. Or, you can use validation tooling like Gatekeeper or Kyverno without manual overrides.
The Pod security context provides the defaults for the component’s containers. If you set a container security context, it overrides the defaults you configure for the pod-level, allowing you to customize the behavior of your components.
Kubernetes security contexts have different fields depending on whether you apply them at the container-level, with the Astronomer securityContext, or at the Pod-level, with the Astro Private Cloud podSecurityContext. If you configure both the securityContext and podSecurityContext, the container-level definitions take precedence.
Read more about SecurityContext and podSecurityContext in the Kubernetes documentation.
openshiftEnabled: true configured, you cannot use a configuration like fsGroup: 1000 because OpenShift does not allow users to run non-standard UID’s.To see possible configuration options per component, refer to the Helm chart config reference. These configurations must be made per-component, and not globally. However there is a sub-set of components that can be configured simultaneously.
You can simultaneously configure the security context for containers in the astro-ui, commander, houston, configsyncer, and registry components by updating the astronomer.securityContext parameter. The following example configures all containers in these components to run as a non-root user.
For all other Astro Private Cloud components, you must define the container security context using the securityContext parameter.
For example, the following code example configures containers in the Grafana component to run as non-root users:
To see possible configuration options per component, refer to the Helm chart config reference. podSecurityContext configurations must be made per-component, and not globally. In general, the configuration structure follows the pattern in this example:
For example, you can configure the podSecurityContext for the Astro UI (astro-ui) with the following:
You can confirm which components have security contexts applied by running the following query in your environment to produce a list of components and their security context status:
Astronomer recommends that you set security contexts only when you need to comply with security policies and requirements. If you apply security contexts, Astronomer recommends using pod-level security context for common settings, and container-level for specific overrides. For example, the following configuration shows how to configure Pod-level and container-level security contexts for the Commander component. In this example, the container-level runAsUser setting defined in Astronomer’s values.yaml (under astronomer.securityContexts.container) overrides the Commander component’s Pod-level runAsNonRoot setting.
This produces a Pod manifest for the Commander component with the following definitions:
Starting in APC 1.1, you can use Kubernetes Pod Security Admission (PSA) to enforce Pod Security Standards at the namespace level and prevent privileged Pod creation in your Airflow Deployment namespaces.
Astro Private Cloud supports the baseline Pod Security Standard. Astro Private Cloud does not support the restricted standard.
Before you enable PSA, verify that your Dags and custom workloads don’t require privileged containers or elevated permissions. Kubernetes rejects Pods that violate the security standard.
To enable PSA for Deployment namespaces, add the following label configuration to your values.yaml file:
This configuration adds PSA labels to all namespaces that Astro Private Cloud creates, enforcing the baseline security standard. For information about PSA modes and gradual rollout strategies, see Pod Security Admission in the Kubernetes documentation.
By default, the Astro Private Cloud install does not require elevated privileges. This means that the Software container ports are limited to 1024 or greater by default. If you need your install to have exceptions for privileged access, you can update the controller settings in the Helm configs.yaml file by using the following container security context definition.