本指南全面介绍了 OpenShift Container Platform 中提供的容器安全措施，包括主机层、容器和编配层以及构建和应用程序层的解决方案。本指南包含以下信息：

容器将一个应用程序及其所有依赖项打包成单一镜像，可在不发生改变的情况下从开发环境提升到测试环境，再提升到生产环境。

容器提供不同环境间的一致性和多个部署目标：物理服务器、虚拟机 (VM) 和私有或公有云。

使用容器的一些好处包括：

深入阅读

本指南描述了容器解决方案堆栈中每个层的安全性的关键元素，同时还介绍了如何使用 OpenShift Container Platform 在不同阶段和每一层都使用 OpenShift Container Platform 来大规模创建、部署和管理容器。

深入阅读

容器允许您通过在单一主机上部署多个应用程序，使用内核和 docker 运行时来为每个容器启动，从而简化多租户部署。

您必须有一个可保护主机内核的操作系统（OS）并且相互保护容器的安全。在 Linux 中，容器只是一种特殊的进程，因此保护容器与保护任何运行的进程是一样的。容器应该以非 root 用户身份运行。建议降低权限级别或创建具有最少权限的容器。

由于 OpenShift Container Platform 在 Red Hat Enterprise Linux（RHEL）和 RHEL Atomic Host 上运行，以下概念默认应用于任何已部署的 OpenShift Container Platform 集群，并且是平台上确保容器安全的核心所在。

深入阅读

传统虚拟化也支持多租户，但方式与容器非常不同。虚拟化依赖于虚拟机监控程序启动虚拟机（VM），每个虚拟机都有自己的操作系统（OS），以及正在运行的应用程序及其依赖项。

使用 VM，虚拟机监控程序会将虚拟客户机相互隔离并与主机内核隔离。这样可减少可访问虚拟机监控程序的个人和进程，进而缩小物理服务器上的攻击面。尽管如此，仍必须对安全性进行监控：一个虚拟客户机可能使用虚拟机监控程序错误来访问另一个虚拟机或主机内核。当操作系统需要补丁时，它必须对所有使用该操作系统的虚拟机进行补丁。

容器可以在客户机虚拟机中运行，在有些用例中可能是需要的。例如，您可能在容器中部署传统应用程序，以便将某个应用程序转移到云端。但是，单一主机上的容器多租户提供了一个更加轻便、灵活且易于部署的解决方案。这种部署模型特别适合云原生应用程序。

深入阅读

应用程序和基础架构由随时可用的组件组成，许多组件都是开源软件包，如 Linux 操作系统、JBoss Web Server、PostgreSQL 和 Node.js。

这些软件包也有容器化版本可用。然而，您需要知道软件包最初来自哪里，是谁构建的，以及软件包中是否有恶意代码。

需要回答的一些问题包括：

深入阅读

容器扫描工具可利用不断更新的漏洞数据库，以确保始终了解容器内容的已知漏洞的最新信息。已知漏洞列表不断变化 ; 您必须在首次下载容器镜像时检查容器镜像的内容,并持续跟踪所有批准和部署的镜像的漏洞状态。

RHEL 提供了一个可插入的 API，以支持多个扫描仪。您还可以使用带有 OpenSCAP 的 Red Hat CloudForms 扫描容器镜像以了解安全问题。有关 RHEL 中 OpenSCAP 的一般信息，请参阅 Red Hat Enterprise Linux 安全指南 ，以及 Red Hat CloudForms 策略及侧写指南中有关 OpenSCAP 集成的具体内容。

OpenShift Container Platform 可让您在 CI/CD 过程中利用这些扫描程序。例如，您可以集成静态代码分析工具来测试源代码中的安全漏洞，并集成软件组成分析工具来标识开源库，以提供关于这些库的元数据，如已知漏洞。这在构建过程中进行了更详细的介绍。

OpenShift Container Platform 使用对象注解来扩展功能。外部工具（如漏洞扫描程序）可能会使用元数据为镜像对象添加注解，以汇总结果并控制 Pod 执行。本节描述了该注解的可识别格式，以便在控制台中可靠使用它来为用户显示有用的数据。

quality.images.openshift.io/<qualityType>.<providerId>: {}

quality.images.openshift.io/vulnerability.blackduck: {}
quality.images.openshift.io/vulnerability.jfrog: {}
quality.images.openshift.io/license.blackduck: {}
quality.images.openshift.io/vulnerability.openscap: {}

{
  "name": "OpenSCAP",
  "description": "OpenSCAP vulnerability score",
  "timestamp": "2016-09-08T05:04:46Z",
  "reference": "https://www.open-scap.org/930492",
  "compliant": true,
  "scannerVersion": "1.2",
  "summary": [
    { "label": "critical", "data": "4", "severityIndex": 3, "reference": null },
    { "label": "important", "data": "12", "severityIndex": 2, "reference": null },
    { "label": "moderate", "data": "8", "severityIndex": 1, "reference": null },
    { "label": "low", "data": "26", "severityIndex": 0, "reference": null }
  ]
}

{
  "name": "Red Hat Container Catalog",
  "description": "Container health index",
  "timestamp": "2016-09-08T05:04:46Z",
  "reference": "https://access.redhat.com/errata/RHBA-2016:1566",
  "compliant": null,
  "scannerVersion": "1.2",
  "summary": [
    { "label": "Health index", "data": "B", "severityIndex": 1, "reference": null }
  ]
}

$ oc annotate image <image> \
    quality.images.openshift.io/vulnerability.redhatcatalog='{ \
    "name": "Red Hat Container Catalog", \
    "description": "Container health index", \
    "timestamp": "2016-09-08T05:04:46Z", \
    "compliant": null, \
    "scannerVersion": "1.2", \
    "reference": "https://access.redhat.com/errata/RHBA-2016:1566", \
    "summary": "[ \
      { "label": "Health index", "data": "B", "severityIndex": 1, "reference": null } ]" }'

annotations:
  images.openshift.io/deny-execution: true

$ curl -X PATCH \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/merge-patch+json" \
  https://<openshift_server>:8443/oapi/v1/images/<image_id> \
  --data '{ <image_annotation> }'

{
"metadata": {
  "annotations": {
    "quality.images.openshift.io/vulnerability.redhatcatalog":
       "{ 'name': 'Red Hat Container Catalog', 'description': 'Container health index', 'timestamp': '2016-09-08T05:04:46Z', 'compliant': null, 'reference': 'https://access.redhat.com/errata/RHBA-2016:1566', 'summary': [{'label': 'Health index', 'data': '4', 'severityIndex': 1, 'reference': null}] }"
    }
  }
}

您可以使用一些工具来扫描和跟踪您下载和部署的容器镜像的内容。但是，容器镜像有很多公共来源。在使用公共容器 registry 时，您可以使用可信源添加一层保护。

在管理不可变容器时，消耗安全更新尤其重要。不可变容器是在运行时永远不会更改的容器。部署不可变容器时，,您不需要介入正在运行的容器来替换一个或多个二进制文件 ; 您可以重建并重新部署更新的容器镜像。

红帽的已认证镜像：

已知漏洞列表不断扩展，因此您必须一直跟踪部署的容器镜像的内容以及新下载的镜像。您可以使用红帽安全公告 (RHSA) 来提醒您红帽的已认证容器镜像中出现的任何新问题，并指引您找到更新的镜像。

深入阅读

红帽通过 Red Hat Registry （由红帽在 registry.redhat.io 托管的公共容器 registry）为红帽产品和合作伙伴提供经过认证的容器。Red Hat Container Catalog 可让您识别与 Red Hat Registry 提供的容器镜像关联的程序错误修复或安全公告。

红帽会监控容器内容以了解漏洞，并定期进行更新。当红帽发布安全更新（如 glibc、Drown 或 Dirty Cow 的修复程序）时，任何受影响的容器镜像也会被重建并推送到 Red Hat Registry。

红帽使用"健康索引"处理通过红帽容器目录提供的容器的安全风险。这些容器使用红帽提供的软件和勘误，旧的、过时的容器不安全，而全新容器则更安全。

为了说明容器的年龄，红帽容器目录使用一个等级系统。新鲜度等级是一个镜像可用的最旧、最严重的安全公告衡量标准。“A”比“F”状态更新。如需了解这个等级系统的更多详情，请参阅 Red Hat Container Catalog 内部使用的容器健康状态索引等级。

深入阅读

OpenShift Container Platform 包含 OpenShift Container Registry，它是一个与可用于管理容器镜像的平台集成的私有 registry。OpenShift Container Registry 提供基于角色的访问控制，供您管理谁可以拉取和推送哪些容器镜像。

OpenShift Container Platform 还支持与其他您可能已经使用的私有 registry 集成。

深入阅读

在容器环境中，软件构建过程是生命周期中应用程序代码与所需的运行时库集成的阶段。管理此构建过程是保护软件堆栈的关键。

使用 OpenShift Container Platform 作为容器构建的标准平台可保证构建环境的安全。遵循“一次构建，随处部署”的原则可确保构建过程的产品就是在生产环境中部署的产品。

保持容器的不可变性也是很重要的。您不应该修补运行中的容器，而应该重建并重新部署这些容器。

您可以使用 Source-to-Image (S2I) 将源代码和基础镜像组合起来。构建器镜像利用 S2I 使您的开发和运维团队能够就可重复生成的构建环境展开合作。

当开发人员使用构建镜像通过 Git 提交某个应用程序的代码时，OpenShift Container Platform 可以执行以下功能：

您可以使用 OpenShift Container Registry 管理对最终镜像的访问。S2I 和原生构建镜像会自动推送到 OpenShift Container Registry。

除了包含的用于 CI 的 Jenkins 外，您还可以使用 RESTful API 将您自己的构建和 CI 环境与 OpenShift Container Platform 集成，并使用与 API 兼容的镜像 registry。

深入阅读

在某些情况下，构建操作需要凭证才能访问依赖的资源，但这些凭证最好不要在通过构建生成的最终应用程序镜像中可用。您可以定义输入 secret 以实现这一目的。

例如，在构建 Node.js 应用程序时，您可以为 Node.js 模块设置私有镜像。要从该私有镜像下载模块，您必须为包含 URL、用户名和密码的构建提供自定义 .npmrc 文件。为安全起见，不应在应用程序镜像中公开您的凭证。

通过使用此示例场景，您可以在新 BuildConfig 中添加输入 secret：

深入阅读

您可以对容器镜像管理和构建过程进行设计以使用容器层，以便您可以分开控制。

例如，一个运维团队负责管理基础镜像，而架构师则负责管理中间件、运行时、数据库和其他解决方案。然后开发人员可以专注于应用程序层及编写代码。

由于每天都会识别出新的漏洞，因此您需要一直主动检查容器内容。要做到这一点，您应该将自动安全测试集成到构建或 CI 过程中。例如：

您的 CI 过程应该包含相应的策略，为构建标记出通过安全扫描发现的问题，以便您的团队能够采取适当行动来解决这些问题。您应该为自定义构建容器签名，以确保在构建和部署之间不会修改任何内容。

深入阅读

如果在构建过程中发生某种情况，或者部署了镜像后发现一个漏洞，您可以使用基于策略的自动化部署工具进行修复。您可以使用触发器来重建和替换镜像，而不是修补正在运行的容器，我们不建议这样做。

例如，您使用三个容器镜像层构建了一个应用程序：核心、中间件和应用程序。由于在核心镜像中发现了一个问题，该镜像被重建。构建完成后，镜像被推送到 OpenShift Container Registry。OpenShift Container Platform 检测到镜像已更改，并根据定义的触发器自动重建并部署应用程序镜像。这一更改包含了固定的库，并确保产品代码与最新镜像是一致的。

oc set triggers 命令可以用来为部署配置设置部署触发器。例如，在名为 frontend 的部署配置中设置 ImageChangeTrigger:

$ oc set triggers dc/frontend \
    --from-image=myproject/origin-ruby-sample:latest \
    -c helloworld

深入阅读

务必要确保实际部署了所需的镜像，确保它们来自可信源，且未被更改。加密签名提供了这一保证。OpenShift Container Platform 可让集群管理员应用广泛或狭窄的安全策略，以反应部署环境和安全要求。该策略由两个参数定义：

使用这些策略参数，可以将 registry 或 registry 的部分（甚至单独的镜像）列入白名单（接受）、列入黑名单（拒绝）或者使用可信公钥定义信任关系，以确保以加密方式验证源。该策略规则应用于节点。策略可以在所有节点中统一应用，或针对不同的节点工作负载（例如：构建、区域或环境）加以应用。

{
    "default": [{"type": "reject"}],
    "transports": {
        "docker": {
            "access.redhat.com": [
                {
                    "type": "signedBy",
                    "keyType": "GPGKeys",
                    "keyPath": "/etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release"
                }
            ]
        },
        "atomic": {
            "172.30.1.1:5000/openshift": [
                {
                    "type": "signedBy",
                    "keyType": "GPGKeys",
                    "keyPath": "/etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release"
                }
            ],
            "172.30.1.1:5000/production": [
                {
                    "type": "signedBy",
                    "keyType": "GPGKeys",
                    "keyPath": "/etc/pki/example.com/pubkey"
                }
            ],
            "172.30.1.1:5000": [{"type": "insecureAcceptAnything"}]
        }
    }
}

该策略可以在节点上保存为 /etc/containers/policy.json。这个示例强制执行以下规则：

有关配置主机的具体步骤，请参阅启用镜像签名支持。更多信息，请参见以下部分签名传输。有关镜像签名策略的详情，请参阅 Signature 验证策略文件格式源代码文档。

docker:
    access.redhat.com:
        sigstore: https://access.redhat.com/webassets/docker/content/sigstore

Secret 对象类型提供了一种机制来保存敏感信息，如密码、OpenShift Container Platform 客户端配置文件、dockercfg 文件和私有源存储库凭证。Secret 将敏感内容与 Pod 分离。您可以使用卷插件将 secret 信息挂载到容器中，系统也可以使用 secret 代表 Pod 执行操作。

例如，使用 web 控制台将 secret 添加到部署配置中，以便其能够访问私有镜像存储库：

ConfigMap 与 secret 类似，但设计为能支持与不含敏感信息的字符串配合使用。ConfigMap 对象包含配置数据的键值对，这些数据可在 Pod 中消耗或用于存储控制器等系统组件的配置数据。

深入阅读

您可以使用 安全性上下文约束 (SCC)来定义 Pod 运行（容器集合）必须满足的一组条件，以便其能被系统接受。

可由 SCC 管理的一些方面包括：

如果您有所需的权限，您可以将默认 SCC 策略调整为更宽松。

深入阅读

您可以将自己的持续部署 (CD) 工具与 OpenShift Container Platform 集成。

利用 CI/CD 和 OpenShift Container Platform，您可以自动执行重建应用程序的过程，以纳入最新的修复、测试，并确保它在环境中随处部署。

API 是大规模自动化容器管理的关键。API 用于：

深入阅读

OpenShift Container Platform 的框架中有多个组件，它们使用基于 REST 的 HTTPS 通信，通过 TLS 证书利用加密功能。OpenShift Container Platform 基于 Ansible 的安装程序在安装过程中配置这些证书。生成此流量的一些主要组件如下：

openshift_master_named_certificates=[{"certfile": "/path/on/host/to/custom1.crt", "keyfile": "/path/on/host/to/custom1.key", "cafile": "/path/on/host/to/custom-ca1.crt"}]

OpenShift Container Platform 使用软件定义网络 (SDN) 来提供一个统一的集群网络，它允许集群中的不同容器相互间进行通信。

使用网络命名空间可以隔离 Pod 网络。每个 pod 都有自己的 IP 和端口范围来绑定，从而将 pod 网络相互隔离。来自不同项目的 Pod 不能与不同项目的 Pod 和服务互相发送或接收数据包。您可以使用它来隔离集群中的开发人员、测试和生产环境。

OpenShift Container Platform 还提供使用路由器或防火墙方法控制出口流量的功能。例如，您可以使用 IP 白名单来控制对数据库的访问。

深入阅读

OpenShift Container Platform 可让您将单一集群上的网络流量分段，以创建多租户集群将用户、团队、应用程序和环境隔离。

例如，若要在集群中隔离项目网络，或反之，请运行：

$ oc adm pod-network isolate-projects <project1> <project2>

在上例中，<project1> 和 <project2> 中的所有 pod 和服务都无法从集群中的其他非全局项目访问任何 pod 和服务，反之亦然。

容器对于无状态和有状态的应用程序都很有用。保护附加存储是保护有状态服务的一个关键元素。

OpenShift Container Platform 为多种存储提供插件，包括 NFS、AWS Elastic Block Stores(EBS)、GCE Persistent Disks、GlusterFS、iSCSI、RADOS(Ceph)和 Cinder。对于相互通信的所有 OpenShift Container Platform 组件，传输中的数据都通过 HTTPS 来加密。

您可以通过存储类型所支持的任何方式在主机上挂载 PersistentVolume (PV)。不同的存储类型具有不同的功能，每个 PV 的访问模式可以被设置为特定卷支持的特定模式。

例如：NFS 可以支持多个读/写客户端，但一个特定的 NFS PV 可能会以只读方式导出。每个 PV 都有自己的一组访问模式来描述特定 PV 的功能，如 ReadWriteOnce、ReadOnlyMany 和 ReadWriteMany。

深入阅读

对于 NFS、Ceph 和 Gluster 等共享存储供应商，PV 将组 ID（GID）注册为 PV 资源上的注解。然后，当 Pod 声明 PV 时，注解的 GID 会添加到 Pod 的补充组中，为该 pod 授予共享存储内容的访问权限。

深入阅读

对于 AWS Elastic Block Store (EBS)、GCE Persistent Disk 和 iSCSI 等块存储供应商，OpenShift Container Platform 使用 SELinux 功能为非特权 Pod 保护挂载卷的根目录，从而使所挂载的卷由与其关联的容器所有并只对该容器可见。

深入阅读

除了本指南其他部分提到的安全措施外，监控和审核 OpenShift Container Platform 集群的能力是防止集群及其用户遭到不当使用的重要部分。

有两个主要的集群级别信息来源可用来实现这一目的：事件和日志记录。

建议集群管理员熟悉 Event 资源类型，并查看事件列表以确定值得关注的事件。根据 master 控制器和插件配置，通常会比这里列出的事件类型更多。

事件与命名空间关联，可以是与它们相关的资源的命名空间，对于集群事件，也可以是 default 命名空间。Default 命名空间包含与监控或审核集群相关的事件，如 Node 事件和与基础架构组件相关的资源事件。

Master API 和 oc 命令不通过提供参数来将事件列表的范围限定为与节点相关的事件。一个简单的方法是使用 grep：

$ oc get event -n default | grep Node
1h         20h         3         origin-node-1.example.local   Node      Normal    NodeHasDiskPressure   ...

更灵活的方法是以其他工具可以处理的形式输出事件。例如，以下示例针对 JSON 输出使用 jq 工具以仅提取 NodeHasDiskPressure 事件：

$ oc get events -n default -o json \
  | jq '.items[] | select(.involvedObject.kind == "Node" and .reason == "NodeHasDiskPressure")'

{
  "apiVersion": "v1",
  "count": 3,
  "involvedObject": {
    "kind": "Node",
    "name": "origin-node-1.example.local",
    "uid": "origin-node-1.example.local"
  },
  "kind": "Event",
  "reason": "NodeHasDiskPressure",
  ...
}

与资源创建、修改或删除相关的事件也很适合用来检测到集群误用情况。例如，以下查询可以用来查找过度拉取镜像：

$ oc get events --all-namespaces -o json \
  | jq '[.items[] | select(.involvedObject.kind == "Pod" and .reason == "Pulling")] | length'

4

本节论述了集群中生成的操作日志的类型。

2017-10-17T13:12:17.635085787Z AUDIT: id="410eda6b-88d4-4491-87ff-394804ca69a1" ip="192.168.122.156" method="GET" user="system:admin" groups="\"system:cluster-admins\",\"system:authenticated\"" as="<self>" asgroups="<lookup>" namespace="<none>" uri="/api/v1/nodes"
2017-10-17T13:12:17.636081056Z AUDIT: id="410eda6b-88d4-4491-87ff-394804ca69a1" response="200"

$ tail -5000 /var/lib/origin/audit-ocp.log \
  | grep -Po 'response="..."' \
  | sort | uniq -c | sort -rn

   3288 response="200"
      8 response="404"
      6 response="201"

$ tail -5000 /var/lib/origin/audit-ocp.log \
  | grep -Po ' user="(.*?)(?<!\\)"' \
  | sort | uniq -c | sort -rn | head -10

  976  user="system:openshift-master"
  270  user="system:node:origin-node-1.example.local"
  270  user="system:node:origin-master.example.local"
   66  user="system:anonymous"
   32  user="system:serviceaccount:kube-system:cronjob-controller"
   24  user="system:serviceaccount:kube-system:pod-garbage-collector"
   18  user="system:serviceaccount:kube-system:endpoint-controller"
   14  user="system:serviceaccount:openshift-infra:serviceaccount-pull-secrets-controller"
   11  user="test user"
    4  user="test \" user"