← Back

2026

OpenShift: Kubernetes with Opinions

OpenShift takes Kubernetes as its foundation and adds everything upstream deliberately left out: a built-in registry, a container build system, opinionated networking and security defaults that are meaningfully stricter than a bare cluster. Here is what that looks like in practice.

Kubernetes is a platform for building platforms. It gives you the building blocks but expects you to assemble them into something usable. That works well if you have the time and the people to do it, but it leaves a significant amount of work between a running Kubernetes cluster and a place where a developer can actually ship software.

OpenShift is Red Hat's answer to that gap. It takes Kubernetes as its foundation and adds everything the upstream project deliberately left out: a built-in image registry, a container build system, opinionated networking, a developer console and security defaults that are meaningfully stricter than what you get with a bare cluster. The result is a distribution that takes stronger positions on how things should work so that teams spend less time making those decisions themselves.

None of that comes for free. OpenShift is more opinionated than vanilla Kubernetes, which means some of those opinions will occasionally be in tension with how a team wants to work. Understanding what it adds, what it changes and where it draws lines is worth doing before you commit to running it.

What OpenShift adds on top of Kubernetes

The Kubernetes API is still there underneath. Pods, Deployments, Services, ConfigMaps all work exactly as they do on any other distribution. OpenShift extends that API with its own resource types that handle the parts upstream Kubernetes leaves to you.

Routes

OpenShift's answer to Kubernetes Ingress. A Route exposes a service to the outside world through the built-in HAProxy router. You get a hostname, optional TLS termination and path-based routing without having to install an Ingress controller separately. The router is managed by the platform and comes configured out of the box.

ImageStreams

An abstraction over container images that lives inside OpenShift. An ImageStream tracks tags pointing to actual image digests in a registry. When the underlying image changes, deployments that reference the stream can be triggered to rebuild or redeploy automatically. It decouples what your workload references from the specific digest it runs.

BuildConfigs

A native build pipeline inside the cluster. A BuildConfig defines how to produce a container image: from source code, from a Dockerfile, using Source-to-Image. Builds run as pods. The output goes into an ImageStream. This keeps the full path from code to running container inside the platform without needing an external CI system for the build step.

Projects

OpenShift's wrapper around Kubernetes namespaces. A Project carries the same isolation boundary as a namespace but adds quota enforcement, a default set of role bindings and integration with the platform's identity system. Creating a Project through the console or CLI creates the namespace and applies standard defaults in one step.

Security Context Constraints

The OpenShift equivalent of Kubernetes Pod Security Admission, but more granular and predating it by years. SCCs define what a pod is permitted to do at the host level: which user IDs it can run as, whether it can mount host paths, whether it can use privileged mode. Every pod gets an SCC applied. The default policy prevents containers from running as root, which catches a large class of misconfigurations that vanilla Kubernetes would let through silently.

The web console

OpenShift ships a web console that covers both the administrator view and the developer view in the same interface. You can switch between them depending on what you are doing. The developer perspective shows you your workloads, their status, the topology of how services connect to each other and a log viewer that does not require kubectl. The administrator perspective shows you the full cluster: nodes, operators, storage, network, quotas.

This matters for teams that include people who are not comfortable at the command line. A developer can check why a pod is crashing, tail its logs, look at environment variables and trigger a new build without touching a terminal. That is genuinely useful in practice and not something you get with a vanilla Kubernetes cluster unless you install and maintain a dashboard yourself.

The console also surfaces the Operator Lifecycle Manager, which handles installing and upgrading cluster add-ons through a catalogue of operators. Installing something like cert-manager, Jaeger or a database operator becomes a few clicks rather than a trip to a Helm chart repository. The trade-off is that the OperatorHub catalogue is curated and not every community project is in it.

Source-to-Image

Source-to-Image, usually written S2I, is a build strategy that takes your application source code and produces a runnable container image without requiring a Dockerfile. You provide the source. OpenShift provides a builder image for the runtime you are using. The builder image knows how to compile the application, install dependencies and assemble the final image in a way that respects the platform's security constraints.

The output is a container that runs as a non-root user by default because the builder image was constructed with that in mind. This is the mechanism that lets developers who do not know much about container security produce images that pass the platform's SCC policies without having to think about it explicitly.

S2I is not a replacement for a full CI pipeline. It does not run tests. It does not enforce code quality gates. What it does is remove the container packaging step as a barrier for teams that just want to take a repository of code and get it running inside the cluster quickly.

Security Context Constraints

Security Context Constraints are the mechanism OpenShift uses to control what pods are allowed to do at the host level. Every pod admission goes through SCC evaluation. The platform picks the most restrictive SCC that the pod's service account is permitted to use and that the pod's requested capabilities fit within. If no matching SCC exists, the pod does not start.

restricted

The default. Prevents running as root, prevents host path mounts, drops most Linux capabilities. Most workloads should work within this constraint. If an image requires root and has no good reason for it, this is where the platform pushes back.

nonroot

Allows any non-root user ID. Less strict than restricted on some dimensions but still prevents running as UID 0. Useful for images that set a specific non-root user but do not fit within restricted.

anyuid

Allows the pod to run as any user ID including root. Required for images that do not respect the platform's injected user ID. Granting this requires explicit administrator action and leaves a clear audit trail of which workloads run with elevated identity.

privileged

Full access to the host. Needed for system-level tooling: node agents, storage plugins, network operators. Almost never appropriate for application workloads. The name is visible in audit logs, which is intentional.

The common frustration with SCCs is that images from Docker Hub or third-party Helm charts often assume they will run as root. When you pull one of those into an OpenShift cluster and it fails to start, the error message points at the SCC. The fix is either to find a version of the image built for OpenShift, to grant a broader SCC to the workload's service account, or to run the container with a specific non-root UID if the image supports it. None of these are difficult but all of them require understanding what SCCs are doing.

The oc CLI

OpenShift ships its own CLI called oc. It is a superset of kubectl. Every command you know from kubectl works with oc. The additions cover the OpenShift-specific resource types and a handful of convenience commands that do not exist in kubectl.

oc new-project my-app

Create a new Project and switch context into it. Equivalent to creating a namespace plus applying default role bindings.

oc new-app --image-stream=nodejs:18 .

Scaffold a new application from source using a built-in image stream. OpenShift detects the runtime, creates a BuildConfig, ImageStream and Deployment in one step.

oc expose svc/my-app

Create a Route pointing to the named service. OpenShift assigns a hostname under the cluster's base domain automatically.

oc start-build my-app

Trigger a build manually. The build runs as a pod in the cluster. Logs are streamed with oc logs -f bc/my-app.

oc get events --sort-by=.lastTimestamp

List recent events in the current project sorted by time. Useful for diagnosing why a pod failed to start or a build did not complete.

oc adm policy add-scc-to-user anyuid -z my-serviceaccount

Grant a service account permission to run pods as any user ID. Needed when a third-party image expects to run as root and you have decided that tradeoff is acceptable.

How it compares to vanilla Kubernetes

The question is not which one is better. They solve different problems for different audiences. OpenShift makes sense when a team wants a fully integrated platform and is willing to operate within its opinions. Vanilla Kubernetes makes sense when maximum control over every component is a requirement or when the team has strong existing preferences about tooling.

Installation

Vanilla Kubernetes requires assembling components from multiple projects and making many decisions upfront. OpenShift ships as an opinionated distribution where the installer makes those decisions for you. The tradeoff is less flexibility but significantly less time to a working cluster.

Container builds

Kubernetes has no opinion about how images get built. You bring your own CI. OpenShift has BuildConfigs and Source-to-Image built in, so a team can go from source code to a running deployment using only platform tools.

Image registry

OpenShift includes an internal registry. Images built inside the cluster are pushed there automatically. Kubernetes has no built-in registry. You bring your own, configure credentials separately and manage access yourself.

Networking

Both require a CNI plugin. OpenShift ships with OVN-Kubernetes by default and manages the network operator as part of the platform. Routes and the HAProxy router come configured. On vanilla Kubernetes you choose a CNI plugin and install an Ingress controller separately.

Security defaults

OpenShift prevents root containers by default through SCCs applied at pod admission. Kubernetes Pod Security Admission reaches a similar place but arrived later and the default enforcement level is lower. OpenShift has been enforcing non-root by default for years.

Operators and the Operator Lifecycle Manager

OpenShift is itself managed by operators. The platform components — the API server, the image registry, the ingress controller, the monitoring stack — are all installed and upgraded by operators that run inside the cluster. This is not unique to OpenShift, but OpenShift takes it further than most distributions by making the operator model the standard mechanism for everything, including the platform itself.

The Operator Lifecycle Manager ships with OpenShift and provides a framework for installing, upgrading and managing the lifecycle of operators in the cluster. OperatorHub is the catalogue. You find an operator you want, subscribe to it at a channel and OLM handles keeping it up to date. The operator then manages whatever it was built to manage, whether that is a database, a message broker or a certificate authority.

For teams building their own tooling, writing a custom operator to manage application-specific lifecycle operations fits naturally into this model. The Operator SDK, maintained by Red Hat, provides scaffolding for writing operators in Go or Ansible without having to build the controller-runtime machinery from scratch.

Cluster updates

One of the operational advantages OpenShift advertises most heavily is over-the-air cluster updates. The Cluster Version Operator manages the update process. You select a target version in the console or through the CLI and the platform handles draining nodes, updating components in the correct order and verifying that each step completed before moving to the next.

Updates follow a graph that Red Hat maintains. Not every version can upgrade directly to every other version. The platform checks the graph before proceeding and will tell you if the path you have chosen is not supported. This prevents the class of problems that comes from skipping a version that contained a migration step.

For teams used to upgrading Kubernetes clusters manually, this is a genuine quality of life improvement. It does not eliminate the need to test workloads after an upgrade, but it removes most of the ceremony around getting the control plane and node components to a new version without breaking things in the process.

Where it fits

OpenShift is not a replacement for understanding Kubernetes. The concepts underneath are the same. Pods, controllers, scheduling, service discovery all work the same way. What OpenShift changes is the layer above that: how you get code into a running container, how you expose it, how the platform enforces security policy and how the cluster updates itself over time.

It makes the most sense in environments where the operational team is smaller relative to the number of development teams using the platform. The defaults carry weight in that situation. Developers get a consistent environment with sensible guardrails. The platform team spends less time answering questions about how to expose a service or why a pod will not start, because the platform's opinions handle a large fraction of those cases.

The tradeoff is the opinions themselves. When your workload does not fit within them, you are working against the platform rather than with it. Understanding where those friction points are — SCCs, the internal registry, Routes versus Ingress — is the difference between OpenShift being a productivity multiplier and being a constant source of friction for the teams using it.