Red Hat Summit Red Hat SummitSupportKonsoleEntwicklerDemo startenKontakt

Dieser Inhalt ist in der von Ihnen ausgewählten Sprache nicht verfügbar.

Chapter 11. Securing builds by strategy

Builds in OpenShift Container Platform are run in privileged containers. Depending on the build strategy used, if you have privileges, you can run builds to escalate their permissions on the cluster and host nodes. And as a security measure, it limits who can run builds and the strategy that is used for those builds. Custom builds are inherently less safe than source builds, because they can execute any code within a privileged container, and are disabled by default. Grant docker build permissions with caution, because a vulnerability in the Dockerfile processing 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 the docker and Source-to-image (S2I) build strategies. Users with cluster administrator privileges can enable the custom build strategy, as referenced in the restricting build strategies to a user globally section.

You can control who can build and which build strategies they can use by 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 to create builds using that strategy. Default roles are provided that grant the create permission on the build strategy subresource.

Expand
Table 11.1. Build Strategy Subresources and Roles
StrategySubresourceRole

Docker

builds/docker

system:build-strategy-docker

Source-to-Image

builds/source

system:build-strategy-source

Custom

builds/custom

system:build-strategy-custom

JenkinsPipeline

builds/jenkinspipeline

system:build-strategy-jenkinspipeline

11.1. Disabling access to a build strategy globally
Link kopieren

To prevent access to a particular build strategy globally, log in as a user with cluster administrator privileges, remove the corresponding role from the 

system:authenticated
group, and apply the annotation 
rbac.authorization.kubernetes.io/autoupdate: "false"
to protect them from changes between the API restarts. The following example shows disabling the docker build strategy.

Procedure

  1. Apply the 

    rbac.authorization.kubernetes.io/autoupdate
    annotation: 

    $ oc annotate clusterrolebinding.rbac system:build-strategy-docker-binding 'rbac.authorization.kubernetes.io/autoupdate=false' --overwrite

  2. Remove the role: 

    $ oc adm policy remove-cluster-role-from-group system:build-strategy-docker system:authenticated

  3. Ensure the build strategy subresources are also removed from the 

    admin
    and 
    edit
    user roles: 

    $ oc get clusterrole admin -o yaml | grep "builds/docker"
     
    $ oc get clusterrole edit -o yaml | grep "builds/docker"

11.2. Restricting build strategies to users globally
Link kopieren

You can allow a set of specific users to create builds with a particular strategy.

Prerequisites

  • Disable global access to the build strategy.

Procedure

  • Assign the role that corresponds to the build strategy to a specific user. For example, to add the 

    system:build-strategy-docker
    cluster role to the user 
    devuser
    : 

    $ oc adm policy add-cluster-role-to-user system:build-strategy-docker devuser
    Warning

    Granting a user access at the cluster level to the 

    builds/docker
    subresource means that the user can create builds with the docker strategy in any project in which they can create builds.

11.3. Restricting build strategies to a user within a project
Link kopieren

Similar to granting the build strategy role to a user globally, you can allow a set of specific users within a project to create builds with a particular strategy.

Prerequisites

  • Disable global access to the build strategy.

Procedure

  • Assign the role that corresponds 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
    : 

    $ oc adm policy add-role-to-user system:build-strategy-docker devuser -n devproject
Red Hat logoGithubredditYoutubeTwitter

Lernen

Testen, kaufen und verkaufen

Communitys

Über Red Hat Dokumentation

Wir helfen Red Hat Benutzern, mit unseren Produkten und Diensten innovativ zu sein und ihre Ziele zu erreichen – mit Inhalten, denen sie vertrauen können. Entdecken Sie unsere neuesten Updates.

Mehr Inklusion in Open Source

Red Hat hat sich verpflichtet, problematische Sprache in unserem Code, unserer Dokumentation und unseren Web-Eigenschaften zu ersetzen. Weitere Einzelheiten finden Sie in Red Hat Blog.

Über Red Hat

Wir liefern gehärtete Lösungen, die es Unternehmen leichter machen, plattform- und umgebungsübergreifend zu arbeiten, vom zentralen Rechenzentrum bis zum Netzwerkrand.

Theme

© 2026 Red HatNach oben