ContainerPlatform4.7
安全性与合规性
了解和管理OpenShiftContainerPlatform的安全性
LastUpdated:2022-02-07
OpenShiftContainerPlatform4.7安全性与合规性
了解和管理OpenShiftContainerPlatform的安全性
Enteryourfirstnamehere.Enteryoursurnamehere.Enteranisation'snamehere.Enteranisationaldivisionhere.Enteryouremailaddresshere.
法律通告
Copyright©2022|YouneedtochangetheHOLDERentityintheenUS/Security_pliance.entfile|.
ThetextofandillustrationsinthisdocumentarelicensedbyRedHatunderaCreativeCommonsAttribution–ShareAlike3.0Unportedlicense("CC-BY-SA").AnexplanationofCC-BY-SAisavailableat/licenses/by-sa/3.0/.InordancewithCC-BY-SA,ifyoudistributethisdocumentoranadaptationofit,youmustprovidetheURLfortheoriginalversion.
RedHat,asthelicensorofthisdocument,waivestherighttoenforce,andagreesnottoassert,Section4dofCC-BY-SAtothefullestextentpermittedbyapplicablelaw.
RedHat,RedHatEnterpriseLinux,theShadowmanlogo,theRedHatlogo,JBoss,OpenShift,Fedora,theInfinitylogo,andRHCEaretrademarksofRedHat,Inc.,registeredintheUnitedStatesandothercountries.
Linux®istheregisteredtrademarkofLinusTorvaldsintheUnitedStatesandothercountries.
Java®isaregisteredtrademarkofOracleand/oritsaffiliates.
XFS®isatrademarkofSiliconGraphicsInternationalCorp.oritssubsidiariesintheUnitedStatesand/orothercountries.
MySQL®isaregisteredtrademarkofMySQLABintheUnitedStates,theEuropeanUnionandothercountries.
Node.js®isanofficialtrademarkofJoyent.RedHatisnotformallyrelatedtoorendorsedbytheofficialJoyentNode.jsopensourcemercialproject.
TheOpenStack®WordMarkandOpenStacklogoareeitherregisteredtrademarks/servicemarksortrademarks/servicemarksoftheOpenStackFoundation,intheUnitedStatesandothercountriesandareusedwiththeOpenStackFoundation'spermission.Wearenotaffiliatedwith,endorsedorsponsoredbytheOpenStackFoundation,orthemunity.
Allothertrademarksarethepropertyoftheirrespectiveowners.
摘要
本文档讨论容器安全性、配置证书和启用加密以便帮助保护集群的安全。
目录 目录 第...1.章...O..P.E.N..S.H..I.F.T..C.O..N..T.A..IN..E.R..P..L.A.T..F.O..R.M..安...全..和..合..规..性.....................................................8............. 1.1.安全概述
8 容器安全性
8 Auditing
8 证书
8 加密数据
9 漏洞扫描
9 1.2.合规性概述
9 合规性检查
9 文件完整性检查
9 1.3.其他资源
9 第...2..章..容..器...安..全..性............................................................................................1.0............. 2.1.了解容器安全性 10 2.1.1.什么是容器？ 10 2.1.2.OpenShiftContainerPlatform是什么？ 11 2.2.了解主机和虚拟机安全性 11 2.2.1.保护RedHatEnterpriseLinuxCoreOS(RHCOS)上的容器 11 2.2.2.虚拟化和容器比较 13 2.2.3.保护OpenShiftContainerPlatform 13 2.3.强化RHCOS 13 2.3.1.在RHCOS中选择要强化的功能 14 2.3.2.选择如何强化RHCOS 14 2.3.2.1.安装前强化 14 2.3.2.2.安装过程中强化 14 2.3.2.3.集群运行后强化 14 2.4.容器镜像签名 15 2.4.1.为RedHatContainerregistry启用签名验证 15 2.4.2.验证签名验证配置 18 2.4.3.其他资源 22 2.5.了解合规性 22 2.5.1.了解合规性及风险管理 23 2.6.保护容器内容 23 2.6.1.确保容器内安全 23 2.6.2.使用UBI创建可重新分发的镜像 23 2.6.3.RHEL中的安全扫描 24 2.6.3.1.扫描OpenShift镜像 24 2.6.4.集成外部扫描 24 2.6.4.1.镜像元数据 24 2.6.4.1.1.注解键示例 25 2.6.4.1.2.注解值示例 26 2.6.4.2.为镜像对象添加注解 27 2.6.4.2.1.注解CLI命令示例 27 2.6.4.3.控制Pod执行 27 2.6.4.3.1.注解示例 27 2.6.4.4.集成参考 27 2.6.4.4.1.RESTAPI调用示例 27 2.7.安全地使用容器REGISTRY 28 2.7.1.知道容器来自哪里？ 28 2.7.2.不可变和已认证的容器 28 2.7.3.从红帽Registry和生态系统目录获取容器 29
1 OpenShiftContainerPlatform4.7安全性与合规性 2.7.4.OpenShiftContainerRegistry 29 2.7.5.使用RedHatQuay存储容器 29 2.8.保护构建过程 30 2.8.1.一次构建，随处部署 30 2.8.2.管理构建 30 2.8.3.在构建期间保护输入 31 2.8.4.设计构建过程 32 2.8.5.构建Knative无服务器应用程序 33 2.8.6.其他资源 33 2.9.部署容器 33 2.9.1.使用触发器控制容器部署 33 2.9.2.控制可以部署的镜像源 34 2.9.3.使用签名传输 35 2.9.4.创建secret和配置映射 36 2.9.5.自动化持续部署 36 2.10.保护容器平台 37 2.10.1.使用多租户隔离容器 37 2.10.2.使用准入插件保护controlplane 37 2.10.2.1.安全性上下文约束(SCC) 38 2.10.2.2.为服务帐户授予角色 38 2.10.3.认证和授权 38 2.10.3.1.使用OAuth控制访问 38 2.10.3.2.API访问控制和管理 38 2.10.3.3.红帽单点登录 39 2.10.3.4.安全自助服务Web控制台 39 2.10.4.为平台管理证书 39 2.10.4.1.配置自定义证书 39 2.11.保护网络 40 2.11.1.使用网络命名空间 40 2.11.2.使用网络策略隔离Pod 40 2.11.3.使用多个Pod网络 40 2.11.4.隔离应用程序 40 2.11.5.保护入口流量 41 2.11.6.保护出口流量 41 2.12.保护附加存储 41 2.12.1.持久性卷插件 41 2.12.2.共享存储 42 2.12.3.块存储 42 2.13.监控集群事件和日志 42 2.13.1.监视集群事件 42 2.13.2.日志记录 43 2.13.3.审计日志 44 第...3..章..配...置..证..书..............................................................................................4.5............. 3.1.替换默认入口证书 45 3.1.1.了解默认入口证书 45 3.1.2.替换默认入口证书 45 3.2.添加API服务器证书 46 3.2.1.向API服务器添加指定名称的证书 46 3.3.使用服务提供的证书SECRET保护服务流量 48 3.3.1.了解服务用证书 48 3.3.2.添加服务证书 48 3.3.3.将服务CA捆绑包添加到配置映射中 49
2 目录 3.3.4.将服务CA捆绑包添加到API服务 50 3.3.5.将服务CA捆绑包添加到自定义资源定义中 51 3.3.6.将服务CA捆绑包添加到变异的webhook配置中 52 3.3.7.将服务CA捆绑包添加到验证webhook配置中 52 3.3.8.手动轮转生成的服务证书 53 3.3.9.手动轮转服务CA证书 54 第...4..章..证...书..类..型..和..描..述........................................................................................5.6............. 4.1.API服务器的用户提供的证书 56 4.1.1.用途 56 4.1.2.位置 56 4.1.3.管理 56 4.1.4.过期 56 4.1.5.自定义 56 其他资源 56 4.2.代理证书 56 4.2.1.用途 56 其他资源 57 4.2.2.在安装过程中管理代理证书 57 4.2.3.位置 57 4.2.4.过期 57 4.2.5.服务 58 4.2.6.管理 58 4.2.7.自定义 58 4.2.8.续订 59 4.3.服务CA证书 59 4.3.1.用途 59 4.3.2.过期 59 4.3.3.管理 60 4.3.4.服务 60 其他资源 60 4.4.节点证书 61 4.4.1.用途 61 4.4.2.管理 61 其他资源 61 4.5.BOOTSTRAP证书 61 4.5.1.用途 61 4.5.2.管理 61 4.5.3.过期 61 4.5.4.自定义 61 4.6.ETCD证书 61 4.6.1.用途 61 4.6.2.过期 61 4.6.3.管理 62 4.6.4.服务 62 其他资源 62 4.7.OLM证书 62 4.7.1.管理 62 4.8.用户提供的默认入口证书 62 4.8.1.用途 62 4.8.2.位置 63 4.8.3.管理 63 4.8.4.过期 63
3 OpenShiftContainerPlatform4.7安全性与合规性 4.8.5.服务 63 4.8.6.自定义 63 其他资源 63 4.9.入口证书（INGRESSCERTIFICATE） 63 4.9.1.用途 63 4.9.2.位置 63 4.9.3.工作流 64 4.9.4.过期 65 4.9.5.服务 65 4.9.6.管理 65 4.9.7.续订 66 4.10.监控和OPENSHIFTLOGGINGOPERATOR组件证书 66 4.10.1.过期 66 4.10.2.管理 66 4.11.CONTROLPLANE证书 66 4.11.1.位置 66 4.11.2.管理 66 第...5..章..C..O..M..P.L.I.A.N..C..E..O.P..E.R.A..T.O..R...........................................................................6.7............. 5.1.COMPLIANCEOPERATOR发行注记 67 5.1.1.OpenShiftComplianceOperator0.1.47 67 5.1.1.1.新功能及功能增强 67 5.1.1.2.程序错误修复 67 5.1.2.OpenShiftComplianceOperator0.1.44 67 5.1.2.1.新功能及功能增强 67 5.1.2.2.模板和变量使用 68 5.1.2.3.程序错误修复 68 5.1.3.ComplianceOperator0.1.39发行注记 69 5.1.3.1.新功能及功能增强 69 5.1.4.其他资源 69 5.2.支持的合规性配置集 69 5.2.1.合规配置集 69 5.2.2.其他资源 71 5.3.安装COMPLIANCEOPERATOR 71 5.3.1.通过Web控制台安装ComplianceOperator 71 5.3.2.使用CLI安装ComplianceOperator 71 5.3.3.其他资源 73 5.4.COMPLIANCEOPERATOR扫描 73 5.4.1.运行合规性扫描 73 5.4.2.在worker节点上调度结果服务器pod 75 5.5.了解COMPLIANCEOPERATOR 77 5.5.1.ComplianceOperator配置集 77 5.6.管理COMPLIANCEOPERATOR 79 5.6.1.更新安全性内容 80 5.6.2.使用镜像流 80 5.6.3.ProfileBundleCR示例 81 5.6.4.其他资源 82 5.7.定制COMPLIANCEOPERATOR 82 5.7.1.使用定制配置集 82 5.8.检索COMPLIANCEOPERATOR原始结果 84 5.8.1.从持久性卷中获取ComplianceOperator原始结果 84 5.9.管理COMPLIANCEOPERATOR补救 85 5.9.1.审阅补救 85
4 目录 5.9.2.应用补救 86 5.9.3.手动补救平台检查 87 5.9.4.更新补救 88 5.9.5.取消应用补救 89 5.9.6.删除KubeletConfig补救 89 5.9.7.不一致的补救 91 5.9.8.过滤失败的合规性检查结果 91 5.9.9.其他资源 92 5.10.执行高级COMPLIANCEOPERATOR任务 92 5.10.1.直接使用ComplianceSuite和ComplianceScan对象 92 5.10.2.使用原始定制配置集 92 5.10.3.执行重新扫描 93 5.10.4.为结果设置自定义存储大小 94 5.10.4.1.使用自定义结果存储值 94 5.10.5.应用套件扫描生成的补救 94 5.10.6.自动更新补救 95 5.11.对COMPLIANCEOPERATOR进行故障排除 95 5.11.1.扫描剖析 96 5.11.1.1.合规性源 96 5.11.1.2.ScanSetting和ScanSettingBinding对象生命周期和调试 96 5.11.1.3.ComplianceSuite自定义资源生命周期和调试 97 5.11.1.4.ComplianceScan自定义资源生命周期和调试 97 5.11.1.4.1.待处理阶段 97 5.11.1.4.2.启动阶段 97 5.11.1.4.3.运行阶段 98 5.11.1.4.4.聚合阶段 99 5.11.1.4.5.完成阶段 100 5.11.1.5.ComplianceRemediation控制器生命周期和调试 100 5.11.1.6.有用的标签 101 5.11.2.获取支持 101 5.12.卸载COMPLIANCEOPERATOR 102 5.12.1.从OpenShiftContainerPlatform卸载OpenShiftComplianceOperator 102 第...6..章...F.IL..E..IN..T.E..G.R..IT..Y..O.P..E.R..A.T.O..R........................................................................10..4............. 6.1.FILEINTEGRITYOPERATOR发行注记 104 6.1.1.OpenShiftFileIntegrityOperator0.1.22 104 6.1.1.1.程序错误修复 104 6.1.2.OpenShiftFileIntegrityOperator0.1.21 104 6.1.2.1.新功能及功能增强 104 6.1.2.2.程序错误修复 104 6.1.3.其他资源 105 6.2.安装FILEINTEGRITYOPERATOR 105 6.2.1.使用Web控制台安装FileIntegrityOperator 105 6.2.2.使用CLI安装FileIntegrityOperator 105 6.2.3.其他资源 106 6.3.了解FILEINTEGRITYOPERATOR 107 6.3.1.了解FileIntegrity自定义资源 107 6.3.2.检查FileIntegrity自定义资源状态 107 6.3.3.FileIntegrity自定义资源阶段 107 6.3.4.了解FileIntegrityNodeStatuses对象 108 6.3.5.FileIntegrityNodeStatusCR状态类型 109 6.3.5.1.FileIntegrityNodeStatusCR成功示例 109 6.3.5.2.FileIntegrityNodeStatusCR失败状态示例 109
5 OpenShiftContainerPlatform4.7安全性与合规性 6.3.6.了解事件 111 6.4.配置自定义FILEINTEGRITYOPERATOR 112 6.4.1.查看FileIntegrity对象属性 112 6.4.2.重要属性 112 6.4.3.检查默认配置 113 6.4.4.了解默认的FileIntegrityOperator配置 113 6.4.5.提供自定义AIDE配置 114 6.4.6.定义自定义FileIntegrityOperator配置 114 6.4.7.更改自定义文件完整性配置 115 6.5.执行高级自定义FILEINTEGRITYOPERATOR任务 116 6.5.1.重新初始化数据库 116 6.5.2.机器配置集成 116 6.5.3.探索守护进程集 116 6.6.对FILEINTEGRITYOPERATOR进行故障排除 117 6.6.1.常规故障排除 117 6.6.2.检查AIDE配置 117 6.6.3.确定FileIntegrity对象的阶段 117 6.6.4.确定守护进程集的Pod是否在预期节点上运行 117 第...7..章..查..看...审..计..日..志..........................................................................................11.9............. 7.1.关于API审计日志 119 7.2.查看审计日志 120 7.3.过滤审计日志 123 7.4.收集审计日志 124 7.5.其他资源 124 第...8..章..配...置..审..计..日..志..策..略.....................................................................................1.2.5............. 8.1.关于审计日志策略配置集 125 8.2.配置审计日志策略 125 第...9..章..配...置..T..L.S..安..全..配..置..集..................................................................................1.2.7............. 9.1.了解TLS安全配置集 127 9.2.查看TLS安全配置集详情 128 9.3.为INGRESSCONTROLLER配置TLS安全配置集 130 9.4.为CONTROLPLANE配置TLS安全配置集 132 第...1.0..章..配..置...S.E..C.C..O..M..P.配...置..集..............................................................................1.3.5............. 10.1.配置默认SECCOMP配置集 135 10.2.配置自定义SECCOMP配置集 135 10.2.1.设置自定义p配置集 135 10.2.2.将自定义p配置集应用到工作负载 136 10.3.其他资源 136 第...1.1.章...允..许..从..其..他..主..机..对...A..P.I.服..务..器...进..行..基..于...J.A.V..A.S..C.R..IP..T..的..访..问............................................1.3.7............. 11.1.允许从其他主机对API服务器进行基于JAVASCRIPT的访问 137 第...1.2.章...加..密...E.T..C.D..数..据......................................................................................1.3.9............. 12.1.关于ETCD加密 139 12.2.启用ETCD加密 139 12.3.禁用ETCD加密 140 第...1.3..章..对...P.O..D..进..行..安..全...漏..洞..扫..描............................................................................1.4.3............. 13.1.运行CONTAINERSECURITYOPERATOR 143 13.2.通过CLI查询镜像安全漏洞 145
6 目录
7 OpenShiftContainerPlatform4.7安全性与合规性 第1章OPENSHIFTCONTAINERPLATFORM安全和合规性 1.1.安全概述 了解如何正确保护OpenShiftContainerPlatform集群的各个方面非常重要。
容器安全性了解OpenShiftContainerPlatform安全性的良好起点是回顾了解容器安全性中的概念。
本节和接下来的章节介绍了OpenShiftContainerPlatform中提供的容器安全措施，包括主机层、容器和编配层以及构建和应用程序层的解决方案。
这些部分还包括有关以下主题的信息： 为什么容器安全性很重要，以及它与现有安全标准相比较的情况。
哪些容器安全措施是由主机（RHCOS和RHEL）层提供的，哪些是由OpenShiftContainerPlatform提供的。
如何评估您的容器内容和漏洞来源。
如何设计您的构建和部署过程，以主动检查容器的内容。
如何通过身份验证和授权控制对容器的访问。
如何在OpenShiftContainerPlatform中保护网络和附加存储。
用于API管理和SSO的容器化解决方案。
AuditingOpenShiftContainerPlatformauditing（审计）提供一组安全相关的按时间排序的记录，记录各个用户、管理员或其他系统组件影响系统的一系列活动。
管理员可以配置审计日志策略，并查看审计日志。
证书证书供各种组件用于验证对集群的访问。
管理员可以替换默认入口证书、添加API服务器证书或添加服务证书。
您还可以查看集群使用的证书类型的更多详情：API服务器的用户提供的证书代理证书服务CA证书节点证书Bootstrap证书etcd证书olm证书用户提供的默认入口证书入口证书（Ingresscertificate）监控和集群日志记录Operator组件证书
8 第1章OPENSHIFTCONTAINERPLATFORM安全和合规性Controlplane证书 加密数据您可以为集群启用etcd加密以提供额外的数据安全层。
例如，如果etcd备份暴露给不应该获得这个数据的人员，它会帮助保护敏感数据。
漏洞扫描管理员可以使用ContainerSecurityOperator(CSO)来运行漏洞扫描，并查看有关检测到的漏洞的信息。
1.2.合规性概述 对于许多OpenShiftContainerPlatform客户，在将任何系统投入生产前需要达到一定级别的法规就绪状态或合规性。
这种法规就绪性可通过国家标准、行业标准或组织的企业管理框架来实施。
合规性检查管理员可以使用ComplianceOperator运行合规性扫描，并为发现的问题推荐补救。
文件完整性检查管理员可以使用FileIntegrityOperator在集群节点上持续运行文件完整性检查，并提供已修改的文件日志。
1.3.其他资源 了解身份验证配置内部OAuth服务器了解身份提供程序配置使用RBAC定义和应用权限管理安全性上下文约束
9 OpenShiftContainerPlatform4.7安全性与合规性 第2章容器安全性 2.1.了解容器安全性 保护容器化应用程序需要依赖于多个级别的安全性： 容器安全性从可信基础容器镜像开始，一直到经过您的CI/CD管道的容器构建过程。
重要 默认情况下，镜像流不会自动更新。
这个默认行为可能会造成安全问题，因为镜像流引用的镜像的安全更新不会自动进行。
有关如何覆盖此默认行为的详情，请参阅配置定期导入imagestreamtag。
部署容器时，其安全性取决于它运行在安全的操作系统和网络上，并在容器本身和与之交互的用户和主机之间建立明确界限。
持续安全性取决于能够扫描容器镜像以获取漏洞，并具有高效的方法来更正和替换有漏洞的镜像。
除了OpenShiftContainerPlatform等平台提供的开箱即用的功能外，您的机构可能会有自己的安全需求。
在将OpenShiftContainerPlatform放入数据中心之前，可能需要进行一定程度的合规性验证。
同样，您可能需要将自己的代理、专用硬件驱动程序或加密功能添加到OpenShiftContainerPlatform中，才能满足您机构的安全标准。
本指南全面介绍了OpenShiftContainerPlatform中提供的容器安全措施，包括主机层、容器和编配层以及构建和应用程序层的解决方案。
然后，它会指引您参考特定的OpenShiftContainerPlatform文档以帮助您实现这些安全措施。
本指南包含以下信息： 为什么容器安全性很重要，以及它与现有安全标准相比较的情况。
哪些容器安全措施是由主机（RHCOS和RHEL）层提供的，哪些是由OpenShiftContainerPlatform提供的。
如何评估您的容器内容和漏洞来源。
如何设计您的构建和部署过程，以主动检查容器的内容。
如何通过身份验证和授权控制对容器的访问。
如何在OpenShiftContainerPlatform中保护网络和附加存储。
用于API管理和SSO的容器化解决方案。
本指南的目的是了解将OpenShiftContainerPlatform用于容器化工作负载的极大安全优势，以及整个红帽生态系统在提供和保持容器安全方面发挥的作用。
它还将帮助您了解如何与OpenShiftContainerPlatform互动以实现您机构的安全目标。
2.1.1.什么是容器？ 容器将一个应用程序及其所有依赖项打包成单一镜像，可在不发生改变的情况下从开发环境提升到测试环境，再提升到生产环境。
容器可能是大型应用程序的一部分，与其他容器紧密合作。
10 第2章容器安全性 容器提供不同环境间的一致性和多个部署目标：物理服务器、虚拟机(VM)和私有或公有云。
使用容器的一些好处包括： 基础架构 在共享的Linux操作系统内核上将应用程序进程沙盒化 与虚拟机相比更简单、更轻便且密度更高 可在不同环境间移植 应用程序将我的应用程序及其所有依赖项打包 部署到任意环境只需几秒并启用CI/CD轻松访问和共享容器化组件 请参阅红帽客户门户中的了解Linux容器以查找更多有关Linux容器的信息。
如需了解有关RHEL容器工具的信息，请参阅RHEL产品文档中的构建、运行和管理容器。
2.1.2.OpenShiftContainerPlatform是什么？ OpenShiftContainerPlatform等平台的任务是自动化部署、运行和管理容器化应用程序。
作为核心功能，OpenShiftContainerPlatform依赖于es项目来提供在可扩展数据中心跨许多节点编配容器的引擎。
es是一个项目，可使用不同的操作系统和附加组件来运行，它们不提供项目的支持性保证。
因此，不同es平台的安全性可能会有所不同。
OpenShiftContainerPlatform旨在锁定es安全性，并将平台与各种扩展组件集成。
为实现这一目标，OpenShiftContainerPlatform利用了广泛的红帽开源技术生态系统，包括操作系统、身份验证、存储、网络、开发工具、基础容器镜像和其他许多组件。
OpenShiftContainerPlatform可以利用红帽的经验，发现平台本身以及在平台上运行的容器化应用程序中存在的漏洞并快速部署修复程序。
红帽的经验还涉及到在新组件可用后高效地将它们与OpenShiftContainerPlatform集成，以及根据各个客户的需求对技术进行调整。
其他资源 OpenShiftContainerPlatform架构 OpenShift安全性指南 2.2.了解主机和虚拟机安全性 容器和虚拟机都提供了将主机上运行的应用程序与操作系统分开的方法。
了解OpenShiftContainerPlatform使用的RHCOS操作系统将帮助您理解主机系统如何保护容器和主机不受彼此影响。
2.2.1.保护RedHatEnterpriseLinuxCoreOS(RHCOS)上的容器 容器简化了将许多应用程序部署在同一主机上运行的操作，每个容器启动都使用相同的内核和容器运行时。
应用程序可以归很多用户所有，并且由于是保持独立的，他们可以毫无问题地同时运行这些应用程序的不同版本甚至不兼容的版本。
在Linux中，容器只是一种特殊的进程，因此在很多方面，保护容器与保护任何其他运行的进程类似。
运 11 OpenShiftContainerPlatform4.7安全性与合规性 在Linux中，容器只是一种特殊的进程，因此在很多方面，保护容器与保护任何其他运行的进程类似。
运行容器的环境始于操作系统，它可以保护主机内核不受容器和主机上运行的其他进程的影响，同时还可以保护容器不受彼此的影响。
由于OpenShiftContainerPlatform4.7在RHCOS主机上运行，同时可选择使用RedHatEnterpriseLinux(RHEL)作为worker节点，因此以下概念将默认应用于任何已部署的OpenShiftContainerPlatform集群。
这些RHEL安全功能是确保以更加安全的方式在OpenShift中运行容器的核心所在： Linux命名空间支持创建特定全局系统资源的抽象集，使其显示为一个实例，独立于命名空间中的进程。
因此，几个容器可以同时使用相同的计算资源，而不会产生冲突。
默认情况下独立于主机的容器命名空间包括挂载表、进程表、网络接口、用户、控制组、UTS和IPC命名空间。
需要直接访问主机命名空间的容器需要具有升级权限才能请求该访问权限。
如需了解有关命名空间类型的详细信息，请参阅RHEL7容器文档中的红帽系统中的容器概述。
SELinux提供了额外一层安全性，可以使容器相互隔离并与主机隔离。
SELinux允许管理员为每个用户、应用程序、进程和文件实行强制访问控制(MAC)。
CGroups（控制组）限制、说明和隔离一组进程的资源用量（CPU、内存、磁盘I/O、网络等等）。
CGroups用于确保同一主机上的容器不会相互影响。
安全计算模式(p)配置集可以与容器关联来限制可用的系统调用。
有关p的详情，请参阅OpenShift安全性指南的第94页。
使用RHCOS部署容器可最大程度缩小主机环境并根据容器进行调整，从而减少攻击面。
CRI-O容器引擎只会实现es和OpenShift运行和管理容器所需的功能，而不像其他容器引擎一样实现面向桌面的独立功能，因此进一步减少了这一攻击面。
RHCOS是RedHatEnterpriseLinux(RHEL)的一个版本，它经过特别配置，可用作OpenShiftContainerPlatform集群上的controlplane(master)和worker节点。
因此，RHCOS适用于高效运行容器工作负载，以及es和OpenShift服务。
为了进一步保护OpenShiftContainerPlatform集群中的RHCOS系统，大多数容器（除了管理或监控主机系统本身的容器外）都应以非root用户身份运行。
要保护您自己的OpenShiftContainerPlatform集群，推荐的最佳实践是降低权限级别或创建包含最少权限的容器。
其他资源 节点如何强制实施资源限制 管理安全性上下文约束 OpenShift集群支持的平台 具有用户置备基础架构的集群的机器要求 选择如何配置RHCOS Ignition 内核参数 内核模块 FIPS加密 磁盘加密 12 第2章容器安全性 Chrony时间服务 OpenShiftContainerPlatform集群更新 2.2.2.虚拟化和容器比较 传统虚拟化提供了另一种在相同物理主机上将应用程序环境保持独立的方法。
但是，虚拟机的工作方式与容器不同。
虚拟化依赖于虚拟机监控程序启动虚拟客户机(VM)，每个虚拟机都有自己的操作系统(OS)，具体表现为运行的内核、正在运行的应用程序及其依赖项。
使用VM，虚拟机监控程序会将虚拟客户机相互隔离并与主机内核隔离。
这样可减少可访问虚拟机监控程序的个人和进程，进而缩小物理服务器上的攻击面。
尽管如此，仍然必须对安全性进行监控：一个虚拟客户机可能利用虚拟机监控程序的错误来获取对另一个虚拟机或主机内核的访问权限。
当需要修补操作系统时，必须对所有使用该操作系统的虚拟客户机进行修补。
容器可在虚拟客户机中运行，这种方式在有些用例中可能是可取的。
例如，您可能在容器中部署传统应用程序，以便将某个应用程序转移到云端。
但是，在单一主机上进行容器分离提供了一种更加轻便、灵活且易于部署的解决方案。
这种部署模型特别适合云原生应用程序。
容器通常比VM小得多，消耗的内存和CPU也更少。
请参阅RHEL7容器文档中的Linux容器与KVM虚拟化的比较，以了解容器和虚拟机之间的差别。
2.2.3.保护OpenShiftContainerPlatform 在部署OpenShiftContainerPlatform时，您可以选择安装程序置备的基础架构（有多个可用的平台）或您自己的用户置备的基础架构。
用户置备的基础架构可能有益于一些低级别的安全相关配置，如启用FIPS合规性或在第一次引导时添加内核模块。
同样，用户置备的基础架构适合用于断开连接的OpenShiftContainerPlatform部署。
请记住，在为OpenShiftContainerPlatform进行安全增强和其他配置更改方面，应包括以下目标： 尽可能保持底层节点的通用性。
您需要能够快速、轻松地以指定的方式丢弃和启动类似的节点。
尽可能通过OpenShiftContainerPlatform管理对节点的修改，而不是对节点进行直接的一次性更改。
为实现这些目标，应该在安装过程中使用MachineConfigOperator应用到各组节点的MachineConfig，通过Ignition或更高版本进行大多数节点更改。
您可以通过这种方式进行的与安全性相关的配置更改示例包括： 添加内核参数 添加内核模块 启用FIPS加密支持 配置磁盘加密 配置chrony时间服务 除了MachineConfigOperator外，还有一些其他的Operator可用来配置由ClusterVersionOperator(CVO)管理的OpenShiftContainerPlatform基础架构。
CVO可以为OpenShiftContainerPlatform集群更新的很多方面实现自动化。
2.3.强化RHCOS 13 OpenShiftContainerPlatform4.7安全性与合规性 RHCOS在创建后经过调整以部署到OpenShiftContainerPlatform中，只需对RHCOS节点进行很少更改甚至无需更改。
每个采用OpenShiftContainerPlatform的机构都对系统加强有自己的要求。
作为一个RHEL系统，RHCOS中添加了针对OpenShift的修改和功能（如Ignition、ostree和一个只读/usr，用来提供有限的不可变性），像任何RHEL系统一样，可以对它进行强化。
不同之处在于您管理强化的方式。
OpenShiftContainerPlatform及其es引擎的一个主要功能就是根据需要迅速缩放应用程序和基础架构。
除非不可避免，否则您不需要通过登录到主机并添加软件或更改设置来直接更改RHCOS。
您需要让OpenShiftContainerPlatform安装程序和controlplane管理对RHCOS的更改，以便可以在不手动干预的情况下启动新节点。
因此，如果您准备在OpenShiftContainerPlatform中强化RHCOS节点来满足安全需求，您应该同时考虑要强化的功能以及如何着手进行这种强化。
2.3.1.在RHCOS中选择要强化的功能 RHEL8安全强化指南介绍了如何处理任何RHEL系统的安全问题。
使用本指南来学习如何处理加密、评估漏洞以及评估不同服务受到的威胁。
同样，您可以了解如何扫描合规标准、检查文件完整性、执行审核以及对存储设备进行加密。
了解了您要强化的功能后，您可以决定如何在RHCOS中强化它们。
2.3.2.选择如何强化RHCOS 不建议在OpenShiftContainerPlatform中直接修改RHCOS系统。
取而代之，您应该考虑在节点池中修改系统，如worker节点和controlplane节点（也称为主节点）。
在非裸机安装中，当需要一个新节点时，您可以请求一个您所需的类型的新节点，并且它将从RHCOS镜像创建，再加上之前创建的修改。
在安装前、在安装过程中以及集群启动和运行后，您有机会修改RHCOS。
2.3.2.1.安装前强化对于裸机安装，您可以在开始OpenShiftContainerPlatform安装前为RHCOS添加强化功能。
例如，您可以在引导RHCOS安装程序时添加内核选项来开启或关闭安全功能，如SELinux或各种低级别设置，如对称多线程。
虽然裸机RHCOS安装难度更大，但有机会在开始OpenShiftContainerPlatform安装前完成操作系统更改。
如果您需要确保尽早设置某些功能，比如磁盘加密或者特殊联网设置，这一点就很重要。
2.3.2.2.安装过程中强化您可以中断OpenShift安装过程并更改Ignition配置。
通过Ignition配置，您可以将自己的文件和systemd服务添加到RHCOS节点中。
您还可以对用于安装的install-config.yaml文件进行一些基本的安全相关更改。
以这种方式添加的内容将在每个节点第一次引导时可用。
2.3.2.3.集群运行后强化在OpenShiftContainerPlatform集群启动并运行后，有几种方法可用来将强化功能应用到RHCOS： 守护进程集：如果您需要在每个节点上运行某个服务，您可以使用es的DaemonSet对象添加该服务。
机器配置：MachineConfig对象包含Ignition配置的子集，其格式相同。
通过将机器配置应用到 14 第2章容器安全性 机器配置：MachineConfig对象包含Ignition配置的子集，其格式相同。
通过将机器配置应用到所有worker或controlplane节点，您可以确保添加到集群中的同类型的下一个节点会应用相同的更改。
这里提到的所有功能在OpenShiftContainerPlatform产品文档中都有介绍。
其他资源OpenShift安全性指南选择如何配置RHCOS修改节点 手动创建安装配置文件 创建es清单和Ignition配置文件使用ISO镜像创建RedHatEnterpriseLinuxCoreOS(RHCOS)机器自定义节点 为节点添加内核参数安装配置参数-请参阅fips支持FIPS加密RHEL核心加密组件 2.4.容器镜像签名 红帽为RedHatContainerRegistries中的镜像提供签名。
在使用MachineConfigOperator（MCO）拉取到OpenShiftContainerPlatform4集群时，会自动验证这些签名。
Quay.io提供了组成OpenShiftContainerPlatform的大多数镜像，只有发行镜像会被签名。
发行镜像指的是批准的OpenShiftContainerPlatform镜像，它可以对供应链攻击提供一定程度的保护。
但是，OpenShiftContainerPlatform的一些扩展（如日志记录、监控和服务网格）会作为OperatorLifecycleManager（OLM）的Operator提供。
这些镜像来自红帽生态系统目录容器镜像registry。
要验证这些镜像在红帽registry和您的基础架构间的完整性，启用签名验证。
2.4.1.为RedHatContainerregistry启用签名验证 启用容器签名验证需要将registryURL链接到sigstore的文件，然后指定验证镜像的密钥。
流程
1.创建将registryURL链接到sigstore并指定要验证镜像的密钥的文件。
创建policy.json文件： $cat>policy.json<.yamldocker:
:sigstore:/webassets/docker/content/sigstore
EOF
创建registry.redhat.io.yaml文件：
$cat<registry.redhat.io.yamldocker:
registry.redhat.io:sigstore:https://registry.redhat.io/containers/sigstore
EOF
2.使用base64编码格式设置用于机器配置模板的文件： $exportARC_REG=$(cat.yaml|base64-w0)$exportRIO_REG=$(catregistry.redhat.io.yaml|base64-w0)$exportPOLICY_CONFIG=$(catpolicy.json|base64-w0)
3.创建将导出的文件写入worker节点上磁盘的机器配置： 16 $cat>51-worker-rh-registry-trust.yaml<4.应用创建的机器配置：
$ocapply-f51-worker-rh-registry-trust.yaml
5.创建机器配置，将导出的文件写入master节点上的磁盘： $cat>51-master-rh-registry-trust.yaml<6.将master机器配置更改应用到集群：
$ocapply-f51-master-rh-registry-trust.yaml
2.4.2.验证签名验证配置
将机器配置应用到集群后，MachineConfigController会检测到新的MachineConfig对象，并生成新的rendered-worker-版本。
先决条件 您可以使用机器配置文件启用签名验证。
流程
1.在命令行中运行以下命令显示所需worker的信息： $ocdescribemachineconfigpool/worker 初始worker监控的输出示例 Name:workerNamespace: 18 第2章容器安全性 Labels:machineconfiguration.openshift.io/mco-built-in= Annotations:
APIVersion:machineconfiguration.openshift.io/v1
Kind:MachineConfigPool
Metadata:
CreationTimestamp:2019-12-19T02:02:12Z
Generation:
3 ResourceVersion:16229 SelfLink: /apis/machineconfiguration.openshift.io/v1/machineconfigpools/worker UID: 92697796-2203-11ea-b48c-fa163e3940e5 Spec: Configuration: Name:
rendered-worker-f6819366eb455a401c42f8d96ab25c02 Source: APIVersion:machineconfiguration.openshift.io/v1 Kind:MachineConfig Name:00-worker APIVersion:machineconfiguration.openshift.io/v1 Kind:MachineConfig Name:01-worker-container-runtime APIVersion:machineconfiguration.openshift.io/v1 Kind:MachineConfig Name:01-worker-kubelet APIVersion:machineconfiguration.openshift.io/v1 Kind:MachineConfig Name:51-worker-rh-registry-trust APIVersion:machineconfiguration.openshift.io/v1 Kind:MachineConfig Name:99-worker-92697796-2203-11ea-b48c-fa163e3940e5-registries APIVersion:machineconfiguration.openshift.io/v1 Kind:MachineConfig Name:99-worker-ssh MachineConfigSelector: MatchLabels: machineconfiguration.openshift.io/role:worker NodeSelector: MatchLabels: es.io/worker: Paused: false Status: Conditions: LastTransitionTime:2019-12-19T02:03:27Z Message: Reason: Status: False Type: RenderDegraded LastTransitionTime:2019-12-19T02:03:43Z Message: Reason: Status: False Type: NodeDegraded LastTransitionTime:2019-12-19T02:03:43Z Message: Reason: Status: False Type: Degraded 19 OpenShiftContainerPlatform4.7安全性与合规性 LastTransitionTime:2019-12-19T02:28:23Z Message: Reason: Status: False Type: Updated LastTransitionTime:2019-12-19T02:28:23Z Message: Allnodesareupdatingtorendered-worker- f6819366eb455a401c42f8d96ab25c02 Reason: Status: True Type: Updating Configuration: Name:
rendered-worker-d9b3f4ffcfd65c30dcf591a0e8cf9b2e Source: APIVersion: machineconfiguration.openshift.io/v1 Kind: MachineConfig Name: 00-worker API
Version: machineconfiguration.openshift.io/v1 Kind: MachineConfig Name: 01-worker-container-runtime API
Version: machineconfiguration.openshift.io/v1 Kind: MachineConfig Name: 01-worker-kubelet API
Version: machineconfiguration.openshift.io/v1 Kind: MachineConfig Name: 99-worker-92697796-2203-11ea-b48c-fa163e3940e5-registries API
Version: machineconfiguration.openshift.io/v1 Kind: MachineConfig Name: 99-worker-ssh Degraded
MachineCount:
0 MachineCount:
1 ObservedGeneration:
3 ReadyMachineCount:
0 UnavailableMachineCount:
1 UpdatedMachineCount:
0 Events:
2.再次运行ocdescribe命令：$ocdescribemachineconfigpool/worker worker更新后的输出示例 ... LastTransitionTime:2019-12-19T04:53:09Z Message: Allnodesareupdatedwith f6819366eb455a401c42f8d96ab25c02 Reason: Status: True Type: Updated LastTransitionTime:2019-12-19T04:53:09Z Message: Reason: Status: False Type: Updating rendered-worker- 20 第
2章容器安全性 Configuration: Name:rendered-worker-f6819366eb455a401c42f8d96ab25c02 Source: APIVersion: machineconfiguration.openshift.io/v1 Kind: MachineConfig Name: 00-worker API
Version: machineconfiguration.openshift.io/v1 Kind: MachineConfig Name: 01-worker-container-runtime API
Version: machineconfiguration.openshift.io/v1 Kind: MachineConfig Name: 01-worker-kubelet API
Version: machineconfiguration.openshift.io/v1 Kind: MachineConfig Name: 51-worker-rh-registry-trust API
Version: machineconfiguration.openshift.io/v1 Kind: MachineConfig Name: 99-worker-92697796-2203-11ea-b48c-fa163e3940e5-registries API
Version: machineconfiguration.openshift.io/v1 Kind: MachineConfig Name: 99-worker-ssh Degraded
MachineCount:
0 MachineCount:
3 ObservedGeneration:
4 ReadyMachineCount:
3 UnavailableMachineCount:
0 UpdatedMachineCount:
3 ... 注意 ObservedGeneration参数显示基于控制器生成的配置的生成数量的增加数。
此控制器即使没有处理规格并生成修订，也会更新这个值。
ConfigurationSource值指向51-worker-rh-registry-trust配置。
3.使用以下命令确认policy.json文件已存在： $ocdebugnode/--chroot/hostcat/etc/containers/policy.json
输出示例
Startingpod/-debug...Tousehostbinaries,run`chroot/host`{
"default":[{"type":"eptAnything"}
],"transports":{
"docker":{"":[{"type":"signedBy",
21
OpenShiftContainerPlatform4.7安全性与合规性
"keyType":"GPGKeys","keyPath":"/etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release"}],"registry.redhat.io":[{"type":"signedBy","keyType":"GPGKeys","keyPath":"/etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release"}]},"docker-daemon":{"":[{"type":"eptAnything"}]}}}
4.使用以下命令确认registry.redhat.io.yaml文件已存在： $ocdebugnode/--chroot/hostcat/etc/containers/registries.d/registry.redhat.io.yaml
输出示例
Startingpod/-debug...Tousehostbinaries,run`chroot/host`docker:
registry.redhat.io:sigstore:https://registry.redhat.io/containers/sigstore
5.使用以下命令确认.yaml文件已存在： $ocdebugnode/--chroot/hostcat/etc/containers/registries.d/.yaml
输出示例
Startingpod/-debug...Tousehostbinaries,run`chroot/host`docker:
:sigstore:/webassets/docker/content/sigstore
2.4.3.其他资源
机器配置概述
2.5.了解合规性
22
第2章容器安全性
对于许多OpenShiftContainerPlatform客户，在将任何系统投入生产前需要达到一定级别的法规就绪状态或合规性。
这种法规就绪状态可通过国家标准、行业标准或机构的企业监管框架来施加。
2.5.1.了解合规性及风险管理 FIPS合规性是高安全性环境中所需的最重要的组件之
一，可确保节点上只允许使用支持的加密技术。
重要只有在x86_64架构中的OpenShiftContainerPlatform部署支持FIPS验证的/ModulesinProcess加密库。
要了解红帽对OpenShiftContainerPlatform合规框架的观点，请参阅OpenShift安全性指南手册中的“风险管理和法规就绪状态”一章。
其他资源在FIPS模式下安装集群 2.6.保护容器内容 要确保容器内所含内容的安全性，需要以可信的基础镜像（如红帽通用基础镜像）开始，并添加可信软件。
为了检查容器镜像的持续安全性，红帽及第三方都有可用于扫描镜像的工具。
2.6.1.确保容器内安全 应用程序和基础架构由随时可用的组件组成，许多组件都是开源软件包，如Linux操作系统、JBossWebServer、PostgreSQL和Node.js。
这些软件包也有容器化版本可用。
然而，您需要知道软件包最初来自哪里，使用什么版本，是谁构建的，以及软件包内是否有恶意代码。
需要回答的一些问题包括： 容器内的内容是否会破坏您的基础架构？应用程序层是否存在已知的漏洞？运行时和操作系统层是不是最新的？通过从红帽通用基础镜像(UBI)构建容器，您可以保证您的容器镜像基础由RedHatEnterpriseLinux中包含的同一RPM打包软件组成。
使用或重新分发UBI镜像不需要订阅。
为确保容器本身持续安全，安全扫描功能（直接从RHEL使用或添加到OpenShiftContainerPlatform）可在您使用的镜像有漏洞时发出警告。
RHEL中提供了OpenSCAP镜像扫描，并且可添加ContainerSecurityOperator来检查OpenShiftContainerPlatform中使用的容器镜像。
2.6.2.使用UBI创建可重新分发的镜像 要创建容器化应用程序，您通常以可信基础镜像开始，该镜像提供的组件通常由操作系统提供。
这些组件包括库、实用程序以及应用程序在操作系统文件系统中应该看到的其他功能。
创建红帽通用基础镜像(UBI)是为了鼓励任何人在构建其自己的容器时都先使用一个完全由RedHat 23 OpenShiftContainerPlatform4.7安全性与合规性 创建红帽通用基础镜像(UBI)是为了鼓励任何人在构建其自己的容器时都先使用一个完全由RedHatEnterpriseLinuxrpm软件包及其他内容组成的容器镜像。
这些UBI镜像会定期更新，以应用最新的安全补丁，并可自由地与构建用来包含您自己的软件的容器镜像一起使用和重新分发。
搜索红帽生态系统目录，以便查找和检查不同UBI镜像的健康状态。
作为创建安全容器镜像的人员，您可能对两种通用UBI镜像类型感兴趣： UBI：RHEL7和8有标准的UBI镜像（ubi7/ubi和ubi8/ubi），以及基于这些系统的最小镜像（ubi7/ubi-minimal和ubi8/ubi-mimimal）。
所有这些镜像已预先配置，以指向您可以使用标准yum和dnf命令添加到构建的容器镜像中的免费RHEL软件存储库。
红帽鼓励人们在其他发行版（如Fedora和Ubuntu）上使用这些镜像。
RedHatSoftwareCollections：在红帽生态系统目录中搜索rhscl/以查找为用作特定应用程序类型的基础镜像而创建的镜像。
例如，有Apachehttpd(rhscl/httpd-*)、Python(rhscl/python*),Ruby(rhscl/ruby-*)、Node.js(rhscl/nodejs-*)和Perl(rhscl/perl-*)rhscl镜像。
请记住，虽然UBI镜像可自由使用且可重新发布，但红帽对这些镜像的支持只能通过RedHat产品订阅获得。
请参阅RedHatEnterpriseLinux文档中的使用红帽通用基础镜像来获得有关如何使用标准、最小和initUBI镜像作为构建基础的信息。
2.6.3.RHEL中的安全扫描 对于RedHatEnterpriseLinux(RHEL)系统，可从openscap-utils软件包中获得OpenSCAP扫描功能。
在RHEL中，您可以使用openscap-podman命令扫描针镜像中的漏洞。
请参阅RedHatEnterpriseLinux文档中的扫描容器和容器镜像中的漏洞。
OpenShiftContainerPlatform可让您在CI/CD过程中利用RHEL扫描程序。
例如，您可以集成静态代码分析工具来测试源代码中的安全漏洞，并集成软件组成分析工具来标识开源库，以提供关于这些库的元数据，如已知漏洞。
2.6.3.1.扫描OpenShift镜像对于在OpenShiftContainerPlatform中运行并且从RedHatQuayregistry中拉取的容器镜像，您可以使用Operator来列出这些镜像的漏洞。
ContainerSecurityOperator可以添加到OpenShiftContainerPlatform中，为添加到所选命名空间的镜像提供漏洞报告。
RedHatQuay的容器镜像扫描由Clair安全扫描程序执行。
在RedHatQuay中，Clair可以搜索和报告从RHEL、CentOS、Oracle、Alpine、Debian和Ubuntu操作系统软件构建的镜像中的漏洞。
2.6.4.集成外部扫描 OpenShiftContainerPlatform使用对象注解来扩展功能。
外部工具（如漏洞扫描程序）可以使用元数据为镜像对象添加注解，以汇总结果和控制Pod执行。
本节描述了该注解的公认格式，以便在控制台中可靠使用它来为用户显示有用的数据。
2.6.4.1.镜像元数据镜像质量数据有多种不同的类型，包括软件包漏洞和开源软件(OSS)许可证合规性。
另外，该元数据的供应商可能不止一个。
为此，保留了以下注解格式： quality.images.openshift.io/.:{}
表2.1.注解键格式
24
组件qualityType
描述元数据类型
第2章容器安全性可接受值vulnerabilitylicenseoperationspolicy
providerId
供应商ID字符串
openscapredhatcatalogredhatinsightsblackduckjfrog
2.6.4.1.1.注解键示例
quality.images.openshift.io/vulnerability.blackduck:{}quality.images.openshift.io/vulnerability.jfrog:{}quality.images.openshift.io/license.blackduck:{}quality.images.openshift.io/vulnerability.openscap:{}
镜像质量注解的值是必须遵循以下格式的结构化数据：
表2.2.注解值格式
字段
必需？
描述
类型
name
是
供应商显示名称
字符串
timestamp
是
扫描时间戳
字符串
description
否
简短描述
字符串
reference
是
信息来源的
URL或更多详细信息。
必需，以便用 户可以验证数据。
字符串 scannerVersion 否 扫描程序版本 字符串 compliant 否 合规性通过或未通过 布尔值 summary 否 找到的问题摘要 列表（请参阅下表） summary
字段必须遵循以下格式：表2.3.Summary字段值格式 25 OpenShiftContainerPlatform4.7安全性与合规性 字段label dataseverityIndexreference 描述 类型 显示组件标签（例如："critical"、"important"、"moderate"、"low"或"health"） 字符串 此组件的数据（例如：发现的漏洞计数或分数） 字符串 组件索引，允许对图形表示进行排整数序和分配。
该值范围为0..3，其中0=low。
信息来源的URL或更多详细信息。
可选。
字符串 2.6.4.1.2.注解值示例 本示例显示了一个镜像的OpenSCAP注解，带有漏洞概述数据以及一个合规性布尔值： OpenSCAP注解 {"name":"OpenSCAP","description":"OpenSCAPvulnerabilityscore","timestamp":"2016-09-08T05:04:46Z","reference":"/930492",pliant":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}] } 本例演示了红帽生态系统目录注解中镜像的容器镜像部分，包含健康索引数据以及获取更多详细信息的外部URL: 红帽生态系统目录注解 {"name":"RedHatEcosystemCatalog","description":"Containerhealthindex","timestamp":"2016-09-08T05:04:46Z","reference":"/errata/RHBA-2016:1566",pliant":null,"scannerVersion":"1.2","summary":[ 26 {"label":"Healthindex","data":"B","severityIndex":
1,"reference":null}]} 第2章容器安全性 2.6.4.2.为镜像对象添加注解 虽然OpenShiftContainerPlatform最终用户操作针对的是镜像流对象，但会使用安全元数据为镜像对象添加注解。
镜像对象是集群范围的，指向可能由多个镜像流和标签引用的单一镜像。
2.6.4.2.1.注解CLI命令示例 将替换为镜像摘要，如sha256:2：
$ocannotateimage\quality.images.openshift.io/vulnerability.redhatcatalog='{\"name":"RedHatEcosystemCatalog",\"description":"Containerhealthindex",\"timestamp":"2020-06-01T05:04:46Z",\pliant":null,\"scannerVersion":"1.2",\"reference":"/errata/RHBA-2020:2347",\"summary":"[\{"label":"Healthindex","data":"B","severityIndex":
1,"reference":null}]"}' 2.6.4.3.控制Pod执行使用images.openshift.io/deny-execution镜像策略，以编程方式控制镜像是否可以运行。
2.6.4.3.1.注解示例 annotations:images.openshift.io/deny-execution:true 2.6.4.4.集成参考 在大多数情况下，漏洞扫描程序等外部工具会开发一个脚本或插件来监视镜像更新，执行扫描，并使用结果为相关的镜像对象添加注解。
通常，这个自动化过程会调用OpenShiftContainerPlatform4.7RESTAPI来编写注解。
有关RESTAPI的常规信息，请参阅OpenShiftContainerPlatformRESTAPI。
2.6.4.4.1.RESTAPI调用示例 以下使用curl的示例调用会覆盖注解值。
请务必替换、、和的值。
修补API调用 $curl-XPATCH\-H"Authorization:Bearer"\-H"Content-Type:application/merge-patch+json"\https://:8443/oapi/v1/images/\--data'{}'
27
OpenShiftContainerPlatform4.7安全性与合规性
以下是PATCH有效负载数据的示例：
修补调用数据
{"metadata":{
"annotations":{"quality.images.openshift.io/vulnerability.redhatcatalog":"{'name':'RedHatEcosystemCatalog','description':'Containerhealthindex','timestamp':'2020-
06-01T05:04:46Z',pliant':null,'reference':'/errata/RHBA-2020:2347','summary':[{'label':'Healthindex','data':'4','severityIndex':
1,'reference':null}]}" }}} 其他资源 镜像流对象 2.7.安全地使用容器REGISTRY 容器registry存储容器镜像以便： 使镜像可供其他用户访问 将镜像组织到可包含多个镜像版本的存储库中 选择性地根据不同的身份验证方法限制对镜像的访问，或者将其设为可公开使用 有一些公共容器registry（如Quay.io和DockerHub）可供很多个人和机构共享其镜像。
红帽Registry提供支持的红帽和合作伙伴镜像，而红帽生态系统目录为这些镜像提供了详细的描述和健康状态检查。
要管理自己的registry，您可以购买一个容器registry，如RedHatQuay。
从安全角度来说，有些registry提供了特殊的功能来检查并改进容器的健康状态。
例如，RedHatQuay通过Clair安全扫描程序提供容器漏洞扫描功能，提供构建触发器以在GitHub和其他位置的源代码发生更改时自动重建镜像，并支持使用基于角色的访问控制(RBAC)来保护对镜像的访问。
2.7.1.知道容器来自哪里？ 您可以使用一些工具来扫描和跟踪您下载和部署的容器镜像的内容。
但是，容器镜像有很多公共来源。
在使用公共容器registry时，您可以使用可信源添加一层保护。
2.7.2.不可变和已认证的容器 在管理不可变容器时，消耗安全更新尤其重要。
不可变容器是在运行时永远不会更改的容器。
当您部署不可变容器时，您不会介入正在运行的容器来替换一个或多个二进制文件。
从操作角度来说，您可以重建并重新部署更新的容器镜像以替换某个容器，而不是更改该容器。
红帽的已认证镜像： 在平台组件或层中没有已知漏洞 在RHEL平台间兼容，从裸机到云端 受红帽支持 28 第2章容器安全性 已知漏洞列表不断扩展，因此您必须一直跟踪部署的容器镜像的内容以及新下载的镜像。
您可以使用红帽安全公告(RHSA)来提醒您红帽的已认证容器镜像中出现的任何新问题，并指引您找到更新的镜像。
另外，您还可以访问红帽生态系统目录查找每个红帽镜像的各种安全相关问题。
2.7.3.从红帽Registry和生态系统目录获取容器 红帽在红帽生态系统目录的容器镜像部分列出了适用于红帽产品和合作伙伴产品的已认证容器镜像。
在该目录中，您可以查看每个镜像的详情，包括CVE、软件包列表和健康状态分数。
红帽镜像实际存储在所谓的红帽Registry中，其具体代表为公共容器registry()和经过身份验证的registry(registry.redhat.io)。
这两者基本包括同一组容器镜像，其中registry.redhat.io包括了一些需要使用红帽订阅凭证进行身份验证的额外镜像。
红帽会监控容器内容以了解漏洞，并定期进行更新。
当红帽发布安全更新（如glibc、DROWN或DirtyCow的修复程序）时，任何受影响的容器镜像也会被重建并推送到RedHatRegistry。
红帽使用healthindex来反映通过红帽生态系统目录提供的每个容器的安全风险。
由于容器消耗红帽提供的软件和勘误表流程，旧的、过时的容器不安全，而全新容器则更安全。
为了说明容器的年龄，红帽生态系统目录使用一个等级系统。
新鲜度等级是一个镜像可用的最旧、最严重的安全公告衡量标准。
“A”比“F”状态更新。
如需了解这个等级系统的更多详情，请参阅RedHatEcosystemCatalog内部使用的容器健康状态索引等级。
如需详细了解与红帽软件相关的安全更新和漏洞，请参阅红帽产品安全中心。
查看红帽安全公告以搜索具体公告和CVE。
2.7.4.OpenShiftContainerRegistry OpenShiftContainerPlatform包括OpenShiftContainerRegistry，它是作为平台集成组件运行的私有registry，可用于管理容器镜像。
OpenShiftContainerRegistry提供基于角色的访问控制，供您管理谁可以拉取和推送哪些容器镜像。
OpenShiftContainerPlatform还支持与其他您可能已经使用的私有registry集成，如RedHatQuay。
其他资源 集成的OpenShiftContainerPlatformregistry 2.7.5.使用RedHatQuay存储容器 RedHatQuay是红帽的一个企业级容器registry产品。
RedHatQuay的开发是通过上游ProjectQuay完成的。
RedHatQuay可用于在内部部署，或通过RedHatQuay在Quay.io的托管版本部署。
与安全性相关的RedHatQuay功能包括： 时间机器：允许带有旧标签的镜像在一段设定时间后或基于用户选择的过期时间过期。
存储库镜像：让您出于安全原因为其他registry创建镜像，如在公司防火墙后面的RedHatQuay上托管公共存储库，或出于性能原因让registry更接近使用的位置。
操作日志存储：将RedHatQuay日志输出保存到Elasticsearch存储，以便稍后进行搜索和分析。
Clair安全扫描：根据每个容器镜像的来源，针对各种Linux漏洞数据库扫描镜像。
内部身份验证：使用默认本地数据库处理面向RedHatQuay的RBAC身份验证，或者从 29 OpenShiftContainerPlatform4.7安全性与合规性内部身份验证：使用默认本地数据库处理面向RedHatQuay的RBAC身份验证，或者从LDAP、Keystone(OpenStack)、JWT自定义身份验证或ExternalApplicationToken身份验证中选择。
外部授权(OAuth)：允许通过GitHub、GitHubEnterprise或Google身份验证对RedHatQuay进行授权。
访问设置：生成令牌，允许从docker、rkt、匿名访问、用户创建的帐户、加密客户端密码或前缀用户名自动完成访问RedHatQuay。
RedHatQuay不断与OpenShiftContainerPlatform持续集成，包含几个特别值得关注的OpenShiftContainerPlatformOperator。
QuayBridgeOperator可让您将OpenShiftContainerPlatform内部registry替换为RedHatQuay。
QuayContainerSecurityOperator可让您检查在OpenShiftContainerPlatform中运行并从RedHatQuayregistry拉取的镜像的漏洞。
2.8.保护构建过程 在容器环境中，软件构建过程是生命周期中应用程序代码与所需的运行时库集成的阶段。
管理此构建过程是保护软件堆栈的关键。
2.8.1.一次构建，随处部署 使用OpenShiftContainerPlatform作为容器构建的标准平台可保证构建环境的安全。
遵循“一次构建，随处部署”的原则可确保构建过程的产品就是在生产环境中部署的产品。
保持容器的不可变性也是很重要的。
您不应该修补运行中的容器，而应该重建并重新部署这些容器。
随着您的软件逐步进入构建、测试和生产阶段，组成软件供给链的工具必须是可信的。
下图演示了可整合到容器化软件的可信软件供应链中的流程和工具： OpenShiftContainerPlatform可以与可信代码存储库（如GitHub）和开发平台（如Che）集成，用于创建和管理安全代码。
单元测试可以依赖Cucumber和JUnit。
您可以通过Anchore或Twistlock检查容器中的漏洞和合规问题，并使用镜像扫描工具，如AtomicScan或Clair。
Sysdig等工具可以提供对容器化应用程序的持续监控。
2.8.2.管理构建 您可以使用Source-to-Image(S2I)将源代码和基础镜像组合起来。
构建器镜像利用S2I使您的开发和运 30 第2章容器安全性 您可以使用Source-to-Image(S2I)将源代码和基础镜像组合起来。
构建器镜像利用S2I使您的开发和运维团队能够就可重复生成的构建环境展开合作。
对于可作为通用基础镜像(UBI)镜像的RedHatS2I镜像，您现在可以使用从真实RHELRPM软件包构建的基础镜像自由重新分发您的软件。
红帽取消了订阅限制以允许这一操作。
当开发人员使用构建镜像通过Git提交某个应用程序的代码时，OpenShiftContainerPlatform可以执行以下功能： 通过使用代码存储库上的Webhook或其他自动持续集成(CI)过程进行触发，以从可用的工件、S2I构建器镜像和新提交的代码中自动编译新镜像。
自动部署新构建的镜像以进行测试。
将测试镜像提升到生产环境中，以使用CI过程自动进行部署。
您可以使用集成的OpenShiftContainerRegistry来管理对最终镜像的访问。
S2I和原生构建镜像会自动推送到OpenShiftContainerRegistry。
除了包含的用于CI的Jenkins外，您还可以使用RESTfulAPI将您自己的构建和CI环境与OpenShiftContainerPlatform集成，并使用与API兼容的镜像registry。
2.8.3.在构建期间保护输入 在某些情况下，构建操作需要凭证才能访问依赖的资源，但这些凭证最好不要在通过构建生成的最终应用程序镜像中可用。
您可以定义输入secret以实现这一目的。
例如，在构建Node.js应用程序时，您可以为Node.js模块设置私有镜像。
要从该私有镜像下载模块，您必须为包含URL、用户名和密码的构建提供自定义的.npmrc文件。
为安全起见，不应在应用程序镜像中公开您的凭证。
通过使用此示例场景，您可以在新BuildConfig对象中添加输入secret：
1.如果secret不存在，则进行创建： 31 OpenShiftContainerPlatform4.7安全性与合规性 $occreatesecretgenericsecret-npmrc--from-file=.npmrc=~/.npmrc这会创建一个名为secret-npmrc的新secret，其包含~/.npmrc文件的base64编码内容。
2.将该secret添加到现有BuildConfig对象的source部分中： source:git:uri:/nodejs-ex.gitsecrets:-destinationDir:.secret:name:secret-npmrc
3.要在新BuildConfig对象中包含该secret，请运行以下命令：$ocnew-build\openshift/nodejs-010-centos7~/nodejs-ex.git\--build-secretsecret-npmrc 2.8.4.设计构建过程 您可以对容器镜像管理和构建过程进行设计以使用容器层，以便您可以分开控制。
例如，一个运维团队负责管理基础镜像，而架构师则负责管理中间件、运行时、数据库和其他解决方案。
然后开发人员可以专注于应用程序层并专注于编写代码。
由于每天都会识别出新的漏洞，因此您需要一直主动检查容器内容。
要做到这一点，您应该将自动安全测试集成到构建或CI过程中。
例如： SAST/DAST–静态和动态安全测试工具。
根据已知漏洞进行实时检查的扫描程序。
这类工具会为您的容器中的开源软件包编目，就任何已知漏洞通知您，并在之前扫描的软件包中发现新漏洞时为您提供最新信息。
您的CI过程应该包含相应的策略，为构建标记出通过安全扫描发现的问题，以便您的团队能够采取适当行动来解决这些问题。
您应该为自定义构建容器签名，以确保在构建和部署之间不会修改任何内容。
32 第2章容器安全性利用GitOps方法，您不仅可以使用相同的CI/CD机制来管理应用程序配置，还可以管理OpenShiftContainerPlatform基础架构。
2.8.5.构建Knative无服务器应用程序 借助es和Kourier，您可以在OpenShiftContainerPlatform中使用OpenShiftServerless来构建、部署和管理无服务器应用程序。
和其他构建一样，您可以使用S2I镜像来构建容器，然后使用Knative服务提供它们。
通过OpenShiftContainerPlatformWeb控制台的Topology视图查看Knative应用程序构建。
2.8.6.其他资源 理解镜像构建触发和修改构建创建构建输入输入secret和配置映射关于OpenShiftServerless使用Topology视图查看应用程序组成情况 2.9.部署容器 您可以使用各种技术来确保所部署的容器包含最新的生产级内容，并确保这些容器没有被修改。
这些技术包括设置构建触发器以纳入最新的代码，以及使用签名来确保容器来自可信源且未修改。
2.9.1.使用触发器控制容器部署 如果在构建过程中发生某种情况，或者部署了镜像后发现一个漏洞，您可以使用基于策略的自动化部署工具进行修复。
您可以使用触发器来重建和替换镜像，确保不可变的容器进程，而不是修补正在运行的容器，这种做法是不推荐的。
33 OpenShiftContainerPlatform4.7安全性与合规性 例如，您使用三个容器镜像层构建了一个应用程序：核心、中间件和应用程序。
由于在核心镜像中发现了一个问题，该镜像被重建。
构建完成后，该镜像被推送到OpenShiftContainerRegistry。
OpenShiftContainerPlatform检测到镜像已更改，并根据定义的触发器自动重建并部署应用程序镜像。
这一更改包含了固定的库，并确保产品代码与最新镜像是一致的。
您可以使用ocsettriggers命令来设置部署触发器。
例如，要为名为deployment-example的部署设置触发器： $ocsettriggersdeploy/deployment-example\--from-image=example:latest\--containers=web 2.9.2.控制可以部署的镜像源 务必要确保实际部署了所需的镜像，还要确保包括容器内容的镜像来自可信源，且尚未更改。
加密签名提供了这一保证。
OpenShiftContainerPlatform可让集群管理员应用广泛或狭窄的安全策略，以反应部署环境和安全要求。
该策略由两个参数定义： 一个或多个带有可选项目命名空间的registry 34 第2章容器安全性 信任类型，如接受、拒绝或要求公钥 您可以使用这些策略参数来允许、拒绝整个registry、部分registry或单独的镜像，或者要求具有信任关系。
使用可信公钥，您可以确保以加密的方式验证源。
该策略规则应用于节点。
策略可以在所有节点中统一应用，或针对不同的节点工作负载（例如：构建、区域或环境）加以应用。
镜像签名策略文件示例 {"default":[{"type":"reject"}],"transports":{"docker":{"":[{"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//pubkey"}],"172.30.1.1:5000":[{"type":"reject"}]}} } 该策略可以在节点上保存为/etc/containers/policy.json。
最好使用新的MachineConfig对象将此文件保存到节点。
这个示例强制执行以下规则： 要求RedHatRegistry()中的镜像由红帽公钥签名。
要求openshift命名空间中的OpenShiftContainerRegistry中的镜像由RedHat公钥签名。
要求production命名空间中的OpenShiftContainerRegistry中的镜像由的公钥签名。
拒绝未由全局默认定义指定的所有其他registry。
2.9.3.使用签名传输 签名传输是一种存储和检索二进制签名blob的方法。
签名传输有两种类型。
35 OpenShiftContainerPlatform4.7安全性与合规性 Atomic：由OpenShiftContainerPlatformAPI管理。
Docker：作为本地文件或通过Web服务器提供。
OpenShiftContainerPlatformAPI负责管理使用atomic传输类型的签名。
您必须将使用此签名类型的镜像存储在OpenShiftContainerRegistry中。
由于docker/distributionextensionsAPI会自动发现镜像签名端点，因此不需要额外的配置。
使用docker传输类型的签名由本地文件或者Web服务器提供。
这些签名更为灵活，您可以提供来自任何容器镜像registry的镜像，并使用独立的服务器来提供二进制签名。
但是，docker传输类型需要进行额外的配置。
您必须为节点配置签名服务器的URI，方法是将随机命名的YAML文件放在主机系统上的目录中，默认为/etc/containers/registries.d。
YAML配置文件包含registryURI和签名服务器URI，或sigstore： Registries.d文件示例 docker::sigstore:/webassets/docker/content/sigstore 在这个示例中，RedHatRegistry是为docker传输类型提供签名的签名服务器。
其URI在sigstore参数中定义。
您可以将此文件命名为/etc/containers/registries.d/.yaml，并使用MachineConfigOperator自动将文件放在集群中的每个节点上。
由于策略和registry.d文件由容器运行时动态加载，因此不需要重启服务。
2.9.4.创建secret和配置映射 Secret对象类型提供了一种机制来保存敏感信息，如密码、OpenShiftContainerPlatform客户端配置文件、dockercfg文件和私有源存储库凭证。
Secret将敏感内容与Pod分离。
您可以使用卷插件将secret信息挂载到容器中，系统也可以使用secret代表Pod执行操作。
例如，要在部署配置中添加secret，以便它可以访问私有镜像存储库，请执行以下操作： 流程
1.登陆到OpenShiftContainerPlatformWeb控制台。
2.创建新项目。
3.导航到Resources→Secrets并创建新secret。
将SecretType设为ImageSecret，并将AuthenticationType设为ImageRegistryCredentials，以输入用于访问私有镜像存储库的凭证。
4.在创建部署配置时（例如，从AddtoProject→DeployImage页面），将PullSecret设置为您的新secret。
配置映射与secret类似，但设计为能支持与不含敏感信息的字符串配合使用。
ConfigMap对象包含配置数据的键值对，这些数据可在Pod中消耗或用于存储控制器等系统组件的配置数据。
2.9.5.自动化持续部署 您可以将自己的持续部署(CD)工具与OpenShiftContainerPlatform集成。
利用CI/CD和OpenShiftContainerPlatform，您可以自动执行重建应用程序的过程，以纳入最新的修 36 第2章容器安全性 利用CI/CD和OpenShiftContainerPlatform，您可以自动执行重建应用程序的过程，以纳入最新的修复、测试，并确保它在环境中随处部署。
其他资源输入secret和配置映射 2.10.保护容器平台 OpenShiftContainerPlatform和esAPI是大规模自动化容器管理的关键。
API用于：验证并配置Pod、服务和复制控制器的数据。
在收到传入请求时执行项目验证，并对其他主要系统组件调用触发器。
OpenShiftContainerPlatform中基于es的安全相关功能包括：多租户，将基于角色的访问控制和网络策略组合起来，以在多个级别上隔离容器。
准入插件，在API和向API发出请求的各方之间形成界限。
OpenShiftContainerPlatform使用Operator来自动化和简化es级别安全功能的管理。
2.10.1.使用多租户隔离容器 多租户允许OpenShiftContainerPlatform集群上由多个用户拥有并在多个主机和命名空间中运行的应用程序保持相互隔离并与外部攻击隔离。
要获取多租户，您可以将基于角色的访问控制(RBAC)应用到es命名空间。
在es中，命名空间是应用程序可以独立于其他应用程序运行的区域。
OpenShiftContainerPlatform使用和扩展命名空间的方式是添加额外的注解，包括在SELinux中的MCS标签，并将这些扩展命名空间标识为项目。
在项目范围内，用户可以维护自己的集群资源，包括服务帐户、策略、限制和各种其他对象。
可将RBAC对象分配给项目，以便授权所选用户访问这些项目。
该授权采用规则、角色和绑定的形式：规则会定义用户可在项目中创建或访问的内容。
角色是您可以绑定到所选用户或组的规则集合。
绑定会定义用户或组与角色之间的关联。
本地RBAC角色和绑定将用户或组附加到特定项目。
集群RBAC可将集群范围的角色和绑定附加到集群中的所有项目。
有默认的集群角色可以分配，用来提供admin、basic-user、cluster-admin和clusterstatus访问。
2.10.2.使用准入插件保护controlplane RBAC可控制用户和组与可用项目之间的访问规则，而准入插件可定义对OpenShiftContainerPlatform主API的访问。
准入插件形成一个由以下部分组成的规则链： 默认准入插件：这些插件实现了一组默认策略和资源限制以应用于OpenShiftContainerPlatformcontrolplane的组件。
变异准入插件：这些插件会动态地扩展准入链。
它们调用Webhook服务器，不仅可对请求进行身份验证，还可修改所选资源。
37 OpenShiftContainerPlatform4.7安全性与合规性 验证准入插件：这些插件验证所选资源的请求，不仅可验证请求，还可确保资源不会再次更改。
API请求经过一个链中的准入插件，沿途的任何失败都会导致请求遭到拒绝。
每个准入插件都与特定资源关联，且只响应这些资源的请求。
2.10.2.1.安全性上下文约束(SCC)您可以使用安全性上下文约束(SCC)定义Pod运行必须满足的一组条件，以便其能被系统接受。
可由SCC管理的一些方面包括： 运行特权容器容器可请求添加的功能将主机目录用作卷。
容器的SELinux上下文。
容器用户ID。
如果具有所需的权限，您可以根据需要将默认SCC策略调整为更宽松。
2.10.2.2.为服务帐户授予角色就像为用户分配基于角色的访问一样，您可以为服务帐户分配角色。
为每个项目创建的默认服务帐户有三个。
服务帐户： 范围限制为特定项目名称来自其项目会被自动分配一个API令牌和凭证来访问OpenShiftContainerRegistry与平台组件关联的服务帐户自动使其密钥轮转。
2.10.3.认证和授权 2.10.3.1.使用OAuth控制访问您可以通过身份验证和授权使用API访问控制来保护容器平台。
OpenShiftContainerPlatformmaster包含内置的OAuth服务器。
用户可以获取OAuth访问令牌来对自身进行API身份验证。
作为管理员，您可以使用用户身份供应商（如LDAP、GitHub或Google）配置OAuth以进行身份验证。
用户身份供应商默认用于新的OpenShiftContainerPlatform部署，但您可以在初始安装时或安装后进行此配置。
2.10.3.2.API访问控制和管理应用程序可以拥有多个独立的API服务，这些服务具有不同的端点需要管理。
OpenShiftContainerPlatform包含3scaleAPI网关的容器化版本，以便您管理API并控制访问。
3scale为您提供用于API身份验证和安全性的各种标准选项，它们可单独或组合起来用于发布凭证和控制访问：标准API密钥、应用程序ID和密钥对以及OAuth2.0。
您可以限制对特定端点、方法和服务的访问，并为用户组应用访问策略。
您可以通过应用程序计划来为各 38 第2章容器安全性 您可以限制对特定端点、方法和服务的访问，并为用户组应用访问策略。
您可以通过应用程序计划来为各组开发人员设置API使用率限制并控制流量。
有关使用容器化3scaleAPI网关APIcastv2的教程，请参阅3scale文档中的在RedHatOpenShift上运行APIcast。
2.10.3.3.红帽单点登录通过红帽单点登录服务器，您可以提供基于标准的Web单点登录功能，包括SAML2.0、OpenIDConnect和OAuth2.0，从而保护应用程序。
该服务器可充当基于SAML或OpenIDConnect的用户身份供应商(IdP)，使用基于标准的令牌在您的企业用户目录或用于身份信息的第三方用户身份供应商与您的应用程序之间进行调和。
您可以将红帽单点登录与基于LDAP的目录服务集成，包括MicrosoftActiveDirectory和RedHatEnterpriseLinuxIdentityManagement。
2.10.3.4.安全自助服务Web控制台OpenShiftContainerPlatform提供了一个自助服务Web控制台，以确保团队在没有授权的情况下无法访问其他环境。
OpenShiftContainerPlatform通过提供以下功能来确保安全多租户master： 使用传输层安全(TLS)访问master使用X.509证书或OAuth访问令牌访问API服务器通过项目配额限制异常令牌可以造成的破坏 Etcd服务不直接向集群公开 2.10.4.为平台管理证书 OpenShiftContainerPlatform的框架中有多个组件，它们使用基于REST的HTTPS通信，通过TLS证书利用加密功能。
OpenShiftContainerPlatform的安装程序会在安装过程中配置这些证书。
生成此流量的一些主要组件如下： master（API服务器和控制器） etcd节点 registry路由器 2.10.4.1.配置自定义证书您可以在初
目录 目录 第...1.章...O..P.E.N..S.H..I.F.T..C.O..N..T.A..IN..E.R..P..L.A.T..F.O..R.M..安...全..和..合..规..性.....................................................8............. 1.1.安全概述
8 容器安全性
8 Auditing
8 证书
8 加密数据
9 漏洞扫描
9 1.2.合规性概述
9 合规性检查
9 文件完整性检查
9 1.3.其他资源
9 第...2..章..容..器...安..全..性............................................................................................1.0............. 2.1.了解容器安全性 10 2.1.1.什么是容器？ 10 2.1.2.OpenShiftContainerPlatform是什么？ 11 2.2.了解主机和虚拟机安全性 11 2.2.1.保护RedHatEnterpriseLinuxCoreOS(RHCOS)上的容器 11 2.2.2.虚拟化和容器比较 13 2.2.3.保护OpenShiftContainerPlatform 13 2.3.强化RHCOS 13 2.3.1.在RHCOS中选择要强化的功能 14 2.3.2.选择如何强化RHCOS 14 2.3.2.1.安装前强化 14 2.3.2.2.安装过程中强化 14 2.3.2.3.集群运行后强化 14 2.4.容器镜像签名 15 2.4.1.为RedHatContainerregistry启用签名验证 15 2.4.2.验证签名验证配置 18 2.4.3.其他资源 22 2.5.了解合规性 22 2.5.1.了解合规性及风险管理 23 2.6.保护容器内容 23 2.6.1.确保容器内安全 23 2.6.2.使用UBI创建可重新分发的镜像 23 2.6.3.RHEL中的安全扫描 24 2.6.3.1.扫描OpenShift镜像 24 2.6.4.集成外部扫描 24 2.6.4.1.镜像元数据 24 2.6.4.1.1.注解键示例 25 2.6.4.1.2.注解值示例 26 2.6.4.2.为镜像对象添加注解 27 2.6.4.2.1.注解CLI命令示例 27 2.6.4.3.控制Pod执行 27 2.6.4.3.1.注解示例 27 2.6.4.4.集成参考 27 2.6.4.4.1.RESTAPI调用示例 27 2.7.安全地使用容器REGISTRY 28 2.7.1.知道容器来自哪里？ 28 2.7.2.不可变和已认证的容器 28 2.7.3.从红帽Registry和生态系统目录获取容器 29
1 OpenShiftContainerPlatform4.7安全性与合规性 2.7.4.OpenShiftContainerRegistry 29 2.7.5.使用RedHatQuay存储容器 29 2.8.保护构建过程 30 2.8.1.一次构建，随处部署 30 2.8.2.管理构建 30 2.8.3.在构建期间保护输入 31 2.8.4.设计构建过程 32 2.8.5.构建Knative无服务器应用程序 33 2.8.6.其他资源 33 2.9.部署容器 33 2.9.1.使用触发器控制容器部署 33 2.9.2.控制可以部署的镜像源 34 2.9.3.使用签名传输 35 2.9.4.创建secret和配置映射 36 2.9.5.自动化持续部署 36 2.10.保护容器平台 37 2.10.1.使用多租户隔离容器 37 2.10.2.使用准入插件保护controlplane 37 2.10.2.1.安全性上下文约束(SCC) 38 2.10.2.2.为服务帐户授予角色 38 2.10.3.认证和授权 38 2.10.3.1.使用OAuth控制访问 38 2.10.3.2.API访问控制和管理 38 2.10.3.3.红帽单点登录 39 2.10.3.4.安全自助服务Web控制台 39 2.10.4.为平台管理证书 39 2.10.4.1.配置自定义证书 39 2.11.保护网络 40 2.11.1.使用网络命名空间 40 2.11.2.使用网络策略隔离Pod 40 2.11.3.使用多个Pod网络 40 2.11.4.隔离应用程序 40 2.11.5.保护入口流量 41 2.11.6.保护出口流量 41 2.12.保护附加存储 41 2.12.1.持久性卷插件 41 2.12.2.共享存储 42 2.12.3.块存储 42 2.13.监控集群事件和日志 42 2.13.1.监视集群事件 42 2.13.2.日志记录 43 2.13.3.审计日志 44 第...3..章..配...置..证..书..............................................................................................4.5............. 3.1.替换默认入口证书 45 3.1.1.了解默认入口证书 45 3.1.2.替换默认入口证书 45 3.2.添加API服务器证书 46 3.2.1.向API服务器添加指定名称的证书 46 3.3.使用服务提供的证书SECRET保护服务流量 48 3.3.1.了解服务用证书 48 3.3.2.添加服务证书 48 3.3.3.将服务CA捆绑包添加到配置映射中 49
2 目录 3.3.4.将服务CA捆绑包添加到API服务 50 3.3.5.将服务CA捆绑包添加到自定义资源定义中 51 3.3.6.将服务CA捆绑包添加到变异的webhook配置中 52 3.3.7.将服务CA捆绑包添加到验证webhook配置中 52 3.3.8.手动轮转生成的服务证书 53 3.3.9.手动轮转服务CA证书 54 第...4..章..证...书..类..型..和..描..述........................................................................................5.6............. 4.1.API服务器的用户提供的证书 56 4.1.1.用途 56 4.1.2.位置 56 4.1.3.管理 56 4.1.4.过期 56 4.1.5.自定义 56 其他资源 56 4.2.代理证书 56 4.2.1.用途 56 其他资源 57 4.2.2.在安装过程中管理代理证书 57 4.2.3.位置 57 4.2.4.过期 57 4.2.5.服务 58 4.2.6.管理 58 4.2.7.自定义 58 4.2.8.续订 59 4.3.服务CA证书 59 4.3.1.用途 59 4.3.2.过期 59 4.3.3.管理 60 4.3.4.服务 60 其他资源 60 4.4.节点证书 61 4.4.1.用途 61 4.4.2.管理 61 其他资源 61 4.5.BOOTSTRAP证书 61 4.5.1.用途 61 4.5.2.管理 61 4.5.3.过期 61 4.5.4.自定义 61 4.6.ETCD证书 61 4.6.1.用途 61 4.6.2.过期 61 4.6.3.管理 62 4.6.4.服务 62 其他资源 62 4.7.OLM证书 62 4.7.1.管理 62 4.8.用户提供的默认入口证书 62 4.8.1.用途 62 4.8.2.位置 63 4.8.3.管理 63 4.8.4.过期 63
3 OpenShiftContainerPlatform4.7安全性与合规性 4.8.5.服务 63 4.8.6.自定义 63 其他资源 63 4.9.入口证书（INGRESSCERTIFICATE） 63 4.9.1.用途 63 4.9.2.位置 63 4.9.3.工作流 64 4.9.4.过期 65 4.9.5.服务 65 4.9.6.管理 65 4.9.7.续订 66 4.10.监控和OPENSHIFTLOGGINGOPERATOR组件证书 66 4.10.1.过期 66 4.10.2.管理 66 4.11.CONTROLPLANE证书 66 4.11.1.位置 66 4.11.2.管理 66 第...5..章..C..O..M..P.L.I.A.N..C..E..O.P..E.R.A..T.O..R...........................................................................6.7............. 5.1.COMPLIANCEOPERATOR发行注记 67 5.1.1.OpenShiftComplianceOperator0.1.47 67 5.1.1.1.新功能及功能增强 67 5.1.1.2.程序错误修复 67 5.1.2.OpenShiftComplianceOperator0.1.44 67 5.1.2.1.新功能及功能增强 67 5.1.2.2.模板和变量使用 68 5.1.2.3.程序错误修复 68 5.1.3.ComplianceOperator0.1.39发行注记 69 5.1.3.1.新功能及功能增强 69 5.1.4.其他资源 69 5.2.支持的合规性配置集 69 5.2.1.合规配置集 69 5.2.2.其他资源 71 5.3.安装COMPLIANCEOPERATOR 71 5.3.1.通过Web控制台安装ComplianceOperator 71 5.3.2.使用CLI安装ComplianceOperator 71 5.3.3.其他资源 73 5.4.COMPLIANCEOPERATOR扫描 73 5.4.1.运行合规性扫描 73 5.4.2.在worker节点上调度结果服务器pod 75 5.5.了解COMPLIANCEOPERATOR 77 5.5.1.ComplianceOperator配置集 77 5.6.管理COMPLIANCEOPERATOR 79 5.6.1.更新安全性内容 80 5.6.2.使用镜像流 80 5.6.3.ProfileBundleCR示例 81 5.6.4.其他资源 82 5.7.定制COMPLIANCEOPERATOR 82 5.7.1.使用定制配置集 82 5.8.检索COMPLIANCEOPERATOR原始结果 84 5.8.1.从持久性卷中获取ComplianceOperator原始结果 84 5.9.管理COMPLIANCEOPERATOR补救 85 5.9.1.审阅补救 85
4 目录 5.9.2.应用补救 86 5.9.3.手动补救平台检查 87 5.9.4.更新补救 88 5.9.5.取消应用补救 89 5.9.6.删除KubeletConfig补救 89 5.9.7.不一致的补救 91 5.9.8.过滤失败的合规性检查结果 91 5.9.9.其他资源 92 5.10.执行高级COMPLIANCEOPERATOR任务 92 5.10.1.直接使用ComplianceSuite和ComplianceScan对象 92 5.10.2.使用原始定制配置集 92 5.10.3.执行重新扫描 93 5.10.4.为结果设置自定义存储大小 94 5.10.4.1.使用自定义结果存储值 94 5.10.5.应用套件扫描生成的补救 94 5.10.6.自动更新补救 95 5.11.对COMPLIANCEOPERATOR进行故障排除 95 5.11.1.扫描剖析 96 5.11.1.1.合规性源 96 5.11.1.2.ScanSetting和ScanSettingBinding对象生命周期和调试 96 5.11.1.3.ComplianceSuite自定义资源生命周期和调试 97 5.11.1.4.ComplianceScan自定义资源生命周期和调试 97 5.11.1.4.1.待处理阶段 97 5.11.1.4.2.启动阶段 97 5.11.1.4.3.运行阶段 98 5.11.1.4.4.聚合阶段 99 5.11.1.4.5.完成阶段 100 5.11.1.5.ComplianceRemediation控制器生命周期和调试 100 5.11.1.6.有用的标签 101 5.11.2.获取支持 101 5.12.卸载COMPLIANCEOPERATOR 102 5.12.1.从OpenShiftContainerPlatform卸载OpenShiftComplianceOperator 102 第...6..章...F.IL..E..IN..T.E..G.R..IT..Y..O.P..E.R..A.T.O..R........................................................................10..4............. 6.1.FILEINTEGRITYOPERATOR发行注记 104 6.1.1.OpenShiftFileIntegrityOperator0.1.22 104 6.1.1.1.程序错误修复 104 6.1.2.OpenShiftFileIntegrityOperator0.1.21 104 6.1.2.1.新功能及功能增强 104 6.1.2.2.程序错误修复 104 6.1.3.其他资源 105 6.2.安装FILEINTEGRITYOPERATOR 105 6.2.1.使用Web控制台安装FileIntegrityOperator 105 6.2.2.使用CLI安装FileIntegrityOperator 105 6.2.3.其他资源 106 6.3.了解FILEINTEGRITYOPERATOR 107 6.3.1.了解FileIntegrity自定义资源 107 6.3.2.检查FileIntegrity自定义资源状态 107 6.3.3.FileIntegrity自定义资源阶段 107 6.3.4.了解FileIntegrityNodeStatuses对象 108 6.3.5.FileIntegrityNodeStatusCR状态类型 109 6.3.5.1.FileIntegrityNodeStatusCR成功示例 109 6.3.5.2.FileIntegrityNodeStatusCR失败状态示例 109
5 OpenShiftContainerPlatform4.7安全性与合规性 6.3.6.了解事件 111 6.4.配置自定义FILEINTEGRITYOPERATOR 112 6.4.1.查看FileIntegrity对象属性 112 6.4.2.重要属性 112 6.4.3.检查默认配置 113 6.4.4.了解默认的FileIntegrityOperator配置 113 6.4.5.提供自定义AIDE配置 114 6.4.6.定义自定义FileIntegrityOperator配置 114 6.4.7.更改自定义文件完整性配置 115 6.5.执行高级自定义FILEINTEGRITYOPERATOR任务 116 6.5.1.重新初始化数据库 116 6.5.2.机器配置集成 116 6.5.3.探索守护进程集 116 6.6.对FILEINTEGRITYOPERATOR进行故障排除 117 6.6.1.常规故障排除 117 6.6.2.检查AIDE配置 117 6.6.3.确定FileIntegrity对象的阶段 117 6.6.4.确定守护进程集的Pod是否在预期节点上运行 117 第...7..章..查..看...审..计..日..志..........................................................................................11.9............. 7.1.关于API审计日志 119 7.2.查看审计日志 120 7.3.过滤审计日志 123 7.4.收集审计日志 124 7.5.其他资源 124 第...8..章..配...置..审..计..日..志..策..略.....................................................................................1.2.5............. 8.1.关于审计日志策略配置集 125 8.2.配置审计日志策略 125 第...9..章..配...置..T..L.S..安..全..配..置..集..................................................................................1.2.7............. 9.1.了解TLS安全配置集 127 9.2.查看TLS安全配置集详情 128 9.3.为INGRESSCONTROLLER配置TLS安全配置集 130 9.4.为CONTROLPLANE配置TLS安全配置集 132 第...1.0..章..配..置...S.E..C.C..O..M..P.配...置..集..............................................................................1.3.5............. 10.1.配置默认SECCOMP配置集 135 10.2.配置自定义SECCOMP配置集 135 10.2.1.设置自定义p配置集 135 10.2.2.将自定义p配置集应用到工作负载 136 10.3.其他资源 136 第...1.1.章...允..许..从..其..他..主..机..对...A..P.I.服..务..器...进..行..基..于...J.A.V..A.S..C.R..IP..T..的..访..问............................................1.3.7............. 11.1.允许从其他主机对API服务器进行基于JAVASCRIPT的访问 137 第...1.2.章...加..密...E.T..C.D..数..据......................................................................................1.3.9............. 12.1.关于ETCD加密 139 12.2.启用ETCD加密 139 12.3.禁用ETCD加密 140 第...1.3..章..对...P.O..D..进..行..安..全...漏..洞..扫..描............................................................................1.4.3............. 13.1.运行CONTAINERSECURITYOPERATOR 143 13.2.通过CLI查询镜像安全漏洞 145
6 目录
7 OpenShiftContainerPlatform4.7安全性与合规性 第1章OPENSHIFTCONTAINERPLATFORM安全和合规性 1.1.安全概述 了解如何正确保护OpenShiftContainerPlatform集群的各个方面非常重要。
容器安全性了解OpenShiftContainerPlatform安全性的良好起点是回顾了解容器安全性中的概念。
本节和接下来的章节介绍了OpenShiftContainerPlatform中提供的容器安全措施，包括主机层、容器和编配层以及构建和应用程序层的解决方案。
这些部分还包括有关以下主题的信息： 为什么容器安全性很重要，以及它与现有安全标准相比较的情况。
哪些容器安全措施是由主机（RHCOS和RHEL）层提供的，哪些是由OpenShiftContainerPlatform提供的。
如何评估您的容器内容和漏洞来源。
如何设计您的构建和部署过程，以主动检查容器的内容。
如何通过身份验证和授权控制对容器的访问。
如何在OpenShiftContainerPlatform中保护网络和附加存储。
用于API管理和SSO的容器化解决方案。
AuditingOpenShiftContainerPlatformauditing（审计）提供一组安全相关的按时间排序的记录，记录各个用户、管理员或其他系统组件影响系统的一系列活动。
管理员可以配置审计日志策略，并查看审计日志。
证书证书供各种组件用于验证对集群的访问。
管理员可以替换默认入口证书、添加API服务器证书或添加服务证书。
您还可以查看集群使用的证书类型的更多详情：API服务器的用户提供的证书代理证书服务CA证书节点证书Bootstrap证书etcd证书olm证书用户提供的默认入口证书入口证书（Ingresscertificate）监控和集群日志记录Operator组件证书
8 第1章OPENSHIFTCONTAINERPLATFORM安全和合规性Controlplane证书 加密数据您可以为集群启用etcd加密以提供额外的数据安全层。
例如，如果etcd备份暴露给不应该获得这个数据的人员，它会帮助保护敏感数据。
漏洞扫描管理员可以使用ContainerSecurityOperator(CSO)来运行漏洞扫描，并查看有关检测到的漏洞的信息。
1.2.合规性概述 对于许多OpenShiftContainerPlatform客户，在将任何系统投入生产前需要达到一定级别的法规就绪状态或合规性。
这种法规就绪性可通过国家标准、行业标准或组织的企业管理框架来实施。
合规性检查管理员可以使用ComplianceOperator运行合规性扫描，并为发现的问题推荐补救。
文件完整性检查管理员可以使用FileIntegrityOperator在集群节点上持续运行文件完整性检查，并提供已修改的文件日志。
1.3.其他资源 了解身份验证配置内部OAuth服务器了解身份提供程序配置使用RBAC定义和应用权限管理安全性上下文约束
9 OpenShiftContainerPlatform4.7安全性与合规性 第2章容器安全性 2.1.了解容器安全性 保护容器化应用程序需要依赖于多个级别的安全性： 容器安全性从可信基础容器镜像开始，一直到经过您的CI/CD管道的容器构建过程。
重要 默认情况下，镜像流不会自动更新。
这个默认行为可能会造成安全问题，因为镜像流引用的镜像的安全更新不会自动进行。
有关如何覆盖此默认行为的详情，请参阅配置定期导入imagestreamtag。
部署容器时，其安全性取决于它运行在安全的操作系统和网络上，并在容器本身和与之交互的用户和主机之间建立明确界限。
持续安全性取决于能够扫描容器镜像以获取漏洞，并具有高效的方法来更正和替换有漏洞的镜像。
除了OpenShiftContainerPlatform等平台提供的开箱即用的功能外，您的机构可能会有自己的安全需求。
在将OpenShiftContainerPlatform放入数据中心之前，可能需要进行一定程度的合规性验证。
同样，您可能需要将自己的代理、专用硬件驱动程序或加密功能添加到OpenShiftContainerPlatform中，才能满足您机构的安全标准。
本指南全面介绍了OpenShiftContainerPlatform中提供的容器安全措施，包括主机层、容器和编配层以及构建和应用程序层的解决方案。
然后，它会指引您参考特定的OpenShiftContainerPlatform文档以帮助您实现这些安全措施。
本指南包含以下信息： 为什么容器安全性很重要，以及它与现有安全标准相比较的情况。
哪些容器安全措施是由主机（RHCOS和RHEL）层提供的，哪些是由OpenShiftContainerPlatform提供的。
如何评估您的容器内容和漏洞来源。
如何设计您的构建和部署过程，以主动检查容器的内容。
如何通过身份验证和授权控制对容器的访问。
如何在OpenShiftContainerPlatform中保护网络和附加存储。
用于API管理和SSO的容器化解决方案。
本指南的目的是了解将OpenShiftContainerPlatform用于容器化工作负载的极大安全优势，以及整个红帽生态系统在提供和保持容器安全方面发挥的作用。
它还将帮助您了解如何与OpenShiftContainerPlatform互动以实现您机构的安全目标。
2.1.1.什么是容器？ 容器将一个应用程序及其所有依赖项打包成单一镜像，可在不发生改变的情况下从开发环境提升到测试环境，再提升到生产环境。
容器可能是大型应用程序的一部分，与其他容器紧密合作。
10 第2章容器安全性 容器提供不同环境间的一致性和多个部署目标：物理服务器、虚拟机(VM)和私有或公有云。
使用容器的一些好处包括： 基础架构 在共享的Linux操作系统内核上将应用程序进程沙盒化 与虚拟机相比更简单、更轻便且密度更高 可在不同环境间移植 应用程序将我的应用程序及其所有依赖项打包 部署到任意环境只需几秒并启用CI/CD轻松访问和共享容器化组件 请参阅红帽客户门户中的了解Linux容器以查找更多有关Linux容器的信息。
如需了解有关RHEL容器工具的信息，请参阅RHEL产品文档中的构建、运行和管理容器。
2.1.2.OpenShiftContainerPlatform是什么？ OpenShiftContainerPlatform等平台的任务是自动化部署、运行和管理容器化应用程序。
作为核心功能，OpenShiftContainerPlatform依赖于es项目来提供在可扩展数据中心跨许多节点编配容器的引擎。
es是一个项目，可使用不同的操作系统和附加组件来运行，它们不提供项目的支持性保证。
因此，不同es平台的安全性可能会有所不同。
OpenShiftContainerPlatform旨在锁定es安全性，并将平台与各种扩展组件集成。
为实现这一目标，OpenShiftContainerPlatform利用了广泛的红帽开源技术生态系统，包括操作系统、身份验证、存储、网络、开发工具、基础容器镜像和其他许多组件。
OpenShiftContainerPlatform可以利用红帽的经验，发现平台本身以及在平台上运行的容器化应用程序中存在的漏洞并快速部署修复程序。
红帽的经验还涉及到在新组件可用后高效地将它们与OpenShiftContainerPlatform集成，以及根据各个客户的需求对技术进行调整。
其他资源 OpenShiftContainerPlatform架构 OpenShift安全性指南 2.2.了解主机和虚拟机安全性 容器和虚拟机都提供了将主机上运行的应用程序与操作系统分开的方法。
了解OpenShiftContainerPlatform使用的RHCOS操作系统将帮助您理解主机系统如何保护容器和主机不受彼此影响。
2.2.1.保护RedHatEnterpriseLinuxCoreOS(RHCOS)上的容器 容器简化了将许多应用程序部署在同一主机上运行的操作，每个容器启动都使用相同的内核和容器运行时。
应用程序可以归很多用户所有，并且由于是保持独立的，他们可以毫无问题地同时运行这些应用程序的不同版本甚至不兼容的版本。
在Linux中，容器只是一种特殊的进程，因此在很多方面，保护容器与保护任何其他运行的进程类似。
运 11 OpenShiftContainerPlatform4.7安全性与合规性 在Linux中，容器只是一种特殊的进程，因此在很多方面，保护容器与保护任何其他运行的进程类似。
运行容器的环境始于操作系统，它可以保护主机内核不受容器和主机上运行的其他进程的影响，同时还可以保护容器不受彼此的影响。
由于OpenShiftContainerPlatform4.7在RHCOS主机上运行，同时可选择使用RedHatEnterpriseLinux(RHEL)作为worker节点，因此以下概念将默认应用于任何已部署的OpenShiftContainerPlatform集群。
这些RHEL安全功能是确保以更加安全的方式在OpenShift中运行容器的核心所在： Linux命名空间支持创建特定全局系统资源的抽象集，使其显示为一个实例，独立于命名空间中的进程。
因此，几个容器可以同时使用相同的计算资源，而不会产生冲突。
默认情况下独立于主机的容器命名空间包括挂载表、进程表、网络接口、用户、控制组、UTS和IPC命名空间。
需要直接访问主机命名空间的容器需要具有升级权限才能请求该访问权限。
如需了解有关命名空间类型的详细信息，请参阅RHEL7容器文档中的红帽系统中的容器概述。
SELinux提供了额外一层安全性，可以使容器相互隔离并与主机隔离。
SELinux允许管理员为每个用户、应用程序、进程和文件实行强制访问控制(MAC)。
CGroups（控制组）限制、说明和隔离一组进程的资源用量（CPU、内存、磁盘I/O、网络等等）。
CGroups用于确保同一主机上的容器不会相互影响。
安全计算模式(p)配置集可以与容器关联来限制可用的系统调用。
有关p的详情，请参阅OpenShift安全性指南的第94页。
使用RHCOS部署容器可最大程度缩小主机环境并根据容器进行调整，从而减少攻击面。
CRI-O容器引擎只会实现es和OpenShift运行和管理容器所需的功能，而不像其他容器引擎一样实现面向桌面的独立功能，因此进一步减少了这一攻击面。
RHCOS是RedHatEnterpriseLinux(RHEL)的一个版本，它经过特别配置，可用作OpenShiftContainerPlatform集群上的controlplane(master)和worker节点。
因此，RHCOS适用于高效运行容器工作负载，以及es和OpenShift服务。
为了进一步保护OpenShiftContainerPlatform集群中的RHCOS系统，大多数容器（除了管理或监控主机系统本身的容器外）都应以非root用户身份运行。
要保护您自己的OpenShiftContainerPlatform集群，推荐的最佳实践是降低权限级别或创建包含最少权限的容器。
其他资源 节点如何强制实施资源限制 管理安全性上下文约束 OpenShift集群支持的平台 具有用户置备基础架构的集群的机器要求 选择如何配置RHCOS Ignition 内核参数 内核模块 FIPS加密 磁盘加密 12 第2章容器安全性 Chrony时间服务 OpenShiftContainerPlatform集群更新 2.2.2.虚拟化和容器比较 传统虚拟化提供了另一种在相同物理主机上将应用程序环境保持独立的方法。
但是，虚拟机的工作方式与容器不同。
虚拟化依赖于虚拟机监控程序启动虚拟客户机(VM)，每个虚拟机都有自己的操作系统(OS)，具体表现为运行的内核、正在运行的应用程序及其依赖项。
使用VM，虚拟机监控程序会将虚拟客户机相互隔离并与主机内核隔离。
这样可减少可访问虚拟机监控程序的个人和进程，进而缩小物理服务器上的攻击面。
尽管如此，仍然必须对安全性进行监控：一个虚拟客户机可能利用虚拟机监控程序的错误来获取对另一个虚拟机或主机内核的访问权限。
当需要修补操作系统时，必须对所有使用该操作系统的虚拟客户机进行修补。
容器可在虚拟客户机中运行，这种方式在有些用例中可能是可取的。
例如，您可能在容器中部署传统应用程序，以便将某个应用程序转移到云端。
但是，在单一主机上进行容器分离提供了一种更加轻便、灵活且易于部署的解决方案。
这种部署模型特别适合云原生应用程序。
容器通常比VM小得多，消耗的内存和CPU也更少。
请参阅RHEL7容器文档中的Linux容器与KVM虚拟化的比较，以了解容器和虚拟机之间的差别。
2.2.3.保护OpenShiftContainerPlatform 在部署OpenShiftContainerPlatform时，您可以选择安装程序置备的基础架构（有多个可用的平台）或您自己的用户置备的基础架构。
用户置备的基础架构可能有益于一些低级别的安全相关配置，如启用FIPS合规性或在第一次引导时添加内核模块。
同样，用户置备的基础架构适合用于断开连接的OpenShiftContainerPlatform部署。
请记住，在为OpenShiftContainerPlatform进行安全增强和其他配置更改方面，应包括以下目标： 尽可能保持底层节点的通用性。
您需要能够快速、轻松地以指定的方式丢弃和启动类似的节点。
尽可能通过OpenShiftContainerPlatform管理对节点的修改，而不是对节点进行直接的一次性更改。
为实现这些目标，应该在安装过程中使用MachineConfigOperator应用到各组节点的MachineConfig，通过Ignition或更高版本进行大多数节点更改。
您可以通过这种方式进行的与安全性相关的配置更改示例包括： 添加内核参数 添加内核模块 启用FIPS加密支持 配置磁盘加密 配置chrony时间服务 除了MachineConfigOperator外，还有一些其他的Operator可用来配置由ClusterVersionOperator(CVO)管理的OpenShiftContainerPlatform基础架构。
CVO可以为OpenShiftContainerPlatform集群更新的很多方面实现自动化。
2.3.强化RHCOS 13 OpenShiftContainerPlatform4.7安全性与合规性 RHCOS在创建后经过调整以部署到OpenShiftContainerPlatform中，只需对RHCOS节点进行很少更改甚至无需更改。
每个采用OpenShiftContainerPlatform的机构都对系统加强有自己的要求。
作为一个RHEL系统，RHCOS中添加了针对OpenShift的修改和功能（如Ignition、ostree和一个只读/usr，用来提供有限的不可变性），像任何RHEL系统一样，可以对它进行强化。
不同之处在于您管理强化的方式。
OpenShiftContainerPlatform及其es引擎的一个主要功能就是根据需要迅速缩放应用程序和基础架构。
除非不可避免，否则您不需要通过登录到主机并添加软件或更改设置来直接更改RHCOS。
您需要让OpenShiftContainerPlatform安装程序和controlplane管理对RHCOS的更改，以便可以在不手动干预的情况下启动新节点。
因此，如果您准备在OpenShiftContainerPlatform中强化RHCOS节点来满足安全需求，您应该同时考虑要强化的功能以及如何着手进行这种强化。
2.3.1.在RHCOS中选择要强化的功能 RHEL8安全强化指南介绍了如何处理任何RHEL系统的安全问题。
使用本指南来学习如何处理加密、评估漏洞以及评估不同服务受到的威胁。
同样，您可以了解如何扫描合规标准、检查文件完整性、执行审核以及对存储设备进行加密。
了解了您要强化的功能后，您可以决定如何在RHCOS中强化它们。
2.3.2.选择如何强化RHCOS 不建议在OpenShiftContainerPlatform中直接修改RHCOS系统。
取而代之，您应该考虑在节点池中修改系统，如worker节点和controlplane节点（也称为主节点）。
在非裸机安装中，当需要一个新节点时，您可以请求一个您所需的类型的新节点，并且它将从RHCOS镜像创建，再加上之前创建的修改。
在安装前、在安装过程中以及集群启动和运行后，您有机会修改RHCOS。
2.3.2.1.安装前强化对于裸机安装，您可以在开始OpenShiftContainerPlatform安装前为RHCOS添加强化功能。
例如，您可以在引导RHCOS安装程序时添加内核选项来开启或关闭安全功能，如SELinux或各种低级别设置，如对称多线程。
虽然裸机RHCOS安装难度更大，但有机会在开始OpenShiftContainerPlatform安装前完成操作系统更改。
如果您需要确保尽早设置某些功能，比如磁盘加密或者特殊联网设置，这一点就很重要。
2.3.2.2.安装过程中强化您可以中断OpenShift安装过程并更改Ignition配置。
通过Ignition配置，您可以将自己的文件和systemd服务添加到RHCOS节点中。
您还可以对用于安装的install-config.yaml文件进行一些基本的安全相关更改。
以这种方式添加的内容将在每个节点第一次引导时可用。
2.3.2.3.集群运行后强化在OpenShiftContainerPlatform集群启动并运行后，有几种方法可用来将强化功能应用到RHCOS： 守护进程集：如果您需要在每个节点上运行某个服务，您可以使用es的DaemonSet对象添加该服务。
机器配置：MachineConfig对象包含Ignition配置的子集，其格式相同。
通过将机器配置应用到 14 第2章容器安全性 机器配置：MachineConfig对象包含Ignition配置的子集，其格式相同。
通过将机器配置应用到所有worker或controlplane节点，您可以确保添加到集群中的同类型的下一个节点会应用相同的更改。
这里提到的所有功能在OpenShiftContainerPlatform产品文档中都有介绍。
其他资源OpenShift安全性指南选择如何配置RHCOS修改节点 手动创建安装配置文件 创建es清单和Ignition配置文件使用ISO镜像创建RedHatEnterpriseLinuxCoreOS(RHCOS)机器自定义节点 为节点添加内核参数安装配置参数-请参阅fips支持FIPS加密RHEL核心加密组件 2.4.容器镜像签名 红帽为RedHatContainerRegistries中的镜像提供签名。
在使用MachineConfigOperator（MCO）拉取到OpenShiftContainerPlatform4集群时，会自动验证这些签名。
Quay.io提供了组成OpenShiftContainerPlatform的大多数镜像，只有发行镜像会被签名。
发行镜像指的是批准的OpenShiftContainerPlatform镜像，它可以对供应链攻击提供一定程度的保护。
但是，OpenShiftContainerPlatform的一些扩展（如日志记录、监控和服务网格）会作为OperatorLifecycleManager（OLM）的Operator提供。
这些镜像来自红帽生态系统目录容器镜像registry。
要验证这些镜像在红帽registry和您的基础架构间的完整性，启用签名验证。
2.4.1.为RedHatContainerregistry启用签名验证 启用容器签名验证需要将registryURL链接到sigstore的文件，然后指定验证镜像的密钥。
流程
1.创建将registryURL链接到sigstore并指定要验证镜像的密钥的文件。
创建policy.json文件： $cat>policy.json<
2.使用base64编码格式设置用于机器配置模板的文件： $exportARC_REG=$(cat.yaml|base64-w0)$exportRIO_REG=$(catregistry.redhat.io.yaml|base64-w0)$exportPOLICY_CONFIG=$(catpolicy.json|base64-w0)
3.创建将导出的文件写入worker节点上磁盘的机器配置： 16 $cat>51-worker-rh-registry-trust.yaml<
5.创建机器配置，将导出的文件写入master节点上的磁盘： $cat>51-master-rh-registry-trust.yaml<
先决条件 您可以使用机器配置文件启用签名验证。
流程
1.在命令行中运行以下命令显示所需worker的信息： $ocdescribemachineconfigpool/worker 初始worker监控的输出示例 Name:workerNamespace: 18 第2章容器安全性 Labels:machineconfiguration.openshift.io/mco-built-in= Annotations:
3 ResourceVersion:16229 SelfLink: /apis/machineconfiguration.openshift.io/v1/machineconfigpools/worker UID: 92697796-2203-11ea-b48c-fa163e3940e5 Spec: Configuration: Name:
rendered-worker-f6819366eb455a401c42f8d96ab25c02 Source: APIVersion:machineconfiguration.openshift.io/v1 Kind:MachineConfig Name:00-worker APIVersion:machineconfiguration.openshift.io/v1 Kind:MachineConfig Name:01-worker-container-runtime APIVersion:machineconfiguration.openshift.io/v1 Kind:MachineConfig Name:01-worker-kubelet APIVersion:machineconfiguration.openshift.io/v1 Kind:MachineConfig Name:51-worker-rh-registry-trust APIVersion:machineconfiguration.openshift.io/v1 Kind:MachineConfig Name:99-worker-92697796-2203-11ea-b48c-fa163e3940e5-registries APIVersion:machineconfiguration.openshift.io/v1 Kind:MachineConfig Name:99-worker-ssh MachineConfigSelector: MatchLabels: machineconfiguration.openshift.io/role:worker NodeSelector: MatchLabels: es.io/worker: Paused: false Status: Conditions: LastTransitionTime:2019-12-19T02:03:27Z Message: Reason: Status: False Type: RenderDegraded LastTransitionTime:2019-12-19T02:03:43Z Message: Reason: Status: False Type: NodeDegraded LastTransitionTime:2019-12-19T02:03:43Z Message: Reason: Status: False Type: Degraded 19 OpenShiftContainerPlatform4.7安全性与合规性 LastTransitionTime:2019-12-19T02:28:23Z Message: Reason: Status: False Type: Updated LastTransitionTime:2019-12-19T02:28:23Z Message: Allnodesareupdatingtorendered-worker- f6819366eb455a401c42f8d96ab25c02 Reason: Status: True Type: Updating Configuration: Name:
rendered-worker-d9b3f4ffcfd65c30dcf591a0e8cf9b2e Source: APIVersion: machineconfiguration.openshift.io/v1 Kind: MachineConfig Name: 00-worker API
Version: machineconfiguration.openshift.io/v1 Kind: MachineConfig Name: 01-worker-container-runtime API
Version: machineconfiguration.openshift.io/v1 Kind: MachineConfig Name: 01-worker-kubelet API
Version: machineconfiguration.openshift.io/v1 Kind: MachineConfig Name: 99-worker-92697796-2203-11ea-b48c-fa163e3940e5-registries API
Version: machineconfiguration.openshift.io/v1 Kind: MachineConfig Name: 99-worker-ssh Degraded
MachineCount:
0 MachineCount:
1 ObservedGeneration:
3 ReadyMachineCount:
0 UnavailableMachineCount:
1 UpdatedMachineCount:
0 Events:
2.再次运行ocdescribe命令：$ocdescribemachineconfigpool/worker worker更新后的输出示例 ... LastTransitionTime:2019-12-19T04:53:09Z Message: Allnodesareupdatedwith f6819366eb455a401c42f8d96ab25c02 Reason: Status: True Type: Updated LastTransitionTime:2019-12-19T04:53:09Z Message: Reason: Status: False Type: Updating rendered-worker- 20 第
2章容器安全性 Configuration: Name:rendered-worker-f6819366eb455a401c42f8d96ab25c02 Source: APIVersion: machineconfiguration.openshift.io/v1 Kind: MachineConfig Name: 00-worker API
Version: machineconfiguration.openshift.io/v1 Kind: MachineConfig Name: 01-worker-container-runtime API
Version: machineconfiguration.openshift.io/v1 Kind: MachineConfig Name: 01-worker-kubelet API
Version: machineconfiguration.openshift.io/v1 Kind: MachineConfig Name: 51-worker-rh-registry-trust API
Version: machineconfiguration.openshift.io/v1 Kind: MachineConfig Name: 99-worker-92697796-2203-11ea-b48c-fa163e3940e5-registries API
Version: machineconfiguration.openshift.io/v1 Kind: MachineConfig Name: 99-worker-ssh Degraded
MachineCount:
0 MachineCount:
3 ObservedGeneration:
4 ReadyMachineCount:
3 UnavailableMachineCount:
0 UpdatedMachineCount:
3 ... 注意 ObservedGeneration参数显示基于控制器生成的配置的生成数量的增加数。
此控制器即使没有处理规格并生成修订，也会更新这个值。
ConfigurationSource值指向51-worker-rh-registry-trust配置。
3.使用以下命令确认policy.json文件已存在： $ocdebugnode/
4.使用以下命令确认registry.redhat.io.yaml文件已存在： $ocdebugnode/
5.使用以下命令确认.yaml文件已存在： $ocdebugnode/
这种法规就绪状态可通过国家标准、行业标准或机构的企业监管框架来施加。
2.5.1.了解合规性及风险管理 FIPS合规性是高安全性环境中所需的最重要的组件之
一，可确保节点上只允许使用支持的加密技术。
重要只有在x86_64架构中的OpenShiftContainerPlatform部署支持FIPS验证的/ModulesinProcess加密库。
要了解红帽对OpenShiftContainerPlatform合规框架的观点，请参阅OpenShift安全性指南手册中的“风险管理和法规就绪状态”一章。
其他资源在FIPS模式下安装集群 2.6.保护容器内容 要确保容器内所含内容的安全性，需要以可信的基础镜像（如红帽通用基础镜像）开始，并添加可信软件。
为了检查容器镜像的持续安全性，红帽及第三方都有可用于扫描镜像的工具。
2.6.1.确保容器内安全 应用程序和基础架构由随时可用的组件组成，许多组件都是开源软件包，如Linux操作系统、JBossWebServer、PostgreSQL和Node.js。
这些软件包也有容器化版本可用。
然而，您需要知道软件包最初来自哪里，使用什么版本，是谁构建的，以及软件包内是否有恶意代码。
需要回答的一些问题包括： 容器内的内容是否会破坏您的基础架构？应用程序层是否存在已知的漏洞？运行时和操作系统层是不是最新的？通过从红帽通用基础镜像(UBI)构建容器，您可以保证您的容器镜像基础由RedHatEnterpriseLinux中包含的同一RPM打包软件组成。
使用或重新分发UBI镜像不需要订阅。
为确保容器本身持续安全，安全扫描功能（直接从RHEL使用或添加到OpenShiftContainerPlatform）可在您使用的镜像有漏洞时发出警告。
RHEL中提供了OpenSCAP镜像扫描，并且可添加ContainerSecurityOperator来检查OpenShiftContainerPlatform中使用的容器镜像。
2.6.2.使用UBI创建可重新分发的镜像 要创建容器化应用程序，您通常以可信基础镜像开始，该镜像提供的组件通常由操作系统提供。
这些组件包括库、实用程序以及应用程序在操作系统文件系统中应该看到的其他功能。
创建红帽通用基础镜像(UBI)是为了鼓励任何人在构建其自己的容器时都先使用一个完全由RedHat 23 OpenShiftContainerPlatform4.7安全性与合规性 创建红帽通用基础镜像(UBI)是为了鼓励任何人在构建其自己的容器时都先使用一个完全由RedHatEnterpriseLinuxrpm软件包及其他内容组成的容器镜像。
这些UBI镜像会定期更新，以应用最新的安全补丁，并可自由地与构建用来包含您自己的软件的容器镜像一起使用和重新分发。
搜索红帽生态系统目录，以便查找和检查不同UBI镜像的健康状态。
作为创建安全容器镜像的人员，您可能对两种通用UBI镜像类型感兴趣： UBI：RHEL7和8有标准的UBI镜像（ubi7/ubi和ubi8/ubi），以及基于这些系统的最小镜像（ubi7/ubi-minimal和ubi8/ubi-mimimal）。
所有这些镜像已预先配置，以指向您可以使用标准yum和dnf命令添加到构建的容器镜像中的免费RHEL软件存储库。
红帽鼓励人们在其他发行版（如Fedora和Ubuntu）上使用这些镜像。
RedHatSoftwareCollections：在红帽生态系统目录中搜索rhscl/以查找为用作特定应用程序类型的基础镜像而创建的镜像。
例如，有Apachehttpd(rhscl/httpd-*)、Python(rhscl/python*),Ruby(rhscl/ruby-*)、Node.js(rhscl/nodejs-*)和Perl(rhscl/perl-*)rhscl镜像。
请记住，虽然UBI镜像可自由使用且可重新发布，但红帽对这些镜像的支持只能通过RedHat产品订阅获得。
请参阅RedHatEnterpriseLinux文档中的使用红帽通用基础镜像来获得有关如何使用标准、最小和initUBI镜像作为构建基础的信息。
2.6.3.RHEL中的安全扫描 对于RedHatEnterpriseLinux(RHEL)系统，可从openscap-utils软件包中获得OpenSCAP扫描功能。
在RHEL中，您可以使用openscap-podman命令扫描针镜像中的漏洞。
请参阅RedHatEnterpriseLinux文档中的扫描容器和容器镜像中的漏洞。
OpenShiftContainerPlatform可让您在CI/CD过程中利用RHEL扫描程序。
例如，您可以集成静态代码分析工具来测试源代码中的安全漏洞，并集成软件组成分析工具来标识开源库，以提供关于这些库的元数据，如已知漏洞。
2.6.3.1.扫描OpenShift镜像对于在OpenShiftContainerPlatform中运行并且从RedHatQuayregistry中拉取的容器镜像，您可以使用Operator来列出这些镜像的漏洞。
ContainerSecurityOperator可以添加到OpenShiftContainerPlatform中，为添加到所选命名空间的镜像提供漏洞报告。
RedHatQuay的容器镜像扫描由Clair安全扫描程序执行。
在RedHatQuay中，Clair可以搜索和报告从RHEL、CentOS、Oracle、Alpine、Debian和Ubuntu操作系统软件构建的镜像中的漏洞。
2.6.4.集成外部扫描 OpenShiftContainerPlatform使用对象注解来扩展功能。
外部工具（如漏洞扫描程序）可以使用元数据为镜像对象添加注解，以汇总结果和控制Pod执行。
本节描述了该注解的公认格式，以便在控制台中可靠使用它来为用户显示有用的数据。
2.6.4.1.镜像元数据镜像质量数据有多种不同的类型，包括软件包漏洞和开源软件(OSS)许可证合规性。
另外，该元数据的供应商可能不止一个。
为此，保留了以下注解格式： quality.images.openshift.io/
URL或更多详细信息。
必需，以便用 户可以验证数据。
字符串 scannerVersion 否 扫描程序版本 字符串 compliant 否 合规性通过或未通过 布尔值 summary 否 找到的问题摘要 列表（请参阅下表） summary
字段必须遵循以下格式：表2.3.Summary字段值格式 25 OpenShiftContainerPlatform4.7安全性与合规性 字段label dataseverityIndexreference 描述 类型 显示组件标签（例如："critical"、"important"、"moderate"、"low"或"health"） 字符串 此组件的数据（例如：发现的漏洞计数或分数） 字符串 组件索引，允许对图形表示进行排整数序和分配。
该值范围为0..3，其中0=low。
信息来源的URL或更多详细信息。
可选。
字符串 2.6.4.1.2.注解值示例 本示例显示了一个镜像的OpenSCAP注解，带有漏洞概述数据以及一个合规性布尔值： OpenSCAP注解 {"name":"OpenSCAP","description":"OpenSCAPvulnerabilityscore","timestamp":"2016-09-08T05:04:46Z","reference":"/930492",pliant":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}] } 本例演示了红帽生态系统目录注解中镜像的容器镜像部分，包含健康索引数据以及获取更多详细信息的外部URL: 红帽生态系统目录注解 {"name":"RedHatEcosystemCatalog","description":"Containerhealthindex","timestamp":"2016-09-08T05:04:46Z","reference":"/errata/RHBA-2016:1566",pliant":null,"scannerVersion":"1.2","summary":[ 26 {"label":"Healthindex","data":"B","severityIndex":
1,"reference":null}]} 第2章容器安全性 2.6.4.2.为镜像对象添加注解 虽然OpenShiftContainerPlatform最终用户操作针对的是镜像流对象，但会使用安全元数据为镜像对象添加注解。
镜像对象是集群范围的，指向可能由多个镜像流和标签引用的单一镜像。
2.6.4.2.1.注解CLI命令示例 将
1,"reference":null}]"}' 2.6.4.3.控制Pod执行使用images.openshift.io/deny-execution镜像策略，以编程方式控制镜像是否可以运行。
2.6.4.3.1.注解示例 annotations:images.openshift.io/deny-execution:true 2.6.4.4.集成参考 在大多数情况下，漏洞扫描程序等外部工具会开发一个脚本或插件来监视镜像更新，执行扫描，并使用结果为相关的镜像对象添加注解。
通常，这个自动化过程会调用OpenShiftContainerPlatform4.7RESTAPI来编写注解。
有关RESTAPI的常规信息，请参阅OpenShiftContainerPlatformRESTAPI。
2.6.4.4.1.RESTAPI调用示例 以下使用curl的示例调用会覆盖注解值。
请务必替换
修补API调用 $curl-XPATCH\-H"Authorization:Bearer
1,'reference':null}]}" }}} 其他资源 镜像流对象 2.7.安全地使用容器REGISTRY 容器registry存储容器镜像以便： 使镜像可供其他用户访问 将镜像组织到可包含多个镜像版本的存储库中 选择性地根据不同的身份验证方法限制对镜像的访问，或者将其设为可公开使用 有一些公共容器registry（如Quay.io和DockerHub）可供很多个人和机构共享其镜像。
红帽Registry提供支持的红帽和合作伙伴镜像，而红帽生态系统目录为这些镜像提供了详细的描述和健康状态检查。
要管理自己的registry，您可以购买一个容器registry，如RedHatQuay。
从安全角度来说，有些registry提供了特殊的功能来检查并改进容器的健康状态。
例如，RedHatQuay通过Clair安全扫描程序提供容器漏洞扫描功能，提供构建触发器以在GitHub和其他位置的源代码发生更改时自动重建镜像，并支持使用基于角色的访问控制(RBAC)来保护对镜像的访问。
2.7.1.知道容器来自哪里？ 您可以使用一些工具来扫描和跟踪您下载和部署的容器镜像的内容。
但是，容器镜像有很多公共来源。
在使用公共容器registry时，您可以使用可信源添加一层保护。
2.7.2.不可变和已认证的容器 在管理不可变容器时，消耗安全更新尤其重要。
不可变容器是在运行时永远不会更改的容器。
当您部署不可变容器时，您不会介入正在运行的容器来替换一个或多个二进制文件。
从操作角度来说，您可以重建并重新部署更新的容器镜像以替换某个容器，而不是更改该容器。
红帽的已认证镜像： 在平台组件或层中没有已知漏洞 在RHEL平台间兼容，从裸机到云端 受红帽支持 28 第2章容器安全性 已知漏洞列表不断扩展，因此您必须一直跟踪部署的容器镜像的内容以及新下载的镜像。
您可以使用红帽安全公告(RHSA)来提醒您红帽的已认证容器镜像中出现的任何新问题，并指引您找到更新的镜像。
另外，您还可以访问红帽生态系统目录查找每个红帽镜像的各种安全相关问题。
2.7.3.从红帽Registry和生态系统目录获取容器 红帽在红帽生态系统目录的容器镜像部分列出了适用于红帽产品和合作伙伴产品的已认证容器镜像。
在该目录中，您可以查看每个镜像的详情，包括CVE、软件包列表和健康状态分数。
红帽镜像实际存储在所谓的红帽Registry中，其具体代表为公共容器registry()和经过身份验证的registry(registry.redhat.io)。
这两者基本包括同一组容器镜像，其中registry.redhat.io包括了一些需要使用红帽订阅凭证进行身份验证的额外镜像。
红帽会监控容器内容以了解漏洞，并定期进行更新。
当红帽发布安全更新（如glibc、DROWN或DirtyCow的修复程序）时，任何受影响的容器镜像也会被重建并推送到RedHatRegistry。
红帽使用healthindex来反映通过红帽生态系统目录提供的每个容器的安全风险。
由于容器消耗红帽提供的软件和勘误表流程，旧的、过时的容器不安全，而全新容器则更安全。
为了说明容器的年龄，红帽生态系统目录使用一个等级系统。
新鲜度等级是一个镜像可用的最旧、最严重的安全公告衡量标准。
“A”比“F”状态更新。
如需了解这个等级系统的更多详情，请参阅RedHatEcosystemCatalog内部使用的容器健康状态索引等级。
如需详细了解与红帽软件相关的安全更新和漏洞，请参阅红帽产品安全中心。
查看红帽安全公告以搜索具体公告和CVE。
2.7.4.OpenShiftContainerRegistry OpenShiftContainerPlatform包括OpenShiftContainerRegistry，它是作为平台集成组件运行的私有registry，可用于管理容器镜像。
OpenShiftContainerRegistry提供基于角色的访问控制，供您管理谁可以拉取和推送哪些容器镜像。
OpenShiftContainerPlatform还支持与其他您可能已经使用的私有registry集成，如RedHatQuay。
其他资源 集成的OpenShiftContainerPlatformregistry 2.7.5.使用RedHatQuay存储容器 RedHatQuay是红帽的一个企业级容器registry产品。
RedHatQuay的开发是通过上游ProjectQuay完成的。
RedHatQuay可用于在内部部署，或通过RedHatQuay在Quay.io的托管版本部署。
与安全性相关的RedHatQuay功能包括： 时间机器：允许带有旧标签的镜像在一段设定时间后或基于用户选择的过期时间过期。
存储库镜像：让您出于安全原因为其他registry创建镜像，如在公司防火墙后面的RedHatQuay上托管公共存储库，或出于性能原因让registry更接近使用的位置。
操作日志存储：将RedHatQuay日志输出保存到Elasticsearch存储，以便稍后进行搜索和分析。
Clair安全扫描：根据每个容器镜像的来源，针对各种Linux漏洞数据库扫描镜像。
内部身份验证：使用默认本地数据库处理面向RedHatQuay的RBAC身份验证，或者从 29 OpenShiftContainerPlatform4.7安全性与合规性内部身份验证：使用默认本地数据库处理面向RedHatQuay的RBAC身份验证，或者从LDAP、Keystone(OpenStack)、JWT自定义身份验证或ExternalApplicationToken身份验证中选择。
外部授权(OAuth)：允许通过GitHub、GitHubEnterprise或Google身份验证对RedHatQuay进行授权。
访问设置：生成令牌，允许从docker、rkt、匿名访问、用户创建的帐户、加密客户端密码或前缀用户名自动完成访问RedHatQuay。
RedHatQuay不断与OpenShiftContainerPlatform持续集成，包含几个特别值得关注的OpenShiftContainerPlatformOperator。
QuayBridgeOperator可让您将OpenShiftContainerPlatform内部registry替换为RedHatQuay。
QuayContainerSecurityOperator可让您检查在OpenShiftContainerPlatform中运行并从RedHatQuayregistry拉取的镜像的漏洞。
2.8.保护构建过程 在容器环境中，软件构建过程是生命周期中应用程序代码与所需的运行时库集成的阶段。
管理此构建过程是保护软件堆栈的关键。
2.8.1.一次构建，随处部署 使用OpenShiftContainerPlatform作为容器构建的标准平台可保证构建环境的安全。
遵循“一次构建，随处部署”的原则可确保构建过程的产品就是在生产环境中部署的产品。
保持容器的不可变性也是很重要的。
您不应该修补运行中的容器，而应该重建并重新部署这些容器。
随着您的软件逐步进入构建、测试和生产阶段，组成软件供给链的工具必须是可信的。
下图演示了可整合到容器化软件的可信软件供应链中的流程和工具： OpenShiftContainerPlatform可以与可信代码存储库（如GitHub）和开发平台（如Che）集成，用于创建和管理安全代码。
单元测试可以依赖Cucumber和JUnit。
您可以通过Anchore或Twistlock检查容器中的漏洞和合规问题，并使用镜像扫描工具，如AtomicScan或Clair。
Sysdig等工具可以提供对容器化应用程序的持续监控。
2.8.2.管理构建 您可以使用Source-to-Image(S2I)将源代码和基础镜像组合起来。
构建器镜像利用S2I使您的开发和运 30 第2章容器安全性 您可以使用Source-to-Image(S2I)将源代码和基础镜像组合起来。
构建器镜像利用S2I使您的开发和运维团队能够就可重复生成的构建环境展开合作。
对于可作为通用基础镜像(UBI)镜像的RedHatS2I镜像，您现在可以使用从真实RHELRPM软件包构建的基础镜像自由重新分发您的软件。
红帽取消了订阅限制以允许这一操作。
当开发人员使用构建镜像通过Git提交某个应用程序的代码时，OpenShiftContainerPlatform可以执行以下功能： 通过使用代码存储库上的Webhook或其他自动持续集成(CI)过程进行触发，以从可用的工件、S2I构建器镜像和新提交的代码中自动编译新镜像。
自动部署新构建的镜像以进行测试。
将测试镜像提升到生产环境中，以使用CI过程自动进行部署。
您可以使用集成的OpenShiftContainerRegistry来管理对最终镜像的访问。
S2I和原生构建镜像会自动推送到OpenShiftContainerRegistry。
除了包含的用于CI的Jenkins外，您还可以使用RESTfulAPI将您自己的构建和CI环境与OpenShiftContainerPlatform集成，并使用与API兼容的镜像registry。
2.8.3.在构建期间保护输入 在某些情况下，构建操作需要凭证才能访问依赖的资源，但这些凭证最好不要在通过构建生成的最终应用程序镜像中可用。
您可以定义输入secret以实现这一目的。
例如，在构建Node.js应用程序时，您可以为Node.js模块设置私有镜像。
要从该私有镜像下载模块，您必须为包含URL、用户名和密码的构建提供自定义的.npmrc文件。
为安全起见，不应在应用程序镜像中公开您的凭证。
通过使用此示例场景，您可以在新BuildConfig对象中添加输入secret：
1.如果secret不存在，则进行创建： 31 OpenShiftContainerPlatform4.7安全性与合规性 $occreatesecretgenericsecret-npmrc--from-file=.npmrc=~/.npmrc这会创建一个名为secret-npmrc的新secret，其包含~/.npmrc文件的base64编码内容。
2.将该secret添加到现有BuildConfig对象的source部分中： source:git:uri:/nodejs-ex.gitsecrets:-destinationDir:.secret:name:secret-npmrc
3.要在新BuildConfig对象中包含该secret，请运行以下命令：$ocnew-build\openshift/nodejs-010-centos7~/nodejs-ex.git\--build-secretsecret-npmrc 2.8.4.设计构建过程 您可以对容器镜像管理和构建过程进行设计以使用容器层，以便您可以分开控制。
例如，一个运维团队负责管理基础镜像，而架构师则负责管理中间件、运行时、数据库和其他解决方案。
然后开发人员可以专注于应用程序层并专注于编写代码。
由于每天都会识别出新的漏洞，因此您需要一直主动检查容器内容。
要做到这一点，您应该将自动安全测试集成到构建或CI过程中。
例如： SAST/DAST–静态和动态安全测试工具。
根据已知漏洞进行实时检查的扫描程序。
这类工具会为您的容器中的开源软件包编目，就任何已知漏洞通知您，并在之前扫描的软件包中发现新漏洞时为您提供最新信息。
您的CI过程应该包含相应的策略，为构建标记出通过安全扫描发现的问题，以便您的团队能够采取适当行动来解决这些问题。
您应该为自定义构建容器签名，以确保在构建和部署之间不会修改任何内容。
32 第2章容器安全性利用GitOps方法，您不仅可以使用相同的CI/CD机制来管理应用程序配置，还可以管理OpenShiftContainerPlatform基础架构。
2.8.5.构建Knative无服务器应用程序 借助es和Kourier，您可以在OpenShiftContainerPlatform中使用OpenShiftServerless来构建、部署和管理无服务器应用程序。
和其他构建一样，您可以使用S2I镜像来构建容器，然后使用Knative服务提供它们。
通过OpenShiftContainerPlatformWeb控制台的Topology视图查看Knative应用程序构建。
2.8.6.其他资源 理解镜像构建触发和修改构建创建构建输入输入secret和配置映射关于OpenShiftServerless使用Topology视图查看应用程序组成情况 2.9.部署容器 您可以使用各种技术来确保所部署的容器包含最新的生产级内容，并确保这些容器没有被修改。
这些技术包括设置构建触发器以纳入最新的代码，以及使用签名来确保容器来自可信源且未修改。
2.9.1.使用触发器控制容器部署 如果在构建过程中发生某种情况，或者部署了镜像后发现一个漏洞，您可以使用基于策略的自动化部署工具进行修复。
您可以使用触发器来重建和替换镜像，确保不可变的容器进程，而不是修补正在运行的容器，这种做法是不推荐的。
33 OpenShiftContainerPlatform4.7安全性与合规性 例如，您使用三个容器镜像层构建了一个应用程序：核心、中间件和应用程序。
由于在核心镜像中发现了一个问题，该镜像被重建。
构建完成后，该镜像被推送到OpenShiftContainerRegistry。
OpenShiftContainerPlatform检测到镜像已更改，并根据定义的触发器自动重建并部署应用程序镜像。
这一更改包含了固定的库，并确保产品代码与最新镜像是一致的。
您可以使用ocsettriggers命令来设置部署触发器。
例如，要为名为deployment-example的部署设置触发器： $ocsettriggersdeploy/deployment-example\--from-image=example:latest\--containers=web 2.9.2.控制可以部署的镜像源 务必要确保实际部署了所需的镜像，还要确保包括容器内容的镜像来自可信源，且尚未更改。
加密签名提供了这一保证。
OpenShiftContainerPlatform可让集群管理员应用广泛或狭窄的安全策略，以反应部署环境和安全要求。
该策略由两个参数定义： 一个或多个带有可选项目命名空间的registry 34 第2章容器安全性 信任类型，如接受、拒绝或要求公钥 您可以使用这些策略参数来允许、拒绝整个registry、部分registry或单独的镜像，或者要求具有信任关系。
使用可信公钥，您可以确保以加密的方式验证源。
该策略规则应用于节点。
策略可以在所有节点中统一应用，或针对不同的节点工作负载（例如：构建、区域或环境）加以应用。
镜像签名策略文件示例 {"default":[{"type":"reject"}],"transports":{"docker":{"":[{"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//pubkey"}],"172.30.1.1:5000":[{"type":"reject"}]}} } 该策略可以在节点上保存为/etc/containers/policy.json。
最好使用新的MachineConfig对象将此文件保存到节点。
这个示例强制执行以下规则： 要求RedHatRegistry()中的镜像由红帽公钥签名。
要求openshift命名空间中的OpenShiftContainerRegistry中的镜像由RedHat公钥签名。
要求production命名空间中的OpenShiftContainerRegistry中的镜像由的公钥签名。
拒绝未由全局默认定义指定的所有其他registry。
2.9.3.使用签名传输 签名传输是一种存储和检索二进制签名blob的方法。
签名传输有两种类型。
35 OpenShiftContainerPlatform4.7安全性与合规性 Atomic：由OpenShiftContainerPlatformAPI管理。
Docker：作为本地文件或通过Web服务器提供。
OpenShiftContainerPlatformAPI负责管理使用atomic传输类型的签名。
您必须将使用此签名类型的镜像存储在OpenShiftContainerRegistry中。
由于docker/distributionextensionsAPI会自动发现镜像签名端点，因此不需要额外的配置。
使用docker传输类型的签名由本地文件或者Web服务器提供。
这些签名更为灵活，您可以提供来自任何容器镜像registry的镜像，并使用独立的服务器来提供二进制签名。
但是，docker传输类型需要进行额外的配置。
您必须为节点配置签名服务器的URI，方法是将随机命名的YAML文件放在主机系统上的目录中，默认为/etc/containers/registries.d。
YAML配置文件包含registryURI和签名服务器URI，或sigstore： Registries.d文件示例 docker::sigstore:/webassets/docker/content/sigstore 在这个示例中，RedHatRegistry是为docker传输类型提供签名的签名服务器。
其URI在sigstore参数中定义。
您可以将此文件命名为/etc/containers/registries.d/.yaml，并使用MachineConfigOperator自动将文件放在集群中的每个节点上。
由于策略和registry.d文件由容器运行时动态加载，因此不需要重启服务。
2.9.4.创建secret和配置映射 Secret对象类型提供了一种机制来保存敏感信息，如密码、OpenShiftContainerPlatform客户端配置文件、dockercfg文件和私有源存储库凭证。
Secret将敏感内容与Pod分离。
您可以使用卷插件将secret信息挂载到容器中，系统也可以使用secret代表Pod执行操作。
例如，要在部署配置中添加secret，以便它可以访问私有镜像存储库，请执行以下操作： 流程
1.登陆到OpenShiftContainerPlatformWeb控制台。
2.创建新项目。
3.导航到Resources→Secrets并创建新secret。
将SecretType设为ImageSecret，并将AuthenticationType设为ImageRegistryCredentials，以输入用于访问私有镜像存储库的凭证。
4.在创建部署配置时（例如，从AddtoProject→DeployImage页面），将PullSecret设置为您的新secret。
配置映射与secret类似，但设计为能支持与不含敏感信息的字符串配合使用。
ConfigMap对象包含配置数据的键值对，这些数据可在Pod中消耗或用于存储控制器等系统组件的配置数据。
2.9.5.自动化持续部署 您可以将自己的持续部署(CD)工具与OpenShiftContainerPlatform集成。
利用CI/CD和OpenShiftContainerPlatform，您可以自动执行重建应用程序的过程，以纳入最新的修 36 第2章容器安全性 利用CI/CD和OpenShiftContainerPlatform，您可以自动执行重建应用程序的过程，以纳入最新的修复、测试，并确保它在环境中随处部署。
其他资源输入secret和配置映射 2.10.保护容器平台 OpenShiftContainerPlatform和esAPI是大规模自动化容器管理的关键。
API用于：验证并配置Pod、服务和复制控制器的数据。
在收到传入请求时执行项目验证，并对其他主要系统组件调用触发器。
OpenShiftContainerPlatform中基于es的安全相关功能包括：多租户，将基于角色的访问控制和网络策略组合起来，以在多个级别上隔离容器。
准入插件，在API和向API发出请求的各方之间形成界限。
OpenShiftContainerPlatform使用Operator来自动化和简化es级别安全功能的管理。
2.10.1.使用多租户隔离容器 多租户允许OpenShiftContainerPlatform集群上由多个用户拥有并在多个主机和命名空间中运行的应用程序保持相互隔离并与外部攻击隔离。
要获取多租户，您可以将基于角色的访问控制(RBAC)应用到es命名空间。
在es中，命名空间是应用程序可以独立于其他应用程序运行的区域。
OpenShiftContainerPlatform使用和扩展命名空间的方式是添加额外的注解，包括在SELinux中的MCS标签，并将这些扩展命名空间标识为项目。
在项目范围内，用户可以维护自己的集群资源，包括服务帐户、策略、限制和各种其他对象。
可将RBAC对象分配给项目，以便授权所选用户访问这些项目。
该授权采用规则、角色和绑定的形式：规则会定义用户可在项目中创建或访问的内容。
角色是您可以绑定到所选用户或组的规则集合。
绑定会定义用户或组与角色之间的关联。
本地RBAC角色和绑定将用户或组附加到特定项目。
集群RBAC可将集群范围的角色和绑定附加到集群中的所有项目。
有默认的集群角色可以分配，用来提供admin、basic-user、cluster-admin和clusterstatus访问。
2.10.2.使用准入插件保护controlplane RBAC可控制用户和组与可用项目之间的访问规则，而准入插件可定义对OpenShiftContainerPlatform主API的访问。
准入插件形成一个由以下部分组成的规则链： 默认准入插件：这些插件实现了一组默认策略和资源限制以应用于OpenShiftContainerPlatformcontrolplane的组件。
变异准入插件：这些插件会动态地扩展准入链。
它们调用Webhook服务器，不仅可对请求进行身份验证，还可修改所选资源。
37 OpenShiftContainerPlatform4.7安全性与合规性 验证准入插件：这些插件验证所选资源的请求，不仅可验证请求，还可确保资源不会再次更改。
API请求经过一个链中的准入插件，沿途的任何失败都会导致请求遭到拒绝。
每个准入插件都与特定资源关联，且只响应这些资源的请求。
2.10.2.1.安全性上下文约束(SCC)您可以使用安全性上下文约束(SCC)定义Pod运行必须满足的一组条件，以便其能被系统接受。
可由SCC管理的一些方面包括： 运行特权容器容器可请求添加的功能将主机目录用作卷。
容器的SELinux上下文。
容器用户ID。
如果具有所需的权限，您可以根据需要将默认SCC策略调整为更宽松。
2.10.2.2.为服务帐户授予角色就像为用户分配基于角色的访问一样，您可以为服务帐户分配角色。
为每个项目创建的默认服务帐户有三个。
服务帐户： 范围限制为特定项目名称来自其项目会被自动分配一个API令牌和凭证来访问OpenShiftContainerRegistry与平台组件关联的服务帐户自动使其密钥轮转。
2.10.3.认证和授权 2.10.3.1.使用OAuth控制访问您可以通过身份验证和授权使用API访问控制来保护容器平台。
OpenShiftContainerPlatformmaster包含内置的OAuth服务器。
用户可以获取OAuth访问令牌来对自身进行API身份验证。
作为管理员，您可以使用用户身份供应商（如LDAP、GitHub或Google）配置OAuth以进行身份验证。
用户身份供应商默认用于新的OpenShiftContainerPlatform部署，但您可以在初始安装时或安装后进行此配置。
2.10.3.2.API访问控制和管理应用程序可以拥有多个独立的API服务，这些服务具有不同的端点需要管理。
OpenShiftContainerPlatform包含3scaleAPI网关的容器化版本，以便您管理API并控制访问。
3scale为您提供用于API身份验证和安全性的各种标准选项，它们可单独或组合起来用于发布凭证和控制访问：标准API密钥、应用程序ID和密钥对以及OAuth2.0。
您可以限制对特定端点、方法和服务的访问，并为用户组应用访问策略。
您可以通过应用程序计划来为各 38 第2章容器安全性 您可以限制对特定端点、方法和服务的访问，并为用户组应用访问策略。
您可以通过应用程序计划来为各组开发人员设置API使用率限制并控制流量。
有关使用容器化3scaleAPI网关APIcastv2的教程，请参阅3scale文档中的在RedHatOpenShift上运行APIcast。
2.10.3.3.红帽单点登录通过红帽单点登录服务器，您可以提供基于标准的Web单点登录功能，包括SAML2.0、OpenIDConnect和OAuth2.0，从而保护应用程序。
该服务器可充当基于SAML或OpenIDConnect的用户身份供应商(IdP)，使用基于标准的令牌在您的企业用户目录或用于身份信息的第三方用户身份供应商与您的应用程序之间进行调和。
您可以将红帽单点登录与基于LDAP的目录服务集成，包括MicrosoftActiveDirectory和RedHatEnterpriseLinuxIdentityManagement。
2.10.3.4.安全自助服务Web控制台OpenShiftContainerPlatform提供了一个自助服务Web控制台，以确保团队在没有授权的情况下无法访问其他环境。
OpenShiftContainerPlatform通过提供以下功能来确保安全多租户master： 使用传输层安全(TLS)访问master使用X.509证书或OAuth访问令牌访问API服务器通过项目配额限制异常令牌可以造成的破坏 Etcd服务不直接向集群公开 2.10.4.为平台管理证书 OpenShiftContainerPlatform的框架中有多个组件，它们使用基于REST的HTTPS通信，通过TLS证书利用加密功能。
OpenShiftContainerPlatform的安装程序会在安装过程中配置这些证书。
生成此流量的一些主要组件如下： master（API服务器和控制器） etcd节点 registry路由器 2.10.4.1.配置自定义证书您可以在初
声明：
该资讯来自于互联网网友发布，如有侵犯您的权益请联系我们。