このコンテンツは選択した言語では利用できません。

Chapter 16. Securing Builds by Strategy


16.1. Overview

Builds in OpenShift 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, project administrators (the admin role) and project editors (the edit role) 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. Granting permission to create on the build subresource allows the user to create builds of that type.

Table 16.1. Build Strategy Subresources
StrategySubresource

Docker

builds/docker

Source-to-Image

builds/source

Custom

builds/custom

16.2. Disabling a Build Strategy Globally

To prevent access to a particular build strategy globally, log in as a user with cluster-admin privileges and edit each of the default 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:

Example 16.1. Disable the Docker Build Strategy for admin

kind: ClusterRole
metadata:
  name: admin
...

rules:
- attributeRestrictions: null
  resources:
  - builds/custom
  - builds/docker 1
  - builds/source
  - pods/exec
  - pods/portforward

...
1
Delete this line to disable Docker builds globally for users with the admin role.

16.3. Restricting Build Strategies to a User Globally

To allow only a set of specific users to create builds with a particular strategy:

  1. Remove the build strategy subresource from the default admin and edit roles.
  2. Create a separate role for the build strategy. For example, create a dockerstrategy.yaml file that defines a separate role for the Docker build strategy:

    kind: ClusterRole
    apiVersion: v1
    metadata:
      name: dockerbuilder
    rules:
    - resources:
      - builds/docker
      verbs:
      - create

    As cluster administrator, create the new cluster role:

    $ oc create -f dockerstrategy.yaml
  3. Assign the new cluster role to a specific user. For example, to add the new dockerbuilder cluster role to the user devuser:

    $ oadm policy add-cluster-role-to-user dockerbuilder devuser
Warning

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.

16.4. Restricting Build Strategies to a User Within a Project

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:

  1. Remove the build strategy resource from the default admin and edit roles.
  2. Create a separate role for that build strategy.
  3. Assign the role to a specific user within a project. For example, to add the new dockerbuilder role within the project devproject to the user devuser:

    $ oadm policy add-role-to-user dockerbuilder devuser -n devproject
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.