Running Containers in OpenShift

OpenShift is Red Hat container application platform. It is based on Kubernetes and to keep things short we are going to call it a PaaS. The new OpenShift v3 represents a big bet by Red Hat to re-write the software entirely in Go and leverage Kubernetes. Indeed when you use OpenShift, you get a Red Hat distribution of Kubernetes plus the OpenShift functionalities around code deployment, automated builds and so on, that you are used to with a typical PaaS.

What stands out with OpenShift, and what Red Hat touts quite often is the focus on security.

I am not a security expert but when you look at Kubernetes and if you avoid the polemic around secrets, you will find that Kubernetes has a lot of nice security features. RBAC is now the default setup when you use kubeadm to bootstrap your cluster, network isolation can be enforced with network policies and Pods can be controlled very tightly with Pod security policies. Add to that the authentication mechanisms, TLS setup for all components and admission controls and it is looking like a pretty strong and secure system, at least to me.

But security sometimes comes at a price for early adopters. In OpenShift’s case, they use Kubernetes Pod security policies by default, they are called Security Context Constraints (i.e scc). The most visible aspect of using scc by default is that containers that run their processes as ROOT will not run in OpenShift.

So if you start with minishift and try to run a basic Docker image that does not specify a non ROOT user, then it will fail. This means quite sadly that currently our Bitnami images won’t run on OpenShift. While we are working on a long term fix, namely to use a non-privileged user in our Dockerfile, I am going to show you how to temporarily circumvent this issue.

Getting started with OpenShift using minishift

To get started with Openshift use minishift. It is a custom minikube , meaning it will start a virtual machine on your local desktop/laptop and in this VM, openshift (i.e k8s) will be setup. The client oc will also be easily configured as it is a wrapper around kubectl .

Download and start it like minikube (except that the default driver is xhyve so if you use Virtual Box…):


minishift start — vm-driver virtualbox

Setup the Openshift client oc in your shell:


$ minishift oc-env
export PATH=”/Users/sebgoa/.minishift/cache/oc/v1.5.0:$PATH”
# Run this command to configure your shell:
# eval $(minishift oc-env)
$ eval $(minishift oc-env)

Modify Security Context Constraints

To modify a scc you need to be an admin on Openshift, so login as the admin of your minishift (this just switches the k8s context):


oc login -u sysadmin:admin

Then edit the scc called anyuid:


oc edit scc anyuid

If you do not log in as the admin user, the RBAC rules in place will not let you edit the security constraints. Then add a users section that look like this:


users:
- system:serviceaccount:default:ci
- system:serviceaccount:ci:default
- system:serviceaccount:myproject:default

Basically you are letting the default service account in the myproject namespace run Pods whose containers run processes as any uid , including the ROOT user. Note that the myproject is the namespace that your regular user has access to. This was generated by minishift automatically, and you can find it in your k8s context with oc config view .

Switch back to minishift as a regular user ( oc config just like kubectl config ):


oc config use-context minishift

Create an Application Using a Container Running Process as ROOT

You are now ready to create an app using a container where the process runs as ROOT. You relaxed the pod security policy. This is not ideal as you should always use principles of least privilege. oc new-app looks a lot like kubectl run


oc new-app --name foobar \
--docker-image bitnami/mariadb \
--env MARIADB_ROOT_PASSWORD=root

And you now have a running Bitnami mariadb on OpenShift ( oc logs like kubectl logs :


$ oc logs foobar-1-zft17
Welcome to the Bitnami mariadb container
Subscribe to project updates by watching https://github.com/bitnami/bitnami-docker-mariadb
Submit issues and feature requests at https://github.com/bitnami/bitnami-docker-mariadb/issues
Send us your feedback at containers@bitnami.com
nami INFO Initializing mariadb
mariadb INFO ==> Configuring permissions…
mariadb INFO ==> Validating inputs…
mariadb INFO ==> Initializing database…
...<snip>

Conclusions

While you can circumvent the default security context constraints in OpenShift, this is not ideal. That’s why at Bitnami we are now working to modify our container application templates to harden them and ensure they work nicely with OpenShift out of the box.

@sebgoa

@bitnami

References

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.