Is it possible to have a Kubernetes cluster with privileged pods by default?

2/1/2019

I'm creating a pod through the KubernetesPodOperator in Airflow. This pod should mount a Google Cloud Storage to /mnt/bucket using gcsfuse. For this, the pod is required to be started with the securityContext parameter, such that it can become 'privileged'.

It is currently not possible to pass the securityContext parameter through Airflow. Is there another way to work around this? Perhaps by setting a 'default' securityContext before the pods are even started? I've looked at creating a PodSecurityPolicy, but haven't managed to figure out a way.

-- bartcode
airflow
kubernetes

2 Answers

2/3/2019

A mutating admission controller would allow you to do that: https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook

The ibm-cloud team has a post about it, but I've never tried writing one: https://medium.com/ibm-cloud/diving-into-kubernetes-mutatingadmissionwebhook-6ef3c5695f74 and the folks at GiantSwarm have an end-to-end example using their Grumpy admission controller: https://docs.giantswarm.io/guides/creating-your-own-admission-controller/

I would use the labels, or annotations, or maybe even the image, to identify Pods launched by Airflow, and then mutate only them to set the securityContext: on the Pods to be the way you want.

-- mdaniel
Source: StackOverflow

2/3/2019

Separate from the Mutating Admission Controller, it's also possible to deploy a DaemonSet into your cluster that mounts /mnt/bucket onto the host filesystem, and the the Airflow pods would use {"name": "bucket", "hostPath": {"path": "/mnt/bucket"}} as their volume:, which -- assuming it works -- would be a boatload less typing, and also not run the very grave risk of a Mutating Admission Controller borking your cluster and causing Pods to be mysteriously mutated

-- mdaniel
Source: StackOverflow