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
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
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
# 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:
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
oc new-app --name foobar \
--docker-image bitnami/mariadb \
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 email@example.com
nami INFO Initializing mariadb
mariadb INFO ==> Configuring permissions…
mariadb INFO ==> Validating inputs…
mariadb INFO ==> Initializing database…
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.