Red Hat OpenShift

Red Hat OpenShift is an enterprise Kubernetes platform. Underneath, it is Kubernetes — the same API, Deployments, Services, and Helm charts — but it adds an opinionated operating system, a fully operator-managed control plane with tested upgrade paths, stricter security defaults, built-in authentication and developer console, and a catalog of supported add-ons for CI/CD, GitOps, service mesh, serverless, and virtual machines. Organizations choose it for vendor support, consistent operations across data centers and clouds, and compliance.

For application teams, OpenShift mostly feels like Kubernetes with a few important differences. Containers run as random, non-root user IDs by default; external traffic usually arrives through Routes; namespaces are created as projects; and cluster administrators manage platform components through operators rather than by hand. Images and manifests built with those differences in mind run on OpenShift and on any other Kubernetes.

TL;DR

Quick Example

A Deployment that satisfies the default restricted-v2 security context constraint, with a Service and an edge-terminated Route:

An image that works with arbitrary user IDs, which run with group 0:

Day-to-day commands:

Core Concepts

Editions

Architecture and Lifecycle

Control-plane nodes run Red Hat Enterprise Linux CoreOS, an immutable OS managed by the Machine Config Operator, so node configuration is declared rather than changed by hand. Each platform component — networking, ingress, monitoring, image registry, authentication — is managed by a cluster operator; oc get clusteroperators shows their health. The Cluster Version Operator upgrades the whole platform as a unit along update channels (such as stable and fast, plus extended update support channels), following tested upgrade paths.

Projects, oc, and the Console

A project is a namespace with additional metadata and default permissions; self-service project creation can be enabled or restricted. The oc CLI supports all kubectl commands plus OpenShift resources and administration. The web console offers developer and administrator perspectives, topology views, and log and metrics access.

Networking: Routes

Routes expose services through the cluster's HAProxy-based ingress controller, with edge, passthrough, or re-encrypt TLS termination and automatic hostnames. Standard Kubernetes Ingress objects are supported (OpenShift creates Routes from them), and the Gateway API is available in recent releases. The default CNI is OVN-Kubernetes, with network policies and egress controls.

Security Defaults

Security context constraints (SCCs) control what pods may do. The default restricted-v2 SCC runs containers as a random UID from the project's range, with group 0, no privilege escalation, all capabilities dropped, and the runtime default seccomp profile; it aligns with Kubernetes Pod Security "restricted" standards, which are also enforced. Images that assume root or a fixed UID fail: give group 0 write access to directories the app needs, listen on ports above 1024, and avoid runAsUser in manifests. Grant broader SCCs to specific service accounts only when justified. Authentication uses the built-in OAuth server with identity providers (OIDC, LDAP, and others) plus standard Kubernetes RBAC. See Container Security and Kubernetes RBAC.

Builds, Images, and Delivery

OpenShift includes an internal image registry, ImageStreams that track image tags and trigger redeployments, and Builds (including Source-to-Image) that produce images in-cluster. Many teams instead build in CI and deploy with OpenShift GitOps (Argo CD) or OpenShift Pipelines (Tekton). Legacy DeploymentConfig objects are deprecated; use standard Deployments. See Argo CD.

Operators and Add-Ons

OperatorHub and the Operator Lifecycle Manager install and upgrade platform add-ons and third-party software: databases, messaging, monitoring, OpenShift Virtualization (KubeVirt virtual machines alongside containers), Service Mesh, Serverless (Knative), and data services. See Kubernetes Operators.

Best Practices

Build Images for Arbitrary UIDs

Use non-root base images (such as Red Hat UBI), group-0 permissions, and unprivileged ports, so containers run under default SCCs.

Keep Manifests Portable

Use standard Kubernetes resources where possible and isolate OpenShift-specific ones (Routes, SCC bindings), so workloads also run elsewhere.

Stay on Supported Upgrade Paths

Follow update channels, review operator compatibility before upgrades, and upgrade regularly rather than in large jumps.

Govern Elevated Permissions

Track every custom SCC grant and cluster-admin binding, with owners and reasons, and enforce policies with admission controls. See Kubernetes Policy Enforcement and Exceptions.

Common Mistakes

Images That Require Root

Granting anyuid to Make Errors Go Away

Hand-Editing Nodes

FAQ

Is OpenShift just Kubernetes?

It is Kubernetes plus an opinionated, supported platform: an immutable OS, operator-managed components and upgrades, stricter security defaults, built-in authentication, a developer console, and supported add-ons.

What is the difference between a Route and an Ingress?

Routes are OpenShift's original way to expose services through the built-in router, with TLS options and automatic hostnames. OpenShift also supports Kubernetes Ingress, creating Routes from Ingress objects.

Why does my container fail on OpenShift but work elsewhere?

Most often because OpenShift runs containers as a random non-root UID. Images that need root, fixed UIDs, or privileged ports must be adjusted.

What is OKD?

The community distribution of Kubernetes that OpenShift is built from, available without a Red Hat subscription or support.

Can OpenShift run virtual machines?

Yes. OpenShift Virtualization, based on KubeVirt, runs virtual machines alongside containers and manages them with Kubernetes APIs.

Related Topics

References