This is a blog with random OpenStack and Linux related notes so I don't forget things. If you find something inaccurate or that could be fixed, please file a bug report here.

View on GitHub

Back to home

20 September 2019

Integrating Udica into the Kubernetes workflow

by Juan Antonio Osorio Robles

In a previous blog post I explained about how to set up the SELinux labels for your workloads in Kubernetes and how Udica could be used to generate SELinux policies for your containers. In the end, I hinted at a way to integrate udica into your regular kubernetes development workflow. Here I present work that I did recently on this area.


As a developer creating SELinux policies in “cloud-native” workloads should be as simple as possible. One should just annotate their pod manifest and get an appropriate policy for it. The least manual steps that developers should do the better. This is not to say that folks shouldn’t know how to generate policies themselves, or that they shouldn’t know SELinux. They should, and hopefully teams will have someone with security knowledge. However, if we can make the barrier of entry and the development process smoother, this is a win on the security side.

As a deployer I’d like to restrict the usage of privileged containers to be as minimal as possible. So, the hope is that with an easier workflow, folks will generate policies for their workloads instead of deploying them as privileged.


I’ve created a POC that’s automates the creation of policies for your workloads. Here’s the link:


selinux-policy-helper-operator listens to pods in the kubernetes cluster. If the pod is annotated with the “generate-selinux-policy” label, it’ll generate a config for it and upload it to a config map.

So, your pod will need to have an annotation as the following:

apiVersion: v1
kind: Pod
  name: errorlogger
    generate-selinux-policy: ""

And here’s the operator in action:

This operator uses udica to genenerate the aforementioned policy. Currently, the udica from the pod has a set of additions:

The pod that’s launched by the operator runs a script that calls the CRI to get the information from the requested pod and pass that down to udica, finally, this pod creates a configmap with the policy. That code is here:


This removes the need of having to run manual commands and makes it simpler for udica to be part of the developer’s CI workflow.

Not that this doesn’t remove the need to review your policy for several reasons:


This covers the work of automating and making it easier to generate policies for your workloads. There are still several features to add. PRs are welcome!

Further work

We still need better and friendlier ways to manager policies in our clusters, make sure we can install/uninstall these policies, and optionally restrict who can use which policy. Work on this is coming.

tags: openshift - udica - kubernetes - k8s - selinux

Back to home