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-zft17Welcome 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.comnami 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
- Kubernetes Pod security policies
- Running your docker image on minishift
- Managing security constraints