> ## Documentation Index
> Fetch the complete documentation index at: https://astronomer.io/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Configure Pod security contexts

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.

<Warning>
  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`](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.33/#securitycontext-v1-core) and [podSecurityContext](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.33/#podsecuritycontext-v1-core) in the Kubernetes documentation.
</Warning>

## Prerequisites

* [Systems admin](/docs/astro-private-cloud/v-1-x/role-permission-reference#system-admin) permission level, to make changes to the Astronomer Helm chart

<Warning>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.</Warning>

## Configure securityContext

To see possible configuration options per component, refer to the [Helm chart config reference](/docs/astro-private-cloud/v-1-x/helm-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.

<a id="container-config" />

### 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.

```yaml wrap theme={null}
astronomer:
    securityContext:
        runAsNonRoot: true
```

### Component configuration

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

```yaml wrap theme={null}
<software-component>:
    securityContext:
```

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

```yaml wrap theme={null}
grafana:
    securityContext:
        runAsNonRoot: true
```

## Configure podSecurityContext

To see possible configuration options per component, refer to the [Helm chart config reference](/docs/astro-private-cloud/v-1-x/helm-config-reference). `podSecurityContext` configurations must be made per-component, and not globally. In general, the configuration structure follows the pattern in this example:

```yaml wrap theme={null}
<software-component>:
    podSecurityContext: {}
```

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

```yaml wrap theme={null}
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:

```bash wrap theme={null}
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.

```yaml wrap theme={null}
astronomer:
    securityContexts:
        container:
            runAsUser: 1001
    commander:
        podSecurityContext:
            runAsNonRoot: true
            fsGroup: 50000

```

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

```yaml wrap theme={null}
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](https://kubernetes.io/docs/concepts/security/pod-security-admission/) (PSA) to enforce [Pod Security Standards](https://kubernetes.io/docs/concepts/security/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.

<Warning>
  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.
</Warning>

### Enable Pod Security Admission

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

```yaml wrap theme={null}
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](https://kubernetes.io/docs/concepts/security/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.

```yaml wrap theme={null}
nginx:
    securityContext:
        capabilities:
            drop:
            - ALL
            add:
            - NET_BIND_SERVICE
        allowPrivilegeEscalation: true
```