| Summary: | Disable custom build strategy by default | ||
|---|---|---|---|
| Product: | OKD | Reporter: | Joel Smith <joelsmith> |
| Component: | Build | Assignee: | Corey Daley <cdaley> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Wang Haoran <haowang> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 3.x | CC: | aos-bugs, cbucur, jliggitt, shiywang |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2016-12-09 21:49:56 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
I think this was an explicit choice so that the default policy would "just work" and the ansible installer could choose to change it if they wished. @bparees? I'm also unsure whether we want this done in the policy or in the ocp installer same reasoning would apply to docker builds (In reply to Jordan Liggitt from comment #2) > same reasoning would apply to docker builds In some ways it does, but in some ways it doesn't. * Custom builds are inherently dangerous in that anyone who can do them can easily get root access on the node where the build runs (via the docker socket). * While it's true that docker builds run as root, we know of no existing method to escape containment with a docker build. So only the most paranoid of installations would want to disable docker builds, and only the most naive would want to enable custom builds across the board. So whatever solution we choose to address this issue, it should make as unlikely as possible that people who don't need custom builds don't have them enabled. > So whatever solution we choose to address this issue, it should make as
> unlikely as possible that people who don't need custom builds don't have
> them enabled.
whoa, syntax and semantics fail there. Let me try again
... it should make it as unlikely as possible that people who don't need custom builds have them enabled.
Pull request submitted here: https://github.com/openshift/origin/pull/11411 The PR says that we're waiting for some kind of consensus here. What do we need to do to arrive at that consensus? I forwarded an email thread to Jordan and Corey that happened before I created this bug. That's where it was decided that it was necessary to take action on this issue. We can continue that discussion if we need more specifics, but we have open audit items that we can't close until we either 1) take action or 2) decide that we're not going to do anything (and I'm voting for the first option). Finally in comment #3 I should have said that "relaxed" installs would use custom builds, not "naive". I was looking for an antonym for paranoid and settled on the wrong one. I thought custom and docker were much closer to each other in security impact. It's fine to remove custom now and discuss removing docker separately Commit pushed to master at https://github.com/openshift/origin https://github.com/openshift/origin/commit/206991f5d17abb75e39aceec8a517f9b76e7b605 Fixes bug 1380462 - https://bugzilla.redhat.com/show_bug.cgi?id=1380462 Updated bootstrap policy to not grant builds/custom privs for system:authenticated users by default Permissions can still be granted by an administrator if needed verified with version: openshift v3.4.0.19+346a31d kubernetes v1.4.0+776c994 etcd 3.1.0-rc.0 oc new-app -f https://raw.githubusercontent.com/openshift/origin/master/examples/sample-app/application-template-custombuild.json --> Deploying template "haowang/ruby-helloworld-sample" for "https://raw.githubusercontent.com/openshift/origin/master/examples/sample-app/application-template-custombuild.json" to project haowang ruby-helloworld-sample --------- This example shows how to create a simple ruby application in openshift origin v3 * With parameters: * ADMIN_USERNAME=admin7O5 # generated * ADMIN_PASSWORD=SiRMHWUg # generated * MYSQL_USER=userPLR # generated * MYSQL_PASSWORD=8SfRCMB3 # generated * MYSQL_DATABASE=root --> Creating resources ... service "frontend" created route "route-edge" created imagestream "origin-ruby-sample" created imagestream "origin-custom-docker-builder" created error: buildconfigs "ruby-sample-build" is forbidden: build strategy Custom is not allowed deploymentconfig "frontend" created service "database" created deploymentconfig "database" created --> Failed |
Description of problem: Because of its access to the docker socket, a build running under the custom build strategy can launch privileged containers which can be used to escape containment entirely. While the custom build strategy is useful and important in certain use cases, the security implications of having it enabled are serious. The strategy should be disabled by default for system:authenticated so that cluster owners have to specifically enable the feature if they are willing to take the security risk to use the feature. As it is today, customers who don't need the feature have the security exposure perhaps without even realizing it. Version-Release number of selected component (if applicable): 3.2 How reproducible: 100% Steps to Reproduce: oc policy who-can create builds/custom Actual results: Namespace: default Verb: create Resource: builds/custom ... Groups: system:authenticated system:cluster-admins system:masters Expected results: Namespace: default Verb: create Resource: builds/custom ... Groups: system:cluster-admins system:masters