Yes, to run tests that root your whole cluster, the test running for conformance grants “root your cluster” permissions.
I occasionally regret the defaults we picked because people get frustrated that random software off the internet doesn’t run.
That said, every severe (or almost every) container runtime vulnerability in the last five years has not applied to a default pod running on OpenShift, so there’s at least some comfort there.
To grant “run as uid 0” is a one line RBAC as assignment. To grant “run as uid 0 and access host” is a similar statement.
https://github.com/openshift/origin/blob/master/test/extende...
In SUSE to Acquire Rancher Labsopenshift
origin
Go2015–2020
openshift / origin
origin
Conformance test suite for OpenShift
17Distinct people
23Mentions
0Explicit recommenders
8.7KGitHub stars
What to know before exploring
What it is
Conformance test suite for OpenShift
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 1:49:46 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year23 dated mentions
Observed mentions: 2015-01-29 07:49:04 UTC to 2020-07-08 19:12:29 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 3 | 2 | 1 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 5 | 0 | 5 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 5 | 1 | 4 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 5 | 0 | 5 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 2 | 0 | 2 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
Origin Kubernetes
This repo was previously the core Kubernetes tracking repo for
OKD, and where OpenShift's
hyperkube and openshift-test binaries were maintained. As of July
2020, the purpose and maintenance strategy of the repo varies by
branch.
Maintenance of main and release-x.x branches for 4.6 and above
These branches no longer include the code required to produce
hyperkube binaries, and are limited to maintaining the openshift-tests
binary. Responsibility for maintaining hyperkube has transitioned to
the openshift/kubernetes
repo.
Backports and carries against upstream should be proposed to
openshift/kubernetes. If changes merged to openshift/kubernetes
need to land in origin, it will be necessary to follow up with a PR
to origin that bumps the vendoring.
Branch names are correlated across the 2 repositories such that
changes merged to a given branch in openshift/kubernetes should be
vendored into the same branch in origin (e.g. master in
openshift/kubernetes is vendored into main in origin).
NOTE: Vendoring of the main and release-x.x branches of
openshift/kubernetes into the equivalent branches in origin is
intended to be temporary. At some point in the near future, origin
will switch to vendoring origin-specific branches (e.g
origin-4.6-kubernetes-1.19.2) to minimize the scope of backports and
carries that need to be considered in the context of
openshift/kubernetes rebases.
Test exclusion rules
Test exclusion is now handled through environmental selector based filtering
rather than test annotations. Environmental selectors allow tests to be
filtered or skipped based on the cluster environment and configuration.
For example, selectors can be defined that match kube e2e tests that are
known to be incompatible with specific OpenShift configurations and exclude
those tests from running.
Maintenance of test exclusion rules is split between the
openshift/kubernetes and origin repos to ensure that PRs proposed
to openshift/kubernetes can be validated against the set of kube e2e
tests known to be compatible with OpenShift.
Test exclusion rules for kubernetes e2e tests are maintained in: https://github.com/openshift/kubernetes/blob/master/openshift-hack/cmd/k8s-tests-ext:
environment_selectors.go
disabled_tests.go
Test exclusion rules for openshift e2e tests are maintained in: https://github.com/openshift/origin/blob/main/pkg/test/extensions:
environment_selectors.go
disabled_tests.go
To update test exclusion rules for kube e2e tests, update the environmental selectors in openshift/kubernetes. For OpenShift e2e tests, update the selectors in origin.
Vendoring from openshift/kubernetes
These origin branches vendor k8s.io/kubernetes and some of its
staging repos (e.g. k8s.io/api) from our
openshift/kubernetes fork.
Upstream staging repos are used where possible, but some tests depends
on functionality that is only present in the fork.
When a change has merged to an openshift/kubernetes branch that
needs to be vendored into the same branch in origin, the
hack/update-kube-vendor.sh helper script simplifies updating the go
module configuration for all dependencies sourced from
openshift/kubernetes for that branch. The script requires either the
name of a branch or a SHA from openshift/kubernetes:
$ hack/update-kube-vendor.sh <openshift/kubernetes branch name or SHA>
The script also supports performing a fake bump to validate an as-yet
unmerged change to openshift/kubernetes. This can be accomplished by
supplying the name of a fork repo as the second argument to the
script:
$ hack/update-kube-vendor.sh <branch name or SHA> github.com/myname/kubernetes
Once the script has executed, the vendoring changes will need to be
committed and proposed to the repo.
Working around '410 Gone' error
If the script returns '410 Gone' as per the error that follows, it may
be that the golang checksum server does not yet know about the target
SHA.
go: k8s.io/kubernetes@v1.21.1 (replaced by github.com/openshift/kubernetes@v1.21.2-0.20210603185452-2dfc46b23003): verifying go.mod: g
ithub.com/openshift/kubernetes@v1.21.2-0.20210603185452-2dfc46b23003/go.mod: reading https://sum.golang.org/lookup/github.com/openshif
t/kubernetes@v1.21.2-0.20210603185452-2dfc46b23003: 410 Gone
server response: not found:
The workaround is to set GOSUMDB=off to disable the checksum
database for the vendoring update:
$ GOSUMDB=off hack/update-kube-vendor.sh <branch name or SHA>
Maintenance of release-4.5, release-4.4 and release-4.3
Releases prior to 4.6 continue to maintain hyperkube in the origin
repo in the release-4.x branches. Persistent carries and backports
for those branches should continue to be submitted directly to
origin. openshift/kubernetes is not involved except for rebases.
End-to-End (e2e) and Extended Tests
End to end tests (e2e) should verify a long set of flows in the
product as a user would see them. Two e2e tests should not overlap
more than 10% of function and are not intended to test error
conditions in detail. The project examples should be driven by e2e
tests. e2e tests can also test external components working together.
All e2e tests are compiled into the openshift-tests binary.
To build the test binary, run make.
To run a specific test, or an entire suite of tests, read
test/extended/README
for more information.
Updating external examples
hack/update-external-example.sh will pull down example files from external
repositories and deposit them under the examples directory.
Run this script if you need to refresh an example file, or add a new one. See
the script and examples/quickstarts/README.md for more details.
Read the full README on GitHubWhat Hacker News says
23 sourcesIt would help if you provided a link to the CNCF results.
From what I see in https://github.com/openshift/origin/blob/master/test/extende... there are additional policies granted (search for "Disable container security").
In SUSE to Acquire Rancher Labs> Openshift 4.x is open-source.
That's great to hear. My mistake then, last time I've opened http://github.com/openshift/origin, I saw OpenShift 3.11 even though latest release was 4.2 at the time. From that, and given the fact that all other RedHat products are upstream first, I've made a conclusion that OpenShift 4 is no longer open-source.
> From my understanding, most of it's been blocked on Fedora CoreOS being at a state that it can be used for OKD and just putting resources onto setting up the automation for building everything for OKD.
What's the difference between OKD and OpenShift? Why does OKD use Fedora CoreOS, while OpenShift doesn't? Is it not the same code?
> Remember that Openshift 4.x fundamentally changed how Openshift does updates and that affects OKD a lot. Claytons email touches on this quite a bit.
Don't know Clayton
Read the rest
or seen his email. I'm confused why would OKD use a different code than OpenShift. I though that the only difference between OKD and OpenShift would be the subscription.
I actually wonder what the Kubernetes conformance suite is worth. For one I took a look at how OpenShift passes the conformance suite as it is much more locked down than stock Kubernetes (that's a good thing, I guess, but not exactly conformant). The answer is, they remove the restrictions before running the suite (https://github.com/openshift/origin/blob/master/test/extende...). So in my view a default installation of OpenShift does not pass the Kubernetes conformance test.
The fact that many software packages for Kubernetes do not run on OpenShift confirms this and challenges the worth of the Kubernetes conformance claim, probably for many other Kubernetes products as well. Afer all, what good is a conformance test when it doesn't ensure compatibility.
In There are over 80 Certified Kubernetes offeringsI don’t know any of the details (apologies!) but some OpenShift devs I’ve talked to and work with at Red Hat do this for their work. It seems some of the details are here [0].
[0] https://github.com/openshift/origin/blob/master/CONTRIBUTING...
In Fully static, unprivileged, self-contained, containers as executable binariesThe main repo is the 4th result on Google for me: https://github.com/openshift/origin. In 3rd position is the openshift.org website.
I feel like this one is really on you, not Red Hat.
In As Kubernetes grows, a startup ecosystem develops in its wakeOpenShift is a fork of the Kubernetes code base: https://github.com/openshift/origin
I.e. it’s not using the upstream distribution of Kubernetes like the public cloud vendors or Heptio etc.
It’s great it’s a Certified Kubernetes though!
In Jenkins X: a CI/CD solution for cloud applications on KubernetesBest practice: don't roll your own Kubernetes cluster and use a distribution like OpenShift[1].
They take care of providing, among others, a secure default configuration.
[1]: https://github.com/openshift/origin
In Kubernetes Security – Best Practice GuideRed Hat's open source OpenShift PaaS[1] is amazing. It has all the missing pieces you need for a production Kubernetes cluster: documentation and playbooks on how to run a production cluster[2], a build system, a container registry with fine-grained permissions, application templates, a logging framework...
Red Hat is a major contributor to Kubernetes and continually upstreams OpenShift features (like RBAC - they implemented it in OpenShift first, then upstreamed it, and then rebased OpenShift on top of it, removing the custom implementation).
I'm currently looking at migrating a large enterprise setup to Kubernetes/OpenShift.
[1]: https://github.com/openshift/origin
[2]: https://docs.openshift.org/latest/welcome/index.html
In Kubernetes 1.10 releasedRed Hat's OpenShift[1] Kubernetes distribution can do this too - you even get a webhook for GitHub copy and paste.
Kubernetes is a toolbox, not a product. There's so much you have to set up yourself (build system, registry, security, logging stack, metrics...). That's fine if you're in the business of selling Kubernetes itself, but otherwise, most teams should use something like OpenShift and not re-invent the wheel.
[1]: https://github.com/openshift/origin
In Show HN: Gitkube – Deploy to Kubernetes Using Git PushEverything in openshift is open source at https://github.com/openshift/origin. The commercial version is long term support, security response and errata, and the stability around that. There's nothing that is withheld from the open source project. It is not open core.
Edit: I forgot, the logo is not open source. So the logo is withheld :)
In Adding Kubernetes support to the Docker platformOpenshift is open source, Docker EE is not. Big difference.
https://github.com/openshift/origin
In Adding Kubernetes support to the Docker platformHrm, we've had a plan for a while, so whoever told you that may have been misinformed (sorry about that, not everyone always catches up).
https://github.com/openshift/origin/blob/master/pkg/cmd/infr...
Is in 3.6, and other improvements will continue to be added. The one downside is that you have to grant the router proxies access to secrets, which means if someone compromises your edge ingress controller they can root your cluster unless you are very careful about only giving the routers access to exactly the secrets they need. That's partially why Routes contain their own secrets, so that you can't accidentally expose yourself to a cluster root.
This sort of stuff is the details the OpenShift team spends most of its time on. Kube will eventually get most of this. But most people are running single tenant Kube clusters and so in Kube
Read the rest
we spend more time focusing on making that work just right. It's pretty difficult to build a fully multitenant Kube setup without making choices that we're just not ready to do in Kube yet.
[Full disclosure: I work for Red Hat as an OpenShift Consultant]
The truth is a bit more nuanced as Kubernetes and OpenShift are actually made up of dozens of projects and integrations. Our company contributes to (as upstreams) in support of our OpenShift Enterprise offering: Kubernetes, Linux kernel, HAProxy, Jenkins, Hawkular, Heapster, Cassandra, Elasticsearch, FluentD, Kibana, Jenkins, JBoss, Tomcat, Apache, Ansible, Go-lang, and probably many more. We do almost all of our work completely in the open (our docs, container images, templates, examples, blogs) via github and trello. In fact, you can run just about the same OpenShift (officially called OpenShift Container Platform (OCP or OSCP) or OpenShift Enterprise (OSE)) we sell by using our upstream project for it, OpenShift Origin [0][1]. If that looks complicated, you can try m
Read the rest
inishift [2][3] to start which also has an upstream Kubernetes project in minikube [4].
In terms of superset vs. fork: it's not quite a superset because almost everything we commit to OpenShift gets committed to Kubernetes and/or vicea versa. You can almost always say if it works in OpenShift, it works in Kubernetes; if it works in Kubernetes, it works in OpenShift.
It's not really a fork either (as we say often "Best idea wins!") and so our people (including management!) try to make sure we are adding value to Kubernetes so that our customers & the community can then extract that value. OpenShift/Kubernetes metrics is one place that affects me & my customers that we're following the community's lead on that and implementing new developments in OpenShift as Tech Previews when appropriate. Our code is not diverging from Kubernetes as much as you might think in supporting some of the "enterprise" features we've added.
So, I would say OpenShift is a Distro of Kubernetes in the same ways RHEL, SuSE, et. al., are GNU/Linux Distros. You might say Kubernetes provides the "kernel" for a modern Data Center (compute resource scheduling and management, internal/external data structures and interfaces to use such compute resources). OpenShift is intended to help provide everything else you expect your data center to do for you or to support your Application Development in Java, .Net, node.js, Ruby, Python, PHP, Perl, etc (UI & CLI management interfaces, simplified build and deployment processes (S2I), Jenkins integration, external logging integration, external monitoring integration, sample 12 Factor Applications, etc.). We partner with companies when they want help bringing on their storage systems, frameworks, databases, applications, etc., just like you'd expect when companies provide drivers for their databases, hardware, or storage systems for OS kernels.
[0] https://www.openshift.org/
[1] https://github.com/openshift/origin
[2] https://docs.openshift.org/latest/minishift/getting-started/...
[3] https://github.com/minishift/minishift
[4] https://kubernetes.io/docs/tasks/tools/install-minikube/
Showing the 15 most recent of 23 sources. Enable JavaScript to search and browse every indexed mention.