搜索

2.11. 通过策略保护构建

download PDF

OpenShift Container Platform 中的构建在特权容器中运行。根据所用的构建策略,如果您有权限,可以运行构建来升级其在集群和主机节点上的权限。为安全起见,请限制可以运行构建的人员以及用于这些构建的策略。Custom 构建本质上不如 Source 构建安全,因为它们可以在特权容器内执行任何代码,这在默认情况下是禁用的。请谨慎授予 docker 构建权限,因为 Dockerfile 处理逻辑中的漏洞可能会导致在主机节点上授予特权。

默认情况下,所有能够创建构建的用户都被授予相应的权限,可以使用 docker 和 Source-to-Image (S2I) 构建策略。具有集群管理员特权的用户可启用自定义构建策略,如在全局范围内限制用户使用构建策略部分中所述。

您可以使用授权策略来控制谁能够构建以及他们可以使用哪些构建策略。每个构建策略都有一个对应的构建子资源。用户必须有权创建构建,并在构建策略子资源上创建构建的权限,才能使用该策略创建构建。提供的默认角色用于授予构建策略子资源的 create 权限。

表 2.3. 构建策略子资源和角色
策略子资源角色

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

2.11.1. 在全局范围内禁用构建策略访问

要在全局范围内阻止对特定构建策略的访问,请以具有集群管理源权限的用户身份登录,从 system:authenticated 组中移除对应的角色,再应用注解 rbac.authorization.kubernetes.io/autoupdate: "false" 以防止它们在 API 重启后更改。以下示例演示了如何禁用 Docker 构建策略。

流程

  1. 应用 rbac.authorization.kubernetes.io/autoupdate 注解:

    $ oc edit clusterrolebinding system:build-strategy-docker-binding

    输出示例

    apiVersion: rbac.authorization.k8s.io/v1
    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: /apis/rbac.authorization.k8s.io/v1/clusterrolebindings/system%3Abuild-strategy-docker-binding
      uid: 17b1f3d4-9c3c-11e8-be62-0800277d20bf
    roleRef:
      apiGroup: rbac.authorization.k8s.io
      kind: ClusterRole
      name: system:build-strategy-docker
    subjects:
    - apiGroup: rbac.authorization.k8s.io
      kind: Group
      name: system:authenticated

    1
    rbac.authorization.kubernetes.io/autoupdate 注解的值更改为 "false"
  2. 移除角色:

    $ oc adm policy remove-cluster-role-from-group system:build-strategy-docker system:authenticated
  3. 确保也从这些角色中移除构建策略子资源:

    $ oc edit clusterrole admin
    $ oc edit clusterrole edit
  4. 对于每个角色,指定与要禁用的策略资源对应的子资源。

    1. admin 禁用 docker Build 策略:

      kind: ClusterRole
      metadata:
        name: admin
      ...
      - apiGroups:
        - ""
        - build.openshift.io
        resources:
        - buildconfigs
        - buildconfigs/webhooks
        - builds/custom 1
        - builds/source
        verbs:
        - create
        - delete
        - deletecollection
        - get
        - list
        - patch
        - update
        - watch
      ...
      1
      添加 builds/custombuilds/source,以在全局范围内为具有 admin 角色的用户禁用 docker 构建。

2.11.2. 在全局范围内限制用户使用构建策略

您可以允许某一组用户使用特定策略来创建构建。

先决条件

  • 禁用构建策略的全局访问。

流程

  • 将与构建策略对应的角色分配给特定用户。例如,将 system:build-strategy-docker 集群角色添加到用户 devuser

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

    如果在集群级别授予用户对 builds/docker 子资源的访问权限,那么该用户将能够在他们可以创建构建的任何项目中使用 docker 策略来创建构建。

2.11.3. 在项目范围内限制用户使用构建策略

与在全局范围内向用户授予构建策略角色类似,您只能允许项目中的某一组特定用户使用特定策略来创建构建。

先决条件

  • 禁用构建策略的全局访问。

流程

  • 将与构建策略对应的角色分配给项目中的特定用户。例如,将 devproject 项目中的 system:build-strategy-docker 角色添加到用户 devuser

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

学习

尝试、购买和销售

社区

关于红帽文档

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

让开源更具包容性

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

關於紅帽

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

© 2024 Red Hat, Inc.