Red Hat Summit 红帽全球峰会支持控制台（Console）开发人员开始试用联系人

第 1 章 安全最佳实践

获取 Red Hat OpenShift Dev Spaces 的关键最佳实践概述，可帮助您促进更具弹性的开发环境。

Red Hat OpenShift Dev Spaces 在 OpenShift 上运行，它为其上运行的产品提供平台以及产品的基础。OpenShift 文档是安全强化的入口点。

OpenShift 中的项目隔离

在 OpenShift 中，项目隔离与 Kubernetes 中的命名空间隔离类似，但通过项目的概念来实现。OpenShift 中的项目是顶级的组织单元，可在集群中的不同应用程序、团队或工作负载之间提供隔离和协作。

默认情况下，OpenShift Dev Spaces 为每个用户置备唯一的 & lt;username>-devspaces 项目。另外，集群管理员可以禁用 OpenShift 级别的项目自助置备，并在 CheCluster 自定义资源中关闭自动命名空间置备： 

devEnvironments:
  defaultNamespace:
    autoProvision: false
Copy to Clipboard

使用这个设置，您可以获得一个策展对 OpenShift Dev Spaces 的访问，集群管理员对每个用户控制置备，并可以明确配置各种设置，包括资源限值和配额。在 第 4.2.2 节 “提前置备项目” 中了解更多有关项目置备的信息。

基于角色的访问控制(RBAC)

默认情况下，OpenShift Dev Spaces operator 会创建以下 ClusterRole：

  • <namespace>-cheworkspaces-clusterrole
  • <namespace>-cheworkspaces-devworkspace-clusterrole
注意

& lt;namespace > 前缀与 Red Hat OpenShift Dev Spaces CheCluster CR 所在的项目名称对应。

当用户第一次访问 Red Hat OpenShift Dev Spaces 时，对应的 RoleBinding 会在 < username>-devspaces 项目中创建。

下面列出了可授予用户在命名空间中要使用的所有资源和操作。

表 1.1. 用户命名空间中可用的资源和操作概述。
ResourcesActions

pods

"get", "list", "watch", "create", "delete", "update", "patch"

pods/exec

"get", "create"

pods/log

"get", "list", "watch"

pods/portforward

"get", "list", "create"

configmaps

"get", "list", "create", "update", "patch", "delete"

events

"list", "watch"

secrets

"get", "list", "create", "update", "patch", "delete"

services

"get", "list", "create", "delete", "update", "patch"

Routes

"get", "list", "create", "delete"

persistentvolumeclaims

"get", "list", "watch", "create", "delete", "update", "patch"

应用程序/部署

"get", "list", "watch", "create", "patch", "delete"

apps/replicasets

"get", "list", "patch", "delete"

命名空间

"get", "list"

projects

"get"

devworkspace

"get", "create", "delete", "list", "update", "patch", "watch"

devworkspacetemplates

"get", "create", "delete", "list", "update", "patch", "watch"

重要

每个用户仅被授予其命名空间的权限，无法访问其他用户的资源。集群管理员可以为用户添加额外权限。它们不应该删除默认授予的权限。

如需为 Red Hat OpenShift Dev Spaces 用户配置集群角色，请参阅产品文档。https://eclipse.dev/che/docs/stable/administration-guide/configuring-cluster-roles-for-users/

如需基于角色的访问控制的更多详细信息，请参阅 OpenShift 文档。

开发环境隔离

开发环境的隔离使用 OpenShift 项目实施。每个开发人员都有一个项目，在其中创建和管理以下对象：

  • 云环境(CDE) Pod，包括 IDE 服务器。
  • 包含开发人员凭据的 secret，如 Git 令牌、SSH 密钥和 Kubernetes 令牌。
  • 带有开发人员特定配置的 ConfigMap，如 Git 名称和电子邮件。
  • 持久保留数据的卷，如源代码，即使 CDE Pod 停止了。
重要

对命名空间中的资源的访问权限必须限制为拥有它的开发人员。授予另一个开发人员读取访问权限等同于共享开发人员凭据，应该避免。

增强的授权

当前趋势是将基础架构分成几个 "fit for purpose" 集群，而不是具有 gigantic monolith OpenShift 集群。但是，管理员可能仍然希望提供粒度访问权限，并将某些功能的可用性限制为特定用户。

注意

"fit for purpose" OpenShift 集群指的是专门为满足特定用例或工作负载的要求和目标的集群。它基于它将管理的工作负载特性进行定制，以优化性能、资源利用率和其他因素。对于 Red Hat OpenShift Dev Spaces，建议置备这种类型的集群。

因此，可用于为不同组和用户设置粒度访问权限的可选属性包括在 CheCluster 自定义资源中：

  • AllowUsers
  • allowGroups
  • DenyUsers
  • denyGroups

以下是访问配置示例： 

 networking:
    auth:
      advancedAuthorization:
        allowUsers:
          - user-a
          - user-b
        denyUsers:
          - user-c
        allowGroups:
          - openshift-group-a
          - openshift-group-b
        denyGroups:
          - openshift-group-c
Copy to Clipboard
注意

denyUsers 和 denyGroup 类别中的用户将无法使用 Red Hat OpenShift Dev Spaces，并在尝试访问用户仪表板时看到警告。

身份验证

只有经过身份验证的 OpenShift 用户可以访问 Red Hat OpenShift Dev Spaces。网关 Pod 使用基于角色的访问控制(RBAC)子系统来确定开发人员是否有权访问云开发环境(CDE)。

CDE Gateway 容器检查开发人员的 Kubernetes 角色。如果其角色允许访问 CDE Pod，则允许与开发环境的连接。默认情况下，只有命名空间的所有者有权访问 CDE Pod。

重要

对命名空间中的资源的访问权限必须限制为拥有它的开发人员。授予另一个开发人员 读取访问权限 等同于共享开发人员凭据，应该避免。

安全上下文和安全上下文约束

Red Hat OpenShift Dev Spaces 在 CDE Pod 容器安全上下文的规格中添加 SETGID 和 SETUID 功能： 

"spec": {
  "containers": [
    "securityContext": {
            "allowPrivilegeEscalation": true,
            "capabilities": {
               "add": ["SETGID", "SETUID"],
               "drop": ["ALL","KILL","MKNOD"]
            },
            "readOnlyRootFilesystem": false,
            "runAsNonRoot": true,
            "runAsUser": 1001110000
   }
  ]
 }
Copy to Clipboard

这为用户提供了从 CDE 中构建容器镜像的功能。

默认情况下，Red Hat OpenShift Dev Spaces 将特定的 SecurityContextConstraint (SCC)分配给允许他们启动具有此类功能的 Pod 的用户。与默认 restricted SCC 相比，此 SCC 授予用户更多权限，但与 anyuid SCC 相比。此默认 SCC 在 OpenShift Dev Spaces 命名空间中预先创建，并命名为 container-build。

在 CheCluster 自定义资源中设置以下属性可防止向用户分配额外的功能和 SCC： 

spec:
  devEnvironments:
    disableContainerBuildCapabilities: true
Copy to Clipboard

资源配额和限值范围

资源配额和限值范围是 Kubernetes 功能，可用于帮助防止集群中的错误执行者和资源滥用。具体来说，它们允许您为 pod 和容器设置资源消耗限制。通过组合资源配额和限值范围，您可以强制执行特定于项目的策略，以防止不良的执行者消耗过量资源。

这些机制有助于提高 OpenShift 集群中的资源管理、稳定性和公平性。有关 资源配额和限值范围的更多详细信息 ， 请参阅 OpenShift 文档。

断开连接的环境

air-gapped OpenShift 断开连接的集群指的是从互联网或任何外部网络隔离的 OpenShift 集群。这种隔离通常是出于安全原因来防止敏感或关键系统免受潜在的网络威胁。在 air-gapped 环境中，集群无法访问外部软件仓库或 registry 来下载容器镜像、更新或依赖项。

Red Hat OpenShift Dev Spaces 支持，并可在受限环境中安装。官方文档 中提供了安装说明。

管理扩展

默认情况下，Red Hat OpenShift Dev Spaces 包括嵌入式 Open VSX registry，其中包含 Microsoft Visual Studio Code - 开源编辑器的一组有限的扩展。另外，集群管理员也可以在自定义资源中指定不同的插件 registry，例如 https://open-vsx.org 包含数千个扩展。它们也可以构建自定义 Open VSX 注册表。有关管理 IDE 扩展的更多详细信息，请参阅 官方文档。

重要

安装额外扩展会增加潜在的风险。要最小化这些风险，请确保只安装来自可靠源的扩展并定期更新它们。

Secrets

将敏感数据保存为用户命名空间机密中的 Kubernetes secret （如个人访问令牌(PAT)和 SSH 密钥）。

Git 存储库

在熟悉和您信任的 Git 存储库中操作至关重要。在将新依赖项合并到存储库中之前，请验证它们是否被维护，并定期发行更新以解决其代码中任何识别的安全漏洞。

返回顶部
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

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

让开源更具包容性

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

關於紅帽

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

Theme

© 2025 Red Hat