Skip to content

Frequently Asked Questions

Why not vanilla k8s?

The main reason that Redpill Linpro did not choose vanilla Kubernetes as the base of our multi-tenant platform is that kubernetes lacks out-of-box enterprise functionality and security.

By default, OKD/Openshift comes with the following:

  • a mature UI-console that can be used for multi-tenancy
  • core components that are thoroughly tested as a "whole" before being released with security in mind
  • a full-stack monitoring eco-system that includes Prometheus(kube-state-metrics/cadvisor)/AlertManager/own-branded Grafana
  • Security Context Constraints to control permissions for pods

Vanilla Kubernetes can achieve almost the same stack, but then this needs to be applied, maintained and tested manually.

Why can I not run my container as privileged or root?

Processes in privileged containers are essentially equivalent to root on the host. "privileged" allows access to all privileged and host features and the ability to run as any user, any group, any fsGroup, and with any SELinux context.

This is therefore a big NO-GO since it would disable almost all pod security.

Ref. the following Kubernetes documentation, OKD documentation and the following article

My deployment gives an "Warning: would violate PodSecurity ..."-message

This is often easily resolved by following the output of the warning and adding the necessary parameters in your deployment. Resolving these warnings lead to better PodSecurity, meaning better security for your application!

I am only used to using Docker Compose. How to port this over to OKD/Kubernetes?

Try to separate your different containers in different yaml files. (for example a deployment.yaml,service.yaml and route.yaml) A great tool to do this automatically is Kompose. It is advisable to take one container at a time and try to get it running.

A common way of doing this is to point to a private container registry where your image is hosted or to point directly to an upstream image in quay.io or docker.io. If you have the possibility to hang on the upstream version, this is always advisable. If not, you can push/pull your own custom image through a Dockerfile or directly from your deployment. Some additional information of how to work with container images can be found here

My nginx pod is giving permission errors.

Try the nginxinc/nginx-unprivileged:stable-alpine-slim instead! Containers should run as least-privileged anyways.

My pod is giving permission errors due to hardcoded userID of my upstream image.

By default, OpenShift Container Platform runs containers using an arbitrarily assigned user ID. This provides additional security against processes escaping the container due to a container engine vulnerability and thereby achieving escalated permissions on the host node. (ref this link for more information)

For an image to support running as an arbitrary user, directories and files that are written to by processes in the image must be owned by the root group and be read/writable by that group. Files to be executed must also have group execute permissions.

Adding the following to your Dockerfile sets the directory and file permissions to allow users in the root group to access them in the built image:

RUN chgrp -R 0 /some/directory && \
    chmod -R g=u /some/directory

Because the container user is always a member of the root group, the container user can read and write these files. In addition, the processes running in the container must not listen on privileged ports, ports below 1024, since they are not running as a privileged user.

Can I use PersistentVolumes?

Yes, but we advise against it. Read this page for more information. Currently only access mode RWO(ReadWriteOnce) is supported, which means that a PersistentVolume can be mounted as read-write by a single node. This is not an ideal situation since it implies that all your relevant pods that need to read/write to that volume need to run on the same node. This is though not an issue for example for Statefulsets.

Try to use a database server or s3-bucket instead. If your needs would go beyond this, you can contact us.

Are Devfiles and Tekton pipelines supported?

No, we can offer ArgoCD(=declarative GitOps continuous delivery tool for Kubernetes) instead.

How to configure other timezones in cronjobs?

For CronJobs with no time zone specified, the kube-controller-manager interprets schedules relative to its local time zone, which is UTC by default. If you want to change this, this is possible by configuring the following:

spec:
  timeZone: "Europe/Oslo"

read more about cronjobs here: 1) uptream doc