3 ms·
It takes away privileges which arguably is a good thing but some things that require root containers wont't run. They pass the Kubernetes conformance suite only
by ofrzeta 6y ago
It takes away privileges which arguably is a good thing but some things that require root containers wont't run. They pass the Kubernetes conformance suite only by removing those constraints.
- BossingAround 6y agoAnd you can do the same for your environment. You can run root containers on OpenShift, it's a settings, not a baked-in compiled choice or something similar.
- ofrzeta 6y agoThat is true. It's a tradeoff when you consider to turn off SELinux, too, however.
- candiddevmike 6y agoThat's not true at all. You can read their CNCF results yourself, nothing is disabled. And the conformance tooling works around these constraints by defining their own PSPs.
- ofrzeta 6y agoIt would help if you provided a link to the CNCF results. From what I see in https://github.com/openshift/origin/blob/master/test/extended/conformance-k8s.sh https://github.com/openshift/origin/blob/master/test/extende... there are additional policies granted (search for "Disable container security").
- smarterclayton 6y agoYes, 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/extended/conformance-k8s.sh#L67 https://github.com/openshift/origin/blob/master/test/extende...