搜索

此内容没有您所选择的语言版本。

Chapter 11. Securing builds by strategy

download PDF

Builds in OpenShift Container Platform are run in privileged containers. Depending on the build strategy used, this allows a user who can run builds to escalate their permissions on the cluster and host nodes. As a security measure, limit 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-admin 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 in order to create builds using that strategy. Default roles are provided which grant the create permission on the build strategy subresource.

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

To prevent access to a particular build strategy globally, log in as a user with cluster-admin 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 edit clusterrolebinding system:build-strategy-docker-binding
    
    apiVersion: v1
    groupNames:
    - system:authenticated
    kind: ClusterRoleBinding
    metadata:
      annotations:
        rbac.authorization.kubernetes.io/autoupdate: "false" 1
      creationTimestamp: 2018-08-10T01:24:14Z
      name: system:build-strategy-docker-binding
      resourceVersion: "225"
      selfLink: /oapi/v1/clusterrolebindings/system%3Abuild-strategy-docker-binding
      uid: 17b1f3d4-9c3c-11e8-be62-0800277d20bf
    roleRef:
      name: system:build-strategy-docker
    subjects:
    - kind: SystemGroup
      name: system:authenticated
    userNames:
    - system:serviceaccount:management-infra:management-admin
    1
    Change the rbac.authorization.kubernetes.io/autoupdate annotation’s value to "false".
  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 these roles:

    $ oc edit clusterrole admin
    $ oc edit clusterrole edit
  4. For each role, remove the line that corresponds to the resource of the strategy to disable.

    1. Disable the Docker Build Strategy for admin:

      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.

11.2. Restricting build strategies to users globally

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

Similar to granting the build strategy role to a user globally, you can allow only 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

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

© 2024 Red Hat, Inc.