Configure Pod security contexts

Astronomer Software 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.

You can set up security contexts at a Pod-level scope or configure more specific security contexts at the container level. 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.

Prerequisites

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

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

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.

1
astronomer:
2
    securityContext:
3
        runAsNonRoot: true

Component configuration

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

1
<software-component>:
2
    securityContext:

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

1
grafana:
2
    securityContext:
3
        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:

1
<software-component>:
2
    podSecurityContext: {}

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

1
astronomer:
2
    astro-ui:
3
        podSecurityContext:
4
            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, all containers defined in the Astronomer values.yaml file have the runAsUser configuration overrides the Commander-specific Pod security context, runAsNonRoot.

1
astronomer:
2
    securityContexts:
3
        container:
4
            runAsUser: 1001
5
    commander:
6
        podSecurityContext:
7
            runAsNonRoot: true
8
            fsGroup: 50000

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

1
spec:
2
    securityContext:           # Pod level - defaults for all containers
3
        runAsNonRoot: true
4
        fsGroup: 5000
5
    containers:
6
    - name: app
7
        securityContext:         # Container level - overrides pod defaults
8
            runAsUser: 1001        # Overrides pod setting

Example: Add privileged access

By default, the Astronomer Software 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.

1
nginx:
2
    securityContext:
3
        capabilities:
4
            drop:
5
            - ALL
6
            add:
7
            - NET_BIND_SERVICE
8
        allowPrivilegeEscalation: true