Builds in OpenShift Origin are run in privileged containers that have access to the Docker daemon socket. As a security measure, it is recommended to limit who can run builds and the strategy that is used for those builds. Custom builds are inherently less safe than Source builds, given that they can execute any code in the build with potentially full access to the node’s Docker socket. Docker build permission should also be granted with caution as a vulnerability in the Docker build logic could result in a privileges being granted on the host node.
By default, all users that can create builds are granted permission to use all build strategies (Docker, Source-to-Image, and Custom).
You can control who can build with what build strategy using an authorization policy. Each build strategy has a corresponding build subresource. A user must have permission to create a build and permission to create on the build strategy subresource in order to create builds using that strategy. Default roles are provided which grant the create permission on the build strategy subresource.
| Strategy | Subresource | Role |
|---|---|---|
Docker |
builds/docker |
system:build-strategy-docker |
Source-to-Image |
builds/source |
system:build-strategy-source |
Custom |
builds/custom |
system:build-strategy-custom |
Custom |
builds/jenkinspipeline |
system:build-strategy-jenkinspipeline |
To prevent access to a particular build strategy globally, log in as a user with cluster-admin privileges and remove the corresponding role from the system:authenticated group:
$ oadm policy remove-cluster-role-from-group system:build-strategy-custom system:authenticated $ oadm policy remove-cluster-role-from-group system:build-strategy-docker system:authenticated $ oadm policy remove-cluster-role-from-group system:build-strategy-source system:authenticated $ oadm policy remove-cluster-role-from-group system:build-strategy-jenkinspipeline system:authenticated
In versions prior to 1.2, the build strategy subresources were included in the admin and edit roles.
Ensure the build strategy subresources are also removed from these roles:
$ oc edit clusterrole admin $ oc edit clusterrole edit
For each role, remove the line that corresponds to the resource of the strategy to disable.
kind: ClusterRole metadata: name: admin ... rules: - resources: - builds/custom - builds/docker (1) - builds/source ... ...
| 1 | Delete this line to disable Docker builds globally for users with the admin role. |
To allow only a set of specific users to create builds with a particular strategy:
Assign the role corresponding to the build strategy to a specific user. For example, to add the system:build-strategy-docker cluster role to the user devuser:
$ oadm policy add-cluster-role-to-user system:build-strategy-docker devuser
|
Granting a user access at the cluster level to the builds/docker subresource means that the user will be able to create builds with the Docker strategy in any project in which they can create builds. |
Similar to granting the build strategy role to a user globally, to allow only a set of specific users within a project to create builds with a particular strategy:
Assign the role corresponding to the build strategy to a specific user within a project. For example, to add the system:build-strategy-docker role within the project devproject to the user devuser:
$ oadm policy add-role-to-user system:build-strategy-docker devuser -n devproject