Configure Pod security contexts

Customize the podSecurityContext or containerSecurityContext on Astro Private Cloud.

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.

Prerequisites

• Systems admin permission level, to make changes to the Astronomer Helm chart

For OpenShift users, some configurations for security contexts are incompatible with OpenShift operations. When you configure container and Pod security contexts, you must ensure that the configurations you select are compatible with OpenShift. For example, if you have

openshiftEnabled: true

configured, you cannot use a configuration like

fsGroup: 1000

because OpenShift does not allow users to run non-standard UID’s.

Configure securityContext

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.

astro-ui, commander, houston, configsyncer, and registry container configuration [#container-config]

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.

astronomer:
    securityContext:
        runAsNonRoot: true

Component configuration

For all other Astro Private Cloud components, you must define the container security context using the securityContext parameter.

<software-component>:
    securityContext:

For example, the following code example configures containers in the Grafana component to run as non-root users:

grafana:
    securityContext:
        runAsNonRoot: true

Configure podSecurityContext

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:

<software-component>:
    podSecurityContext: {}

For example, you can configure the podSecurityContext for the Astro UI (astro-ui) with the following:

astronomer:
    astro-ui:
        podSecurityContext:
            fsGroup: 50000

Test security context presence

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:

kubectl -n astronomer get pods -o json | jq -r \
  '.items[] | "\(.metadata.name)\t\(
    if .spec.securityContext then "HAS_SECURITY_CONTEXT" else "MISSING_SECURITY_CONTEXT" end
  )"' | column -t

Best Practice recommendation

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.

astronomer:
    securityContexts:
        container:
            runAsUser: 1001
    commander:
        podSecurityContext:
            runAsNonRoot: true
            fsGroup: 50000

This produces a Pod manifest for the Commander component with the following definitions:

spec:
    securityContext:           # Pod level - defaults for all containers
        runAsNonRoot: true
        fsGroup: 50000
    containers:
    - name: commander
        securityContext:         # Container level - overrides pod defaults
            runAsUser: 1001        # Overrides pod setting

Configure Pod Security Admission

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.

Enable Pod Security Admission

To enable PSA for Deployment namespaces, add the following label configuration to your values.yaml file:

global:
  namespaceLabels:
    pod-security.kubernetes.io/enforce: "baseline"

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.

Example: Add privileged access

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.

nginx:
    securityContext:
        capabilities:
            drop:
            - ALL
            add:
            - NET_BIND_SERVICE
        allowPrivilegeEscalation: true