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.
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 Astronomer Software 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
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 Software 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, all containers defined in the Astronomer values.yaml
file have the runAsUser
configuration overrides the Commander-specific Pod security context, runAsNonRoot
.
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: 5000
containers:
- name: app
securityContext: # Container level - overrides pod defaults
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.
nginx:
securityContext:
capabilities:
drop:
- ALL
add:
- NET_BIND_SERVICE
allowPrivilegeEscalation: true