5.5. Compliance Operator 扫描管理
5.5.1. 支持的合规性配置集
有多个配置集可用于安装 Compliance Operator(CO)。您可以使用以下配置集来评估集群中可能存在的问题,但只使用它们并不会保证符合特定配置集。
Compliance Operator 可能会报告有关受管平台(如 OpenShift Dedicated、Red Hat OpenShift Service on AWS)和 Azure Red Hat OpenShift 的不正确的结果。如需更多信息,请参阅红帽知识库解决方案 #6983418。
5.5.1.1. 合规性配置集
Compliance Operator 提供以下合规配置集:
profile | 配置集标题 | Application | Compliance Operator 版本 | 行业标准基准 | 支持的构架 |
---|---|---|---|---|---|
rhcos4-stig | Defense Information Systems Agency Security Technical Implementation Guide (DISA STIG) for Red Hat Openshift | 节点 | 1.3.0+ | DISA-STIG [1] |
|
ocp4-stig-node | Defense Information Systems Agency Security Technical Implementation Guide (DISA STIG) for Red Hat Openshift | 节点 | 1.3.0+ | DISA-STIG [1] |
|
ocp4-stig | Defense Information Systems Agency Security Technical Implementation Guide (DISA STIG) for Red Hat Openshift | 平台 | 1.3.0+ | DISA-STIG [1] |
|
ocp4-cis | CIS Red Hat OpenShift Container Platform 4 Benchmark v1.4.0 | 平台 | 1.2.0+ | CIS Benchmarks ™ [1] |
|
ocp4-cis-node | CIS Red Hat OpenShift Container Platform 4 Benchmark v1.4.0 | 节点 [2] | 1.2.0+ | CIS Benchmarks ™ [1] |
|
ocp4-e8 | Australian Cyber Security Centre (ACSC) Essential Eight | 平台 | 0.1.39+ |
| |
ocp4-moderate | NIST 800-53 Moderate-Impact Baseline for Red Hat OpenShift - Platform 级别 | 平台 | 0.1.39+ |
| |
rhcos4-e8 | Australian Cyber Security Centre (ACSC) Essential Eight | 节点 | 0.1.39+ |
| |
rhcos4-moderate | NIST 800-53 Moderate-Impact Baseline for Red Hat Enterprise Linux CoreOS | 节点 | 0.1.39+ |
| |
ocp4-moderate-node | NIST 800-53 Moderate-Impact Baseline for Red Hat OpenShift - 节点级别 | 节点 [2] | 0.1.44+ |
| |
ocp4-nerc-cip | Red Hat OpenShift Container Platform 的 North American Electric Reliability Corporation (NERC) Critical Infrastructure Protection (CIP) cybersecurity 标准 - 平台级别 | 平台 | 0.1.44+ |
| |
ocp4-nerc-cip-node | Red Hat OpenShift Container Platform 的 North American Electric Reliability Corporation (NERC) Critical Infrastructure Protection (CIP) cybersecurity 标准配置集 - 节点级别 | 节点 [2] | 0.1.44+ |
| |
rhcos4-nerc-cip | Red Hat Enterprise Linux CoreOS 的 North American Electric Reliability Corporation (NERC) Critical Infrastructure Protection (CIP) cybersecurity 标准配置集 | 节点 | 0.1.44+ |
| |
ocp4-pci-dss | PCI-DSS v3.2.1 Control Baseline for Red Hat OpenShift Container Platform 4 | 平台 | 0.1.47+ |
| |
ocp4-pci-dss-node | PCI-DSS v3.2.1 Control Baseline for Red Hat OpenShift Container Platform 4 | 节点 [2] | 0.1.47+ |
| |
ocp4-high | NIST 800-53 HighImpact Baseline for Red Hat OpenShift - Platform 级别 | 平台 | 0.1.52+ |
| |
ocp4-high-node | NIST 800-53 HighImpact Baseline for Red Hat OpenShift - 节点级别 | 节点 [2] | 0.1.52+ |
| |
rhcos4-high | NIST 800-53 high-Impact Baseline for Red Hat Enterprise Linux CoreOS | 节点 | 0.1.52+ |
|
- 要找到 CIS OpenShift Container Platform v4 Benchmark,进入 CIS Benchmarks 并点 Download Latest CIS Benchmark,然后注册以下载基准。
- 节点配置集必须与相关的 Platform 配置集一起使用。如需更多信息,请参阅 Compliance Operator 配置集类型。
5.5.1.1.1. 关于扩展合规配置集
有些合规配置集会包括需要遵循行业最佳实践的控制,从而导致一些配置集会扩展其他配置集。将 Center for Internet Security (CIS) 的最佳实践与 National Institute of Standards and Technology (NIST) 安全架构结合,可以建立一个安全且合规的环境。
例如,NIST High-Impact 和 Moderate-Impact 配置集将 CIS 配置集扩展来实现合规性。因此,通过扩展合规配置集,就无需在单一集群中运行这两个配置集。
profile | 扩展 |
---|---|
ocp4-pci-dss | ocp4-cis |
ocp4-pci-dss-node | ocp4-cis-node |
ocp4-high | ocp4-cis |
ocp4-high-node | ocp4-cis-node |
ocp4-moderate | ocp4-cis |
ocp4-moderate-node | ocp4-cis-node |
ocp4-nerc-cip | ocp4-moderate |
ocp4-nerc-cip-node | ocp4-moderate-node |
5.5.1.2. 其他资源
5.5.2. Compliance Operator 扫描
建议使用 ScanSetting
和 ScanSettingBinding
API 来通过 Compliance Operator 运行合规性扫描。如需有关这些 API 对象的更多信息,请运行:
$ oc explain scansettings
或者
$ oc explain scansettingbindings
5.5.2.1. 运行合规性扫描
您可以使用互联网安全中心(CIS)配置集运行扫描。为方便起见,Compliance Operator 创建一个在启动时具有合理的默认值的 ScanSetting
对象。这个 ScanSetting
对象名为 default
。
对于 all-in-one control plane 和 worker 节点,合规性扫描在 worker 和 control plane 节点上运行两次。合规性扫描可能会导致扫描结果不一致。您可以通过在 ScanSetting
对象中只定义单个角色来避免结果不一致。
流程
运行以下命令检查
ScanSetting
对象:$ oc describe scansettings default -n openshift-compliance
输出示例
Name: default Namespace: openshift-compliance Labels: <none> Annotations: <none> API Version: compliance.openshift.io/v1alpha1 Kind: ScanSetting Metadata: Creation Timestamp: 2022-10-10T14:07:29Z Generation: 1 Managed Fields: API Version: compliance.openshift.io/v1alpha1 Fields Type: FieldsV1 fieldsV1: f:rawResultStorage: .: f:nodeSelector: .: f:node-role.kubernetes.io/master: f:pvAccessModes: f:rotation: f:size: f:tolerations: f:roles: f:scanTolerations: f:schedule: f:showNotApplicable: f:strictNodeScan: Manager: compliance-operator Operation: Update Time: 2022-10-10T14:07:29Z Resource Version: 56111 UID: c21d1d14-3472-47d7-a450-b924287aec90 Raw Result Storage: Node Selector: node-role.kubernetes.io/master: Pv Access Modes: ReadWriteOnce 1 Rotation: 3 2 Size: 1Gi 3 Tolerations: Effect: NoSchedule Key: node-role.kubernetes.io/master Operator: Exists Effect: NoExecute Key: node.kubernetes.io/not-ready Operator: Exists Toleration Seconds: 300 Effect: NoExecute Key: node.kubernetes.io/unreachable Operator: Exists Toleration Seconds: 300 Effect: NoSchedule Key: node.kubernetes.io/memory-pressure Operator: Exists Roles: master 4 worker 5 Scan Tolerations: 6 Operator: Exists Schedule: 0 1 * * * 7 Show Not Applicable: false Strict Node Scan: true Events: <none>
- 1
- Compliance Operator 创建一个包含扫描结果的持久性卷(PV)。默认情况下,PV 将使用访问模式
ReadWriteOnce
,因为 Compliance Operator 无法假定集群中配置的存储类。另外,多数集群中可以使用ReadWriteOnce
访问模式。如果需要获取扫描结果,可以使用一个 helper pod 来完成此操作,该 pod 也绑定卷。使用ReadWriteOnce
访问模式的卷只能由一个 pod 挂载,因此请记住删除帮助程序 pod。否则,Compliance Operator 将无法重复使用卷进行后续扫描。 - 2
- Compliance Operator 在卷中保留三个后续扫描的结果,旧的扫描会被轮转。
- 3
- Compliance Operator 将为扫描结果分配一个 GB 存储。
- 4 5
- 如果扫描设置使用扫描集群节点的任何配置集,请扫描这些节点角色。
- 6
- 默认扫描设置对象扫描所有节点。
- 7
- 默认扫描设置对象每天 01:00 运行扫描。
作为默认扫描设置的替代,您可以使用
default-auto-apply
,它有以下设置:Name: default-auto-apply Namespace: openshift-compliance Labels: <none> Annotations: <none> API Version: compliance.openshift.io/v1alpha1 Auto Apply Remediations: true 1 Auto Update Remediations: true 2 Kind: ScanSetting Metadata: Creation Timestamp: 2022-10-18T20:21:00Z Generation: 1 Managed Fields: API Version: compliance.openshift.io/v1alpha1 Fields Type: FieldsV1 fieldsV1: f:autoApplyRemediations: f:autoUpdateRemediations: f:rawResultStorage: .: f:nodeSelector: .: f:node-role.kubernetes.io/master: f:pvAccessModes: f:rotation: f:size: f:tolerations: f:roles: f:scanTolerations: f:schedule: f:showNotApplicable: f:strictNodeScan: Manager: compliance-operator Operation: Update Time: 2022-10-18T20:21:00Z Resource Version: 38840 UID: 8cb0967d-05e0-4d7a-ac1c-08a7f7e89e84 Raw Result Storage: Node Selector: node-role.kubernetes.io/master: Pv Access Modes: ReadWriteOnce Rotation: 3 Size: 1Gi Tolerations: Effect: NoSchedule Key: node-role.kubernetes.io/master Operator: Exists Effect: NoExecute Key: node.kubernetes.io/not-ready Operator: Exists Toleration Seconds: 300 Effect: NoExecute Key: node.kubernetes.io/unreachable Operator: Exists Toleration Seconds: 300 Effect: NoSchedule Key: node.kubernetes.io/memory-pressure Operator: Exists Roles: master worker Scan Tolerations: Operator: Exists Schedule: 0 1 * * * Show Not Applicable: false Strict Node Scan: true Events: <none>
创建一个
ScanSettingBinding
对,,它绑定到默认的ScanSetting
对象,并使用cis
和cis-node
配置集扫描集群。例如:apiVersion: compliance.openshift.io/v1alpha1 kind: ScanSettingBinding metadata: name: cis-compliance namespace: openshift-compliance profiles: - name: ocp4-cis-node kind: Profile apiGroup: compliance.openshift.io/v1alpha1 - name: ocp4-cis kind: Profile apiGroup: compliance.openshift.io/v1alpha1 settingsRef: name: default kind: ScanSetting apiGroup: compliance.openshift.io/v1alpha1
运行以下命令来创建
ScanSettingBinding
对象:$ oc create -f <file-name>.yaml -n openshift-compliance
此时,
ScanSettingBinding
对象已协调,并以Binding
和Bound
设置为基础。Compliance Operator 会创建一个ComplianceSuite
对象和关联的ComplianceScan
对象。运行以下命令跟踪合规性扫描进度:
$ oc get compliancescan -w -n openshift-compliance
扫描过程通过扫描阶段进行,最终完成后到达
DONE
阶段。在大多数情况下,扫描的结果是NON-COMPLIANT
。您可以检查扫描结果,并开始应用补救使集群兼容。如需更多信息,请参阅管理 Compliance Operator 补救。
5.5.2.2. 将结果服务器 pod 调度到 worker 节点上
结果服务器 pod 挂载存储原始资产报告格式(ARF)扫描结果的持久性卷(PV)。nodeSelector
和 tolerations
属性允许您配置结果服务器 pod 的位置。
这适用于那些不允许 control plane 节点挂载持久性卷的环境。
流程
为 Compliance Operator 创建
ScanSetting
自定义资源(CR):定义
ScanSetting
CR,并保存 YAML 文件,如rs-workers.yaml
:apiVersion: compliance.openshift.io/v1alpha1 kind: ScanSetting metadata: name: rs-on-workers namespace: openshift-compliance rawResultStorage: nodeSelector: node-role.kubernetes.io/worker: "" 1 pvAccessModes: - ReadWriteOnce rotation: 3 size: 1Gi tolerations: - operator: Exists 2 roles: - worker - master scanTolerations: - operator: Exists schedule: 0 1 * * *
要创建
ScanSetting
CR,请运行以下命令:$ oc create -f rs-workers.yaml
验证
要验证
ScanSetting
对象是否已创建,请运行以下命令:$ oc get scansettings rs-on-workers -n openshift-compliance -o yaml
输出示例
apiVersion: compliance.openshift.io/v1alpha1 kind: ScanSetting metadata: creationTimestamp: "2021-11-19T19:36:36Z" generation: 1 name: rs-on-workers namespace: openshift-compliance resourceVersion: "48305" uid: 43fdfc5f-15a7-445a-8bbc-0e4a160cd46e rawResultStorage: nodeSelector: node-role.kubernetes.io/worker: "" pvAccessModes: - ReadWriteOnce rotation: 3 size: 1Gi tolerations: - operator: Exists roles: - worker - master scanTolerations: - operator: Exists schedule: 0 1 * * * strictNodeScan: true
5.5.2.3. ScanSetting
自定义资源
ScanSetting
自定义资源现在允许您通过扫描限值属性覆盖扫描程序 Pod 的默认 CPU 和内存限值。Compliance Operator 的默认值为 500Mi 内存,100m CPU 用于扫描程序容器;对于 api-resource-collector
容器为 200Mi 内存,100m CPU。要设置 Operator 的内存限值,如果通过 OLM 或 Operator 部署本身安装,请修改 Subscription
对象。
要增加 Compliance Operator 的默认 CPU 和内存限值,请参阅增加 Compliance Operator 资源限值。
如果默认限值不足且 Operator 或扫描程序 Pod 被 Out Of Memory (OOM) 进程停止,则需要提高 Compliance Operator 或 scanner Pod 的内存限值。
5.5.2.4. 配置托管的控制平面(control plane)管理集群
如果您托管您自己的托管控制平面或 Hypershift 环境,并希望从管理集群扫描托管集群,则需要为目标托管集群设置名称和前缀命名空间。您可以通过创建一个 TailoredProfile
来达到此目的。
此流程只适用于管理自己的托管控制平面环境的用户。
托管的控制平面管理集群只支持 ocp4-cis
和 ocp4-pci-dss
配置集。
先决条件
- Compliance Operator 安装在管理集群中。
流程
运行以下命令,获取要扫描的托管集群的
名称
和命名空间
:$ oc get hostedcluster -A
输出示例
NAMESPACE NAME VERSION KUBECONFIG PROGRESS AVAILABLE PROGRESSING MESSAGE local-cluster 79136a1bdb84b3c13217 4.13.5 79136a1bdb84b3c13217-admin-kubeconfig Completed True False The hosted control plane is available
在管理集群中,创建一个
TailoredProfile
扩展扫描配置集,并定义要扫描的 Hosted Cluster 的名称和命名空间:management-tailoredprofile.yaml
示例apiVersion: compliance.openshift.io/v1alpha1 kind: TailoredProfile metadata: name: hypershift-cisk57aw88gry namespace: openshift-compliance spec: description: This profile test required rules extends: ocp4-cis 1 title: Management namespace profile setValues: - name: ocp4-hypershift-cluster rationale: This value is used for HyperShift version detection value: 79136a1bdb84b3c13217 2 - name: ocp4-hypershift-namespace-prefix rationale: This value is used for HyperShift control plane namespace detection value: local-cluster 3
创建
TailoredProfile
:$ oc create -n openshift-compliance -f mgmt-tp.yaml
5.5.2.5. 应用资源请求和限值
当 kubelet 作为 Pod 的一部分启动容器时,kubelet 会将该容器的请求和限值传递给容器运行时。在 Linux 中,容器运行时配置应用并强制实施您定义的限制的内核 cgroup。
CPU 限制定义容器可以使用的 CPU 时间。在每个调度间隔中,Linux 内核会检查是否超过这个限制。如果是这样,内核会在允许 cgroup 恢复执行前等待。
如果几个不同的容器(cgroups)希望在扩展系统上运行,则具有较大的 CPU 请求的工作负载会比具有小请求的工作负载分配更多的 CPU 时间。内存请求在 Pod 调度期间使用。在使用 cgroup v2 的节点上,容器运行时可能会使用内存请求作为提示来设置 memory.min
和 memory.low
值。
如果容器尝试分配超过这个限制的内存,Linux 内核的 out-of-memory 子系统会被激活,并通过停止容器中的一个进程来进行干预。Pod 或容器的内存限值也可以应用到由内存支持的卷的页面,如 emptyDir。
kubelet 将 tmpfs
emptyDir
视为容器使用的内存进行跟踪,而不是视为本地临时存储。如果容器超过其内存请求,且在其中运行的节点变得缺少内存,则 Pod 的容器可能会被驱除。
容器无法在超过 CPU 限制的情况下长时间运行。容器运行时不会停止 Pod 或容器超量使 CPU。要确定容器是否因为资源限值而无法调度或正在被终止,请参阅 Compliance Operator 故障排除。
5.5.2.6. 使用容器资源请求调度 Pod
创建 Pod 时,调度程序会选择要在其上运行的 Pod 的节点。每个节点都有一个最大容量,用于每种资源类型的 CPU 和它可为 Pod 提供的内存。调度程序确保调度容器的资源请求总和小于每种资源类型的节点容量。
虽然节点上的内存或 CPU 资源使用量非常低,但如果容量检查无法防止节点出现资源短缺的情况,则调度程序仍可能会拒绝在节点上放置 Pod。
对于每个容器,您可以指定以下资源限值和请求:
spec.containers[].resources.limits.cpu spec.containers[].resources.limits.memory spec.containers[].resources.limits.hugepages-<size> spec.containers[].resources.requests.cpu spec.containers[].resources.requests.memory spec.containers[].resources.requests.hugepages-<size>
虽然您只能为单个容器指定请求和限值,但考虑 Pod 的整体资源请求和限值也很有用。对于特定资源,容量资源请求和限值是 Pod 中每个容器这个类型的资源请求/限制总和。
容器资源请求和限值示例
apiVersion: v1 kind: Pod metadata: name: frontend spec: containers: - name: app image: images.my-company.example/app:v4 resources: requests: 1 memory: "64Mi" cpu: "250m" limits: 2 memory: "128Mi" cpu: "500m" - name: log-aggregator image: images.my-company.example/log-aggregator:v6 resources: requests: memory: "64Mi" cpu: "250m" limits: memory: "128Mi" cpu: "500m"
5.5.3. 定制 Compliance Operator
虽然 Compliance Operator 附带随时可用的配置集,但必须对其进行修改才能满足机构的需求和要求。修改配置集的过程称为定制。
Compliance Operator 提供了 TailoredProfile
对象来帮助定制配置集。
5.5.3.1. 创建新的定制配置集
您可以使用 TailoredProfile
对象从头开始编写一个定制的配置集。设置适当的 title
和 description
,并将 extends
字段留空。向 Compliance Operator 指明此自定义配置集生成的扫描类型:
- 节点扫描:扫描操作系统。
- 平台扫描:扫描 OpenShift Container Platform 配置。
流程
-
在
TailoredProfile
对象中设置以下注解:
new-profile.yaml
示例
apiVersion: compliance.openshift.io/v1alpha1 kind: TailoredProfile metadata: name: new-profile annotations: compliance.openshift.io/product-type: Node 1 spec: extends: ocp4-cis-node 2 description: My custom profile 3 title: Custom profile 4 enableRules: - name: ocp4-etcd-unique-ca rationale: We really need to enable this disableRules: - name: ocp4-file-groupowner-cni-conf rationale: This does not apply to the cluster
5.5.3.2. 使用定制配置集扩展现有 ProfileBundle
尽管 TailoredProfile
CR 支持最常见的定制操作,但 XCCDF 标准在定制 OpenSCAP 配置集方面具有更大的灵活性。此外,如果您的机构之前一直使用 OpenScap,则您可能有一个现有的 XCCDF 定制文件可重复使用。
ComplianceSuite
对象包含可指向自定义定制文件的可选 TailoringConfigMap
属性。TailoringConfigMap
属性的值是一个配置映射的名称,它必须包含名为 tailoring.xml
的键,这个键的值是定制内容。
流程
浏览 Red Hat Enterprise Linux CoreOS (RHCOS)
ProfileBundle
的可用规则:$ oc get rules.compliance -n openshift-compliance -l compliance.openshift.io/profile-bundle=rhcos4
浏览同一
ProfileBundle
中的可用变量:$ oc get variables.compliance -n openshift-compliance -l compliance.openshift.io/profile-bundle=rhcos4
创建名为
nist-moderate-modified
的定制配置集:选择您要添加到
nist-moderate-modified
定制配置集中的规则。这个示例通过禁用两个规则并更改一个值来扩展rhcos4-moderate
配置集。使用rationale
值描述进行这些更改的原因:new-profile-node.yaml
示例apiVersion: compliance.openshift.io/v1alpha1 kind: TailoredProfile metadata: name: nist-moderate-modified spec: extends: rhcos4-moderate description: NIST moderate profile title: My modified NIST moderate profile disableRules: - name: rhcos4-file-permissions-var-log-messages rationale: The file contains logs of error messages in the system - name: rhcos4-account-disable-post-pw-expiration rationale: No need to check this as it comes from the IdP setValues: - name: rhcos4-var-selinux-state rationale: Organizational requirements value: permissive
表 5.3. spec 变量的属性 属性 描述 extends
构建此
TailoredProfile
的Profile
对象的名称。title
TailoredProfile
的人类可读标题.disableRules
名称和理由对列表。每个名称引用要禁用的规则对象的名称。合理值是人类可读的文本,描述禁用规则的原因。
manualRules
名称和理由对列表。添加手动规则时,检查结果状态始终是
manual
,且不会生成补救。此属性是自动的,在默认情况下,设置手动规则时没有值。enableRules
名称和理由对列表。每个名称引用要启用的规则对象的名称。合理值是人类可读的文本,描述启用规则的原因。
description
描述
TailoredProfile
的人类可读文本.setValues
名称、理由和值分组列表。每个名称都引用值集的名称。理由是人类可读的文本描述该集合。值是实际设置。
添加
tailoredProfile.spec.manualRules
属性:示例
tailoredProfile.spec.manualRules.yaml
apiVersion: compliance.openshift.io/v1alpha1 kind: TailoredProfile metadata: name: ocp4-manual-scc-check spec: extends: ocp4-cis description: This profile extends ocp4-cis by forcing the SCC check to always return MANUAL title: OCP4 CIS profile with manual SCC check manualRules: - name: ocp4-scc-limit-container-allowed-capabilities rationale: We use third party software that installs its own SCC with extra privileges
创建
TailoredProfile
对象:$ oc create -n openshift-compliance -f new-profile-node.yaml 1
- 1
TailoredProfile
对象在默认的openshift-compliance
命名空间中创建。
输出示例
tailoredprofile.compliance.openshift.io/nist-moderate-modified created
定义
ScanSettingBinding
对象,将新的nist-moderate-modified
定制配置集绑定到默认的ScanSetting
对象。new-scansettingbinding.yaml
示例apiVersion: compliance.openshift.io/v1alpha1 kind: ScanSettingBinding metadata: name: nist-moderate-modified profiles: - apiGroup: compliance.openshift.io/v1alpha1 kind: Profile name: ocp4-moderate - apiGroup: compliance.openshift.io/v1alpha1 kind: TailoredProfile name: nist-moderate-modified settingsRef: apiGroup: compliance.openshift.io/v1alpha1 kind: ScanSetting name: default
创建
ScanSettingBinding
对象:$ oc create -n openshift-compliance -f new-scansettingbinding.yaml
输出示例
scansettingbinding.compliance.openshift.io/nist-moderate-modified created
5.5.4. 检索 Compliance Operator 原始结果
为 OpenShift Container Platform 集群提供合规性时,您可能需要提供扫描结果以供审核。
5.5.4.1. 从持久性卷中获取 Compliance Operator 原始结果
流程
Compliance Operator 生成原始结果并将其存储在持久性卷中。这些结果采用资产报告格式 (ARF)。
探索
ComplianceSuite
对象:$ oc get compliancesuites nist-moderate-modified \ -o json -n openshift-compliance | jq '.status.scanStatuses[].resultsStorage'
输出示例
{ "name": "ocp4-moderate", "namespace": "openshift-compliance" } { "name": "nist-moderate-modified-master", "namespace": "openshift-compliance" } { "name": "nist-moderate-modified-worker", "namespace": "openshift-compliance" }
这显示了可以访问原始结果的持久性卷声明。
使用其中一个结果的名称和命名空间来验证原始数据位置:
$ oc get pvc -n openshift-compliance rhcos4-moderate-worker
输出示例
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE rhcos4-moderate-worker Bound pvc-548f6cfe-164b-42fe-ba13-a07cfbc77f3a 1Gi RWO gp2 92m
通过生成挂载卷并复制结果的 Pod 来获取原始结果:
$ oc create -n openshift-compliance -f pod.yaml
pod.yaml 示例
apiVersion: "v1" kind: Pod metadata: name: pv-extract spec: containers: - name: pv-extract-pod image: registry.access.redhat.com/ubi8/ubi command: ["sleep", "3000"] volumeMounts: - mountPath: "/workers-scan-results" name: workers-scan-vol volumes: - name: workers-scan-vol persistentVolumeClaim: claimName: rhcos4-moderate-worker
Pod 运行后,下载结果:
$ oc cp pv-extract:/workers-scan-results -n openshift-compliance .
重要生成挂载持久性卷的 Pod 会将声明保留为
Bound
。如果使用中的卷存储类的权限设置为ReadWriteOnce
,则该卷每次只能被一个 Pod 挂载。您必须在完成后删除 Pod,否则 Operator 将无法调度 Pod 并继续在此位置存储结果。提取完成后,可以删除 Pod:
$ oc delete pod pv-extract -n openshift-compliance
5.5.5. 管理 Compliance Operator 结果和补救
每个 ComplianceCheckResult
都代表一次合规性规则检查的结果。如果该规则可自动修复,则创建一个具有相同名称的 ComplianceRemediation
对象,由 ComplianceCheckResult
拥有。除非请求,否则不会自动应用补救,这使 OpenShift Container Platform 管理员有机会审阅补救的用途,且仅在验证后应用补救。
5.5.5.1. 过滤合规性检查结果
默认情况下,ComplianceCheckResult
对象使用几个有用的标签标记,允许您查询检查,并决定生成结果后的后续步骤。
列出属于特定套件的检查:
$ oc get -n openshift-compliance compliancecheckresults \ -l compliance.openshift.io/suite=workers-compliancesuite
列出属于特定扫描的检查:
$ oc get -n openshift-compliance compliancecheckresults \ -l compliance.openshift.io/scan=workers-scan
不是所有的 ComplianceCheckResult
对象都会创建 ComplianceRemediation
对象。只有可自动修复的 ComplianceCheckResult
对象。如果 ComplianceCheckResult
对象带有 compliance.openshift.io/automated-remediation
标签,则该对象具有相关的补救。补救的名称与检查的名称相同。
列出可自动修复的所有失败检查:
$ oc get -n openshift-compliance compliancecheckresults \ -l 'compliance.openshift.io/check-status=FAIL,compliance.openshift.io/automated-remediation'
列出所有失败的检查(按严重性排序):
$ oc get compliancecheckresults -n openshift-compliance \ -l 'compliance.openshift.io/check-status=FAIL,compliance.openshift.io/check-severity=high'
输出示例
NAME STATUS SEVERITY nist-moderate-modified-master-configure-crypto-policy FAIL high nist-moderate-modified-master-coreos-pti-kernel-argument FAIL high nist-moderate-modified-master-disable-ctrlaltdel-burstaction FAIL high nist-moderate-modified-master-disable-ctrlaltdel-reboot FAIL high nist-moderate-modified-master-enable-fips-mode FAIL high nist-moderate-modified-master-no-empty-passwords FAIL high nist-moderate-modified-master-selinux-state FAIL high nist-moderate-modified-worker-configure-crypto-policy FAIL high nist-moderate-modified-worker-coreos-pti-kernel-argument FAIL high nist-moderate-modified-worker-disable-ctrlaltdel-burstaction FAIL high nist-moderate-modified-worker-disable-ctrlaltdel-reboot FAIL high nist-moderate-modified-worker-enable-fips-mode FAIL high nist-moderate-modified-worker-no-empty-passwords FAIL high nist-moderate-modified-worker-selinux-state FAIL high ocp4-moderate-configure-network-policies-namespaces FAIL high ocp4-moderate-fips-mode-enabled-on-all-nodes FAIL high
列出必须手动修复的所有失败检查:
$ oc get -n openshift-compliance compliancecheckresults \ -l 'compliance.openshift.io/check-status=FAIL,!compliance.openshift.io/automated-remediation'
手动补救步骤通常存储在 ComplianceCheckResult
对象的 description
属性中。
ComplianceCheckResult 状态 | 描述 |
---|---|
PASS | 合规检查运行完成并通过。 |
FAIL | 合规检查运行完并失败。 |
INFO | 合规检查运行完毕,并发现一些不严重的、不被视为错误的问题。 |
手动 | 合规检查没有方法自动评估成功或失败,必须手动检查。 |
INCONSISTENT | 合规检查报告来自不同来源的结果,通常是集群节点。 |
ERROR | 合规性检查运行,但无法正确完成。 |
NOT-APPLICABLE | 合规检查未运行,因为它不适用或未选中。 |
5.5.5.2. 审阅补救
审阅拥有补救的 ComplianceRemediation
对象和 ComplianceCheckResult
对象。ComplianceCheckResult
对象包含有关检查作用和试图避免的强化的人类可读描述,以及其他 metadata
,如重要性和相关的安全控制。ComplianceRemediation
对象代表可以解决 ComplianceCheckResult
中描述的问题的一种方式。第一次扫描后,检查状态为 MissingDependencies
的补救。
下面是名为 sysctl-net-ipv4-conf-all-accept-redirects
的检查和补救示例。此示例经过修订,仅显示 spec
和 status
,省略了 metadata
:
spec: apply: false current: object: apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfig spec: config: ignition: version: 3.2.0 storage: files: - path: /etc/sysctl.d/75-sysctl_net_ipv4_conf_all_accept_redirects.conf mode: 0644 contents: source: data:,net.ipv4.conf.all.accept_redirects%3D0 outdated: {} status: applicationState: NotApplied
补救有效负载存储在 spec.current
属性中。有效负载可以是任何 Kubernetes 对象,但因为此补救是通过节点扫描生成的,上例中的补救有效负载是 MachineConfig
对象。对于平台扫描,补救有效负载通常是其他类型的对象(如 ConfigMap
或 Secret
),但是否应用这种补救通常取决于管理员,否则 Compliance Operator 需要一组非常广泛的权限才能操作任何通用 Kubernetes 对象。本文稍后会提供补救平台检查的示例。
要查看应用补救时的具体操作,MachineConfig
对象内容将使用 Ignition 对象进行配置。有关格式的更多信息,请参阅 Ignition 规格。在示例中,spec.config.storage.files[0].path
属性指定由该补救创建的文件 (/etc/sysctl.d/75-sysctl_net_ipv4_conf_all_accept_redirects.conf
),spec.config.storage.files[0].contents.source
属性指定该文件的内容。
文件的内容是 URL 编码的。
使用以下 Python 脚本查看内容:
$ echo "net.ipv4.conf.all.accept_redirects%3D0" | python3 -c "import sys, urllib.parse; print(urllib.parse.unquote(''.join(sys.stdin.readlines())))"
输出示例
net.ipv4.conf.all.accept_redirects=0
Compliance Operator 不会自动解决补救之间可能出现的依赖关系问题。应用补救后,用户应执行重新扫描以确保准确的结果。
5.5.5.3. 使用自定义机器配置池时应用补救
当您创建自定义 MachineConfigPool
时,在 MachineConfigPool
中添加一个标签,以便 KubeletConfig
中的 machineConfigPoolSelector
可以与 MachineConfigPool
的标签匹配。
不要在 KubeletConfig
文件中设置 protectKernelDefaults: false
,因为 Compliance Operator 完成应用补救后,MachineConfigPool
对象可能无法意外暂停。
流程
列出节点。
$ oc get nodes -n openshift-compliance
输出示例
NAME STATUS ROLES AGE VERSION ip-10-0-128-92.us-east-2.compute.internal Ready master 5h21m v1.24.0 ip-10-0-158-32.us-east-2.compute.internal Ready worker 5h17m v1.24.0 ip-10-0-166-81.us-east-2.compute.internal Ready worker 5h17m v1.24.0 ip-10-0-171-170.us-east-2.compute.internal Ready master 5h21m v1.24.0 ip-10-0-197-35.us-east-2.compute.internal Ready master 5h22m v1.24.0
为节点添加标签。
$ oc -n openshift-compliance \ label node ip-10-0-166-81.us-east-2.compute.internal \ node-role.kubernetes.io/<machine_config_pool_name>=
输出示例
node/ip-10-0-166-81.us-east-2.compute.internal labeled
创建自定义
MachineConfigPool
CR。apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfigPool metadata: name: <machine_config_pool_name> labels: pools.operator.machineconfiguration.openshift.io/<machine_config_pool_name>: '' 1 spec: machineConfigSelector: matchExpressions: - {key: machineconfiguration.openshift.io/role, operator: In, values: [worker,<machine_config_pool_name>]} nodeSelector: matchLabels: node-role.kubernetes.io/<machine_config_pool_name>: ""
- 1
labels
字段定义要为机器配置池(MCP)添加的标签名称。
验证 MCP 是否已成功创建。
$ oc get mcp -w
5.5.5.4. 根据默认配置值评估 KubeletConfig 规则
OpenShift Container Platform 基础架构可能会在运行时包含不完整的配置文件,节点会假定缺少配置选项的默认配置值。某些配置选项可以作为命令行参数传递。因此,Compliance Operator 无法验证节点上的配置文件是否已完成,因为它可能会在规则检查中缺失选项。
要防止出现假的负结果(默认配置值通过检查,但实际应该失败),Compliance Operator 使用 Node/Proxy API 获取节点池中每个节点的配置,然后节点池中的所有配置选项都存储在代表该节点池中所有节点配置的文件中。这提高了扫描结果的准确性。
使用带有默认 master
和 worker
节点池配置的此功能不需要额外的配置更改。
5.5.5.5. 扫描自定义节点池
Compliance Operator 不会维护每个节点池配置的副本。Compliance Operator 将单一节点池中的所有节点的一致性配置选项聚合到配置文件的一个副本中。然后,Compliance Operator 使用特定节点池的配置文件来评估针对该池中的节点的规则。
流程
将
example
角色添加到要存储在ScanSettingBinding
CR 中的ScanSetting
对象中:apiVersion: compliance.openshift.io/v1alpha1 kind: ScanSetting metadata: name: default namespace: openshift-compliance rawResultStorage: rotation: 3 size: 1Gi roles: - worker - master - example scanTolerations: - effect: NoSchedule key: node-role.kubernetes.io/master operator: Exists schedule: '0 1 * * *'
创建使用
ScanSettingBinding
CR 的扫描:apiVersion: compliance.openshift.io/v1alpha1 kind: ScanSettingBinding metadata: name: cis namespace: openshift-compliance profiles: - apiGroup: compliance.openshift.io/v1alpha1 kind: Profile name: ocp4-cis - apiGroup: compliance.openshift.io/v1alpha1 kind: Profile name: ocp4-cis-node settingsRef: apiGroup: compliance.openshift.io/v1alpha1 kind: ScanSetting name: default
验证
平台 KubeletConfig 规则通过
Node/Proxy
对象检查。您可以运行以下命令来查找这些规则:$ oc get rules -o json | jq '.items[] | select(.checkType == "Platform") | select(.metadata.name | contains("ocp4-kubelet-")) | .metadata.name'
5.5.5.6. 修复 KubeletConfig
子池
KubeletConfig
补救标签可以应用到 MachineConfigPool
子池。
流程
在子池
MachineConfigPool
CR 中添加标签:$ oc label mcp <sub-pool-name> pools.operator.machineconfiguration.openshift.io/<sub-pool-name>=
5.5.5.7. 应用补救
布尔值属性 spec.apply
控制 Compliance Operator 是否应该应用补救。您可以通过将属性设置为 true
来应用补救:
$ oc -n openshift-compliance \ patch complianceremediations/<scan-name>-sysctl-net-ipv4-conf-all-accept-redirects \ --patch '{"spec":{"apply":true}}' --type=merge
在 Compliance Operator 处理应用的补救后,status.ApplicationState
属性会更改为 Applied 或在出错时更改为 Error。应用机器配置补救时,该补救与其他应用的补救一起渲染为名为 75-$scan-name-$suite-name
的 MachineConfig
对象。MachineConfig
对象随后由 Machine Config Operator 渲染,最终由在每个节点上运行的机器控制守护进程实例应用到机器配置池中的所有节点。
请注意,当 MachineConfigOperator 将新的 MachineConfig
对象应用到池中的节点时,属于池的所有节点都会重启。应用多个补救时,这可能会不方便,每个补救都会重新渲染组合 75-$scan-name-$suite-name
MachineConfig
对象。要防止立即应用补救,您可以通过将 MachineConfigPool
对象的 .spec.paused
属性设置为 true
来暂停机器配置池。
确保发生 CA 证书轮转时取消暂停池。如果 MCP 暂停,MCO 无法将新轮转的证书推送到这些节点。这会导致集群降级,并在多个 oc
命令中造成失败,包括 oc debug
、oc logs
、oc exec
和 oc attach
。如果在轮转证书时,如果 MCP 被暂停,则 OpenShift Container Platform Web 控制台的 Alerting UI 中收到警报。
Compliance Operator 可以自动应用补救。在 ScanSetting
顶层对象中设置 autoApplyRemediations: true
。
只有经过仔细考虑才能自动应用补救。
Compliance Operator 不会自动解决补救之间可能出现的依赖关系问题。应用补救后,用户应执行重新扫描以确保准确的结果。
5.5.5.8. 手动补救平台检查
检查平台扫描通常必须由管理员手动修复,原因有两个:
- 并不总是能够自动决定必须设置的值。其中一项检查要求提供允许的 registry 列表,但扫描程序并不知道组织要允许哪些 registry。
-
不同的检查会修改不同的 API 对象,需要自动补救以拥有
root
或超级用户访问权限来修改集群中的对象,但不建议这样做。
流程
以下示例使用
ocp4-ocp-allowed-registries-for-import
规则,这在默认 OpenShift Container Platform 安装中会失败。检查规则oc get rule. compliance/ocp4-ocp-allowed-registries-for-import -oyaml
,该规则通过设置allowedRegistriesForImport
属性来限制允许用户从中导入镜像的 registry,该规则的 warning 属性还会显示已检查的 API 对象,因此可以修改它并修复问题:$ oc edit image.config.openshift.io/cluster
输出示例
apiVersion: config.openshift.io/v1 kind: Image metadata: annotations: release.openshift.io/create-only: "true" creationTimestamp: "2020-09-10T10:12:54Z" generation: 2 name: cluster resourceVersion: "363096" selfLink: /apis/config.openshift.io/v1/images/cluster uid: 2dcb614e-2f8a-4a23-ba9a-8e33cd0ff77e spec: allowedRegistriesForImport: - domainName: registry.redhat.io status: externalRegistryHostnames: - default-route-openshift-image-registry.apps.user-cluster-09-10-12-07.devcluster.openshift.com internalRegistryHostname: image-registry.openshift-image-registry.svc:5000
重新运行扫描:
$ oc -n openshift-compliance \ annotate compliancescans/rhcos4-e8-worker compliance.openshift.io/rescan=
5.5.5.9. 更新补救
使用新版本的合规性内容时,可能会提供与之前版本不同的新补救版本。Compliance Operator 将保留应用的旧版本补救。OpenShift Container Platform 管理员还收到要审核和应用的新版本通知。之前应用的 ComplianceRemediation 对象已更新,它的状态已更改为 Outdated。过时的对象已标识,因此可轻松搜索。
以前应用的补救内容将存储在 ComplianceRemediation
对象的 spec.outdated
属性中,新的更新内容将存储在 spec.current
属性中。将内容更新至新版本后,管理员需要审查补救。只要 spec.outdated
属性存在,它将用来渲染生成的 MachineConfig
对象。删除 spec.outdated
属性后,Compliance Operator 会重新渲染生成的 MachineConfig
对象,导致 Operator 将配置推送到节点。
流程
搜索任何过时的补救:
$ oc -n openshift-compliance get complianceremediations \ -l complianceoperator.openshift.io/outdated-remediation=
输出示例
NAME STATE workers-scan-no-empty-passwords Outdated
当前应用的补救存储在
Outdated
属性中,未应用的新补救存储在Current
属性中。如果您对新版本满意,可删除Outdated
字段。如果要保留更新的内容,可删除Current
和Outdated
属性。应用更新的补救版本:
$ oc -n openshift-compliance patch complianceremediations workers-scan-no-empty-passwords \ --type json -p '[{"op":"remove", "path":/spec/outdated}]'
补救状态将从
Outdated
切换为Applied
:$ oc get -n openshift-compliance complianceremediations workers-scan-no-empty-passwords
输出示例
NAME STATE workers-scan-no-empty-passwords Applied
- 节点将应用更新的补救版本并重新引导。
Compliance Operator 不会自动解决补救之间可能出现的依赖关系问题。应用补救后,用户应执行重新扫描以确保准确的结果。
5.5.5.10. 取消应用补救
可能需要取消应用之前应用的补救。
流程
将
apply
标志设置为false
:$ oc -n openshift-compliance \ patch complianceremediations/rhcos4-moderate-worker-sysctl-net-ipv4-conf-all-accept-redirects \ --patch '{"spec":{"apply":false}}' --type=merge
补救状态将更改为
NotApplied
,组合MachineConfig
对象会被重新渲染,不包含补救。重要所有包含补救的受影响节点都将被重新引导。
Compliance Operator 不会自动解决补救之间可能出现的依赖关系问题。应用补救后,用户应执行重新扫描以确保准确的结果。
5.5.5.11. 删除 KubeletConfig 补救
KubeletConfig
补救包括在节点级别的配置集中。要删除 KubeletConfig 补救,您必须手动将其从 KubeletConfig
对象中删除。本例演示了如何删除 one-rule-tp-node-master-kubelet-eviction-thresholds-set-hard-imagefs-available
补救的合规性检查。
流程
找到
one-rule-tp-node-master-kubelet-eviction-thresholds-set-hard-imagefs-available
补救的scan-name
和合规检查:$ oc -n openshift-compliance get remediation \ one-rule-tp-node-master-kubelet-eviction-thresholds-set-hard-imagefs-available -o yaml
输出示例
apiVersion: compliance.openshift.io/v1alpha1 kind: ComplianceRemediation metadata: annotations: compliance.openshift.io/xccdf-value-used: var-kubelet-evictionhard-imagefs-available creationTimestamp: "2022-01-05T19:52:27Z" generation: 1 labels: compliance.openshift.io/scan-name: one-rule-tp-node-master 1 compliance.openshift.io/suite: one-rule-ssb-node name: one-rule-tp-node-master-kubelet-eviction-thresholds-set-hard-imagefs-available namespace: openshift-compliance ownerReferences: - apiVersion: compliance.openshift.io/v1alpha1 blockOwnerDeletion: true controller: true kind: ComplianceCheckResult name: one-rule-tp-node-master-kubelet-eviction-thresholds-set-hard-imagefs-available uid: fe8e1577-9060-4c59-95b2-3e2c51709adc resourceVersion: "84820" uid: 5339d21a-24d7-40cb-84d2-7a2ebb015355 spec: apply: true current: object: apiVersion: machineconfiguration.openshift.io/v1 kind: KubeletConfig spec: kubeletConfig: evictionHard: imagefs.available: 10% 2 outdated: {} type: Configuration status: applicationState: Applied
注意如果补救调用
evictionHard
kubelet 配置,您必须指定所有evictionHard
参数:memory.available
、nodefs.available
、nodefs.inodesFree
、imagefs.available
和imagefs.inodesFree
。如果没有指定所有参数,则只应用指定的参数,补救无法正常工作。删除补救:
为补救对象将
apply
设置为 false:$ oc -n openshift-compliance patch \ complianceremediations/one-rule-tp-node-master-kubelet-eviction-thresholds-set-hard-imagefs-available \ -p '{"spec":{"apply":false}}' --type=merge
使用
scan-name
,找到补救应用到的KubeletConfig
对象:$ oc -n openshift-compliance get kubeletconfig \ --selector compliance.openshift.io/scan-name=one-rule-tp-node-master
输出示例
NAME AGE compliance-operator-kubelet-master 2m34s
从
KubeletConfig
对象手动删除补救imagefs.available: 10%
:$ oc edit -n openshift-compliance KubeletConfig compliance-operator-kubelet-master
重要所有包含补救的受影响节点都将被重新引导。
您还必须在定制的配置集中排除任何调度的扫描规则,这些配置集自动应用补救,否则会在下一次调度的扫描过程中重新应用补救。
5.5.5.12. Inconsistent ComplianceScan
ScanSetting
对象列出了合规性扫描从 ScanSetting
或 ScanSettingBinding
对象扫描的节点角色。每个节点角色通常映射到机器配置池。
机器配置池中的所有机器都应该相同,池中节点的所有扫描结果都应该相同。
如果某些结果与其他结果不同,Compliance Operator 将标记一些节点将报告为 INCONSISTENT
的 ComplianceCheckResult
对象。所有 ComplianceCheckResult
对象也都标有 compliance.openshift.io/inconsistent-check
。
因为池中的机器数量可能非常大,所以 Compliance Operator 会尝试找到最常用的状态,并列出与常见状态不同的节点。最常见的状态存储在 compliance.openshift.io/most-common-status
注解中,注解 compliance.openshift.io/inconsistent-source
包含与最常见状态不同的 hostname:status
检查状态对。如果没有找到常见状态,则所有 hostname:status
对都列在 compliance.openshift.io/inconsistent-source annotation
中。
如果可能,仍会创建补救,以便集群可以整合到兼容状态。但是,并非总是能够创建补救,必须手动纠正节点之间的差异。必须使用 compliance.openshift.io/rescan=
选项为扫描添加注解来重新运行合规性扫描,以得到一致的结果:
$ oc -n openshift-compliance \ annotate compliancescans/rhcos4-e8-worker compliance.openshift.io/rescan=
5.5.5.13. 其他资源
- 修改节点。
5.5.6. 执行高级 Compliance Operator 任务
Compliance Operator 包含适用于高级用户的选项,用于调试或与现有工具集成。
5.5.6.1. 直接使用 ComplianceSuite 和 ComplianceScan 对象
虽然建议用户利用 ScanSetting
和 ScanSettingBinding
对象来定义套件和扫描,但也有直接定义 ComplianceSuite
对象的有效用例:
-
仅指定单个规则进行扫描。这可与
debug: true
属性一起用于调试,提高 OpenSCAP 扫描程序的详细程度,否则调试模式会变得非常冗长。将测试限制为一条规则有助于减少调试信息的数量。 - 提供自定义 nodeSelector。要使补救适用,nodeSelector 必须与一个池匹配。
- 使用定制文件将 Scan 指向定制配置映射。
- 不需要从捆绑包解析配置集的消耗成本时用于测试或开发。
以下示例显示仅使用一条规则扫描 worker 机器的 ComplianceSuite
:
apiVersion: compliance.openshift.io/v1alpha1 kind: ComplianceSuite metadata: name: workers-compliancesuite spec: scans: - name: workers-scan profile: xccdf_org.ssgproject.content_profile_moderate content: ssg-rhcos4-ds.xml contentImage: registry.redhat.io/compliance/openshift-compliance-content-rhel8@sha256:45dc... debug: true rule: xccdf_org.ssgproject.content_rule_no_direct_root_logins nodeSelector: node-role.kubernetes.io/worker: ""
上面提到的 ComplianceSuite
对象和 ComplianceScan
对象以 OpenSCAP 期望的格式指定多个属性。
要找到配置集、内容或规则值,您可以先从 ScanSetting
和 ScanSettingBinding
创建类似的 Suite 或检查从 ProfileBundle
对象中解析的对象,如规则或配置集。这些对象包含可以从 ComplianceSuite
中引用它们的 xccdf_org
标识符。
5.5.6.2. 为 ScanSetting
扫描设置 PriorityClass
在大规模环境中,默认的 PriorityClass
对象可能太低,以保证 Pod 在其上执行扫描。对于必须保持合规或保证自动扫描的集群,建议设置 PriorityClass
变量,以确保 Compliance Operator 始终在资源约束的情况下赋予优先级。
流程
设置
PriorityClass
变量:apiVersion: compliance.openshift.io/v1alpha1 strictNodeScan: true metadata: name: default namespace: openshift-compliance priorityClass: compliance-high-priority 1 kind: ScanSetting showNotApplicable: false rawResultStorage: nodeSelector: node-role.kubernetes.io/master: '' pvAccessModes: - ReadWriteOnce rotation: 3 size: 1Gi tolerations: - effect: NoSchedule key: node-role.kubernetes.io/master operator: Exists - effect: NoExecute key: node.kubernetes.io/not-ready operator: Exists tolerationSeconds: 300 - effect: NoExecute key: node.kubernetes.io/unreachable operator: Exists tolerationSeconds: 300 - effect: NoSchedule key: node.kubernetes.io/memory-pressure operator: Exists schedule: 0 1 * * * roles: - master - worker scanTolerations: - operator: Exists
- 1
- 如果无法找到
ScanSetting
中引用的PriorityClass
,Operator 会将PriorityClass
留空,发出警告,并在没有PriorityClass
的情况下继续调度扫描。
5.5.6.3. 使用原始定制配置集
尽管 TailoredProfile
CR 支持最常见的定制操作,但 XCCDF 标准在定制 OpenSCAP 配置集方面具有更大的灵活性。此外,如果您的机构之前一直使用 OpenScap,则您可能有一个现有的 XCCDF 定制文件可重复使用。
ComplianceSuite
对象包含可指向自定义定制文件的可选 TailoringConfigMap
属性。TailoringConfigMap
属性的值是一个配置映射的名称,它必须包含名为 tailoring.xml
的键,这个键的值是定制内容。
流程
从一个文件创建
ConfigMap
对象:$ oc -n openshift-compliance \ create configmap nist-moderate-modified \ --from-file=tailoring.xml=/path/to/the/tailoringFile.xml
在属于 Suite 的 Scan 中引用定制文件:
apiVersion: compliance.openshift.io/v1alpha1 kind: ComplianceSuite metadata: name: workers-compliancesuite spec: debug: true scans: - name: workers-scan profile: xccdf_org.ssgproject.content_profile_moderate content: ssg-rhcos4-ds.xml contentImage: registry.redhat.io/compliance/openshift-compliance-content-rhel8@sha256:45dc... debug: true tailoringConfigMap: name: nist-moderate-modified nodeSelector: node-role.kubernetes.io/worker: ""
5.5.6.4. 执行重新扫描
通常,您希望按指定时间表重新运行扫描,如每周一或每天。在修复节点上的问题后,重新运行一次扫描也很有用。要执行单次扫描,可使用 compliance.openshift.io/rescan=
选项注解扫描:
$ oc -n openshift-compliance \ annotate compliancescans/rhcos4-e8-worker compliance.openshift.io/rescan=
一个重新扫描会为 rhcos-moderate
配置集生成四个额外的 mc
:
$ oc get mc
输出示例
75-worker-scan-chronyd-or-ntpd-specify-remote-server 75-worker-scan-configure-usbguard-auditbackend 75-worker-scan-service-usbguard-enabled 75-worker-scan-usbguard-allow-hid-and-hub
应用扫描设置 default-auto-apply
标签时,补救会自动应用并过时的补救更新。如果存在由于依赖项或已经过时的补救没有被应用的补救,重新扫描会应用补救,并可能会触发重启。只有使用 MachineConfig
对象触发器重启的补救。如果没有要应用的更新或依赖项,则不会重启。
5.5.6.5. 为结果设置自定义存储大小
虽然 ComplianceCheckResult
等自定义资源表示一次检查跨所有扫描节点的聚合结果,但审阅扫描程序生成的原始结果会很有用。原始结果以 ARF 格式生成,可能较大(每个节点几十兆字节),将其存储在由 etcd
键-值存储支持的 Kubernetes 资源中是不切实际的。相反,每次扫描都会创建一个默认为 1GB 大小的 PV。根据您的环境,您可能想要相应地增大 PV 大小。这可以使用在 ScanSetting
和 ComplianceScan
资源中公开的 rawResultStorage.size
属性完成。
相关的参数是 rawResultStorage.rotation
,它控制在旧的扫描被轮转前 PV 中保留的扫描次数。默认值为 3,将轮转策略设置为 0 可禁用轮转。根据默认轮转策略和每个原始 ARF 扫描报告 100MB 的估计大小,您可以计算出环境的正确 PV 大小。
5.5.6.5.1. 使用自定义结果存储值
由于 OpenShift Container Platform 可以在各种公有云或裸机中部署,因此 Compliance Operator 无法决定可用的存储配置。默认情况下,Compliance Operator 会尝试使用集群的默认存储类创建 PV 来存储结果,但可以使用 rawResultStorage.StorageClassName
属性配置自定义存储类。
如果您的集群没有指定默认存储类,则必须设置此属性。
将 ScanSetting
自定义资源配置为使用标准存储类,并创建大小为 10GB 的持久性卷,并保留最后 10 个结果:
ScanSetting
CR 示例
apiVersion: compliance.openshift.io/v1alpha1 kind: ScanSetting metadata: name: default namespace: openshift-compliance rawResultStorage: storageClassName: standard rotation: 10 size: 10Gi roles: - worker - master scanTolerations: - effect: NoSchedule key: node-role.kubernetes.io/master operator: Exists schedule: '0 1 * * *'
5.5.6.6. 应用套件扫描生成的补救
虽然您可以使用 ComplianceSuite
对象中的 autoApplyRemediations
布尔值参数但您可以使用 compliance.openshift.io/apply-remediations
为对象添加注解。这允许 Operator 应用所有创建的补救。
流程
-
运行以下命令应用
compliance.openshift.io/apply-remediations
注解:
$ oc -n openshift-compliance \ annotate compliancesuites/workers-compliancesuite compliance.openshift.io/apply-remediations=
5.5.6.7. 自动更新补救
在某些情况下带有较新内容的扫描可能会将补救标记为 OUTDATED
。作为管理员您可以应用 compliance.openshift.io/remove-outdated
注解来应用新的补救并删除过时的补救。
流程
-
应用
compliance.openshift.io/remove-outdated
注解:
$ oc -n openshift-compliance \ annotate compliancesuites/workers-compliancesuite compliance.openshift.io/remove-outdated=
或者在 ScanSetting
或 ComplianceSuite
对象中设置 autoUpdateRemediations 标志
以自动更新补救。
5.5.6.8. 为 Compliance Operator 创建自定义 SCC
在一些环境中,您必须创建一个自定义安全性上下文约束(SCC)文件,以确保 Compliance Operator api-resource-collector
使用正确的权限。
先决条件
-
您必须具有
admin
权限。
流程
在名为
restricted-adjusted-compliance.yaml
的 YAML 文件中定义 SCC:SecurityContextConstraints
对象定义allowHostDirVolumePlugin: false allowHostIPC: false allowHostNetwork: false allowHostPID: false allowHostPorts: false allowPrivilegeEscalation: true allowPrivilegedContainer: false allowedCapabilities: null apiVersion: security.openshift.io/v1 defaultAddCapabilities: null fsGroup: type: MustRunAs kind: SecurityContextConstraints metadata: name: restricted-adjusted-compliance priority: 30 1 readOnlyRootFilesystem: false requiredDropCapabilities: - KILL - SETUID - SETGID - MKNOD runAsUser: type: MustRunAsRange seLinuxContext: type: MustRunAs supplementalGroups: type: RunAsAny users: - system:serviceaccount:openshift-compliance:api-resource-collector 2 volumes: - configMap - downwardAPI - emptyDir - persistentVolumeClaim - projected - secret
创建 SCC:
$ oc create -n openshift-compliance -f restricted-adjusted-compliance.yaml
输出示例
securitycontextconstraints.security.openshift.io/restricted-adjusted-compliance created
验证
验证是否已创建 SCC:
$ oc get -n openshift-compliance scc restricted-adjusted-compliance
输出示例
NAME PRIV CAPS SELINUX RUNASUSER FSGROUP SUPGROUP PRIORITY READONLYROOTFS VOLUMES restricted-adjusted-compliance false <no value> MustRunAs MustRunAsRange MustRunAs RunAsAny 30 false ["configMap","downwardAPI","emptyDir","persistentVolumeClaim","projected","secret"]
5.5.6.9. 其他资源
5.5.7. 对 Compliance Operator 进行故障排除
本节介绍如何对 Compliance Operator 进行故障排除。该信息可用于诊断问题或在错误报告中提供信息。一些常规提示:
出现重大事件时,Compliance Operator 会发出 Kubernetes 事件。您可以使用以下命令查看集群中的所有事件:
$ oc get events -n openshift-compliance
或者使用以下命令查看 Scan 等对象的事件:
$ oc describe -n openshift-compliance compliancescan/cis-compliance
Compliance Operator 由多个控制器组成,大约每个 API 对象一个。仅过滤对应于有问题的 API 对象的控制器很有用。如果无法应用
ComplianceRemediation
,请查看remediationctrl
控制器中的信息。可以通过使用jq
进行解析来过滤单个控制器中的信息:$ oc -n openshift-compliance logs compliance-operator-775d7bddbd-gj58f \ | jq -c 'select(.logger == "profilebundlectrl")'
在 UTC 中,自 UNIX 时间戳以来的时间戳以秒为单位记录。要将其转换为人类可读的日期,请使用
date -d @timestamp --utc
,例如:$ date -d @1596184628.955853 --utc
-
很多自定义资源允许设置
debug
选项,最重要的是ComplianceSuite
和ScanSetting
。启用此选项会增加 OpenSCAP 扫描程序 Pod 以及其他一些帮助程序 Pod 的详细程度。 -
如果单个规则意外传递或失败,则仅使用该规则运行单次扫描或 suite 从相应的
ComplianceCheckResult
对象中查找规则 ID 并将其用作Scan
CR 中的rule
属性值会很有帮助。然后再启用debug
选项,扫描程序 Pod 中的scanner
容器日志会显示原始 OpenSCAP 日志。
5.5.7.1. 扫描剖析
以下各节概述了 Compliance Operator 扫描的组件和阶段。
5.5.7.1.1. 合规性源
合规性内容存储在从 ProfileBundle
对象生成的 Profile
对象中。Compliance Operator 为集群创建一个 ProfileBundle
对象,并为集群节点创建另一个对象。
$ oc get -n openshift-compliance profilebundle.compliance
$ oc get -n openshift-compliance profile.compliance
ProfileBundle
对象由带有 Bundle
名称标签的部署处理。要使用 Bundle
排除问题,可以查找部署并查看部署中的 Pod 日志:
$ oc logs -n openshift-compliance -lprofile-bundle=ocp4 -c profileparser
$ oc get -n openshift-compliance deployments,pods -lprofile-bundle=ocp4
$ oc logs -n openshift-compliance pods/<pod-name>
$ oc describe -n openshift-compliance pod/<pod-name> -c profileparser
5.5.7.1.2. ScanSetting 和 ScanSettingBinding 对象生命周期和调试
通过有效的合规性内容源,可以使用高级 ScanSetting
和 ScanSettingBinding
对象来生成 ComplianceSuite
和 ComplianceScan
对象:
apiVersion: compliance.openshift.io/v1alpha1 kind: ScanSetting metadata: name: my-companys-constraints debug: true # For each role, a separate scan will be created pointing # to a node-role specified in roles roles: - worker --- apiVersion: compliance.openshift.io/v1alpha1 kind: ScanSettingBinding metadata: name: my-companys-compliance-requirements profiles: # Node checks - name: rhcos4-e8 kind: Profile apiGroup: compliance.openshift.io/v1alpha1 # Cluster checks - name: ocp4-e8 kind: Profile apiGroup: compliance.openshift.io/v1alpha1 settingsRef: name: my-companys-constraints kind: ScanSetting apiGroup: compliance.openshift.io/v1alpha1
ScanSetting
和 ScanSettingBinding
对象均由标记为 logger=scansettingbindingctrl
的同一控制器处理。这些对象没有状态。任何问题都以事件的形式传递:
Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal SuiteCreated 9m52s scansettingbindingctrl ComplianceSuite openshift-compliance/my-companys-compliance-requirements created
现在创建一个 ComplianceSuite
对象。流继续协调新创建的 ComplianceSuite
。
5.5.7.1.3. ComplianceSuite 自定义资源生命周期和调试
ComplianceSuite
CR 是一个围绕 ComplianceScan
CR 的 wrapper。ComplianceSuite
CR 由标记为 logger=suitectrl
的控制器处理。该控制器处理从 Suite 创建 Scan 的过程,将单个扫描状态协调并整合为一个 Suite 状态。如果将 Suite 设置为定期执行,suitectrl
也会处理创建 CronJob
CR 的事件,该 CR 在初始运行完成后会在 Suite 中重新运行 Scan:
$ oc get cronjobs
输出示例
NAME SCHEDULE SUSPEND ACTIVE LAST SCHEDULE AGE <cron_name> 0 1 * * * False 0 <none> 151m
对于最重要的问题,会发出事件。使用 oc describe compliancesuites/<name>
查看它们。Suite
对象还有一个 Status
子资源,当属于这个 Suite
的任何 Scan
对象更新其 Status 子资源时,这个子资源会更新。创建所有预期扫描后,控制会被传递给扫描控制器。
5.5.7.1.4. ComplianceScan 自定义资源生命周期和调试
ComplianceScan
CR 由 scanctrl
控制器处理。这也是进行实际扫描以及创建扫描结果的地方。每次扫描都经过几个阶段:
5.5.7.1.4.1. 待处理阶段
在此阶段验证扫描是否正确。如果存储大小等参数无效,则扫描会转换为 DONE,并包含 ERROR 结果,否则进入启动阶段。
5.5.7.1.4.2. 启动阶段
在此阶段,一些配置映射包含扫描程序 Pod 的环境或直接包含扫描程序 Pod 要评估的脚本。列出配置映射:
$ oc -n openshift-compliance get cm \ -l compliance.openshift.io/scan-name=rhcos4-e8-worker,complianceoperator.openshift.io/scan-script=
扫描程序 pod 将使用这些配置映射。如果您需要修改扫描程序行为,更改扫描程序调试级别或打印原始结果,修改配置映射是一种好方法。随后,每次扫描都会创建一个持久性卷声明,以存储原始 ARF 结果:
$ oc get pvc -n openshift-compliance -lcompliance.openshift.io/scan-name=rhcos4-e8-worker
PVC 由每次扫描进行的 ResultServer
部署挂载。ResultServer
是一个简单的 HTTP 服务器,单个扫描程序 Pod 会将完整 ARF 结果上传到其中。每个服务器都可以在不同节点中运行。完整 ARF 结果可能非常大,您不能假定可以创建同时从多个节点挂载的卷。扫描完成后,ResultServer
部署会缩减。包含原始结果的 PVC 可从另一个自定义 Pod 挂载,并可获取或检查结果。扫描程序 Pod 和 ResultServer
之间的流量受 mutual TLS 协议保护。
最后,扫描程序 Pod 在此阶段启动;一个扫描程序 Pod 用于一个 Platform
扫描实例,每个匹配节点的一个扫描程序 Pod 用于一个 node
扫描实例。每节点 Pod 使用节点名称标识。每个 Pod 始终使用 ComplianceScan
名称标识:
$ oc get pods -lcompliance.openshift.io/scan-name=rhcos4-e8-worker,workload=scanner --show-labels
输出示例
NAME READY STATUS RESTARTS AGE LABELS rhcos4-e8-worker-ip-10-0-169-90.eu-north-1.compute.internal-pod 0/2 Completed 0 39m compliance.openshift.io/scan-name=rhcos4-e8-worker,targetNode=ip-10-0-169-90.eu-north-1.compute.internal,workload=scanner
+ 扫描然后进入 Running 阶段。
5.5.7.1.4.3. 运行阶段
运行阶段会等待扫描程序 Pod 完成。运行阶段使用以下术语和进程:
-
init 容器:有一个名为
content-container
的 init 容器。它运行 contentImage 容器,并执行单个命令,该命令将 contentFile 复制到与这个 Pod 中其他容器共享的/content
目录中。 -
scanner:此容器运行扫描。对于节点扫描,该容器将节点文件系统作为
/host
挂载,并挂载 init 容器交付的内容。该容器还挂载启动阶段创建的entrypoint
ConfigMap
并执行它。入口点ConfigMap
中的默认脚本执行 OpenSCAP,并将结果文件存储在 Pod 容器之间共享的/results
目录中。可查看此 Pod 中的日志以确定 OpenSCAP 扫描程序检查了哪些内容。可使用debug
标记查看更详细的输出。 logcollector:logcollector 容器会等待扫描程序容器完成。然后,它会将完整的 ARF 结果上传到
ResultServer
,并以ConfigMap
的形式单独上传 XCCDF 结果以及扫描结果和 OpenSCAP 结果代码。这些结果配置映射使用扫描名称 (compliance.openshift.io/scan-name=rhcos4-e8-worker
) 进行标记:$ oc describe cm/rhcos4-e8-worker-ip-10-0-169-90.eu-north-1.compute.internal-pod
输出示例
Name: rhcos4-e8-worker-ip-10-0-169-90.eu-north-1.compute.internal-pod Namespace: openshift-compliance Labels: compliance.openshift.io/scan-name-scan=rhcos4-e8-worker complianceoperator.openshift.io/scan-result= Annotations: compliance-remediations/processed: compliance.openshift.io/scan-error-msg: compliance.openshift.io/scan-result: NON-COMPLIANT OpenSCAP-scan-result/node: ip-10-0-169-90.eu-north-1.compute.internal Data ==== exit-code: ---- 2 results: ---- <?xml version="1.0" encoding="UTF-8"?> ...
用于 Platform
扫描的扫描程序 Pod 类似,以下情况除外:
-
名为
api-resource-collector
的一个额外 init 容器读取由 content-container init 容器提供的 OpenSCAP 内容,确定内容需要检查的 API 资源,并将这些 API 资源存储到scanner
容器将从中读取它们的共享目录中。 -
scanner
容器不需要挂载主机文件系统。
扫描程序 Pod 完成后,扫描将进入聚合阶段。
5.5.7.1.4.4. 聚合阶段
在聚合阶段,扫描控制器会生成另一个名为聚合器 Pod 的 Pod。它的目的是获取生成的 ConfigMap
对象,读取结果,并为每个检查结果创建对应的 Kubernete 对象。如果可自动补救检查失败,将创建一个 ComplianceRemediation
对象。为了提供人类可读的检查和补救元数据,聚合器 Pod 也会使用 init 容器挂载 OpenSCAP 内容。
当一个配置映射由聚合器 Pod 处理时,会使用 compliance-remediations/processed
标签进行标识。这个阶段会生成 ComplianceCheckResult
对象:
$ oc get compliancecheckresults -lcompliance.openshift.io/scan-name=rhcos4-e8-worker
输出示例
NAME STATUS SEVERITY rhcos4-e8-worker-accounts-no-uid-except-zero PASS high rhcos4-e8-worker-audit-rules-dac-modification-chmod FAIL medium
和 ComplianceRemediation
对象:
$ oc get complianceremediations -lcompliance.openshift.io/scan-name=rhcos4-e8-worker
输出示例
NAME STATE rhcos4-e8-worker-audit-rules-dac-modification-chmod NotApplied rhcos4-e8-worker-audit-rules-dac-modification-chown NotApplied rhcos4-e8-worker-audit-rules-execution-chcon NotApplied rhcos4-e8-worker-audit-rules-execution-restorecon NotApplied rhcos4-e8-worker-audit-rules-execution-semanage NotApplied rhcos4-e8-worker-audit-rules-execution-setfiles NotApplied
创建这些 CR 后,聚合器 Pod 将退出,扫描进入完成阶段。
5.5.7.1.4.5. 完成阶段
在最后的扫描阶段,会根据需要清理扫描资源,如果扫描是一次性的,ResultServer
部署会被缩减,如果扫描是连续性的,会被删除;下一个扫描实例将重新创建部署。
也可以在完成阶段通过注解来触发扫描重新运行:
$ oc -n openshift-compliance \ annotate compliancescans/rhcos4-e8-worker compliance.openshift.io/rescan=
扫描到达完成阶段后,除非将补救设置为使用 autoApplyRemediations: true
自动应用,否则不会自动执行任何其他操作。OpenShift Container Platform 管理员现在将审阅补救并根据需要应用它们。如果将补救设置为自动应用,ComplianceSuite
控制器会在完成阶段接管,暂停扫描映射到的机器配置池,并一次性应用所有补救。如果应用了补救,ComplianceRemediation
控制器将接管。
5.5.7.1.5. ComplianceRemediation 控制器生命周期和调试
示例扫描报告了一些结果。通过将 apply
属性切换为 true
可启用其中一个补救:
$ oc patch complianceremediations/rhcos4-e8-worker-audit-rules-dac-modification-chmod --patch '{"spec":{"apply":true}}' --type=merge
ComplianceRemediation
控制器 (logger=remediationctrl
) 协调修改后的对象。协调的结果是会更改已协调补救对象的状态,也会更改包含所有已应用补救的已渲染的每套件 MachineConfig
对象。
MachineConfig
对象始终以 75-
开头,并以扫描和套件命名:
$ oc get mc | grep 75-
输出示例
75-rhcos4-e8-worker-my-companys-compliance-requirements 3.2.0 2m46s
当前包含 mc
的补救列在机器配置的注解中:
$ oc describe mc/75-rhcos4-e8-worker-my-companys-compliance-requirements
输出示例
Name: 75-rhcos4-e8-worker-my-companys-compliance-requirements Labels: machineconfiguration.openshift.io/role=worker Annotations: remediation/rhcos4-e8-worker-audit-rules-dac-modification-chmod:
ComplianceRemediation
控制器的算法如下:
- 所有当前应用的补救都读取到初始补救集合中。
- 如果要应用协调后的补救,会将其添加到该集合中。
-
MachineConfig
对象从集合中渲染,并使用集合中的补救名称进行注解。如果集合为空(未应用最后一个补救),将删除渲染的MachineConfig
对象。 - 只有渲染的机器配置与集群中已应用的 MC 不同时,才会更新(或创建,或删除)应用的 MC。
-
创建或修改
MachineConfig
对象会触发与machineconfiguration.openshift.io/role
标签匹配的节点重新引导 - 请参阅 MachineConfig Operator 文档以了解更多详细信息。
根据需要更新渲染的机器配置并更新协调的补救对象状态后,补救循环即告终止。在本例中,应用补救会触发重新引导。重新引导后,注解扫描以重新运行它:
$ oc -n openshift-compliance \ annotate compliancescans/rhcos4-e8-worker compliance.openshift.io/rescan=
扫描将运行并完成。检查补救是否通过:
$ oc -n openshift-compliance \ get compliancecheckresults/rhcos4-e8-worker-audit-rules-dac-modification-chmod
输出示例
NAME STATUS SEVERITY rhcos4-e8-worker-audit-rules-dac-modification-chmod PASS medium
5.5.7.1.6. 有用的标签
Compliance Operator 生成的每个 pod 都专门使用其所属的扫描及其工作来标识。扫描标识符使用 compliance.openshift.io/scan-name
标签进行标识。工作负载标识符使用 workload
标签进行标识。
Compliance Operator 调度以下工作负载:
- scanner:执行合规性扫描。
- resultserver:存储合规性扫描的原始结果。
- aggregator:汇总结果,检测不一致和输出结果对象(检查结果和补救)。
- suitererunner:将标记一个要重新运行的套件(设定时间表时)。
- profileparser:解析数据流并创建适当的配置集、规则和变量。
需要对某个工作负载进行调试和记录日志时,请运行:
$ oc logs -l workload=<workload_name> -c <container_name>
5.5.7.2. 增加 Compliance Operator 资源限值
在某些情况下,Compliance Operator 可能需要的内存超过默认限制允许的数量。缓解此问题的最佳方法是设置自定义资源限制。
要增加扫描程序 Pod 的默认内存和 CPU 限值,请参阅 'ScanSetting' 自定义资源。
流程
要将 Operator 的内存限值增加到 500 Mi,请创建名为
co-memlimit-patch.yaml
的以下补丁文件:spec: config: resources: limits: memory: 500Mi
应用补丁文件:
$ oc patch sub compliance-operator -nopenshift-compliance --patch-file co-memlimit-patch.yaml --type=merge
5.5.7.3. 配置 Operator 资源限制
resources
字段为 Operator Lifecycle Manager (OLM) 创建的 Pod 中所有容器定义资源约束。
此流程中应用的资源约束会覆盖现有的资源限制。
流程
通过编辑
Subscription
对象,注入 0.25 cpu 和 64 Mi 内存的请求,以及每个容器 0.5 cpu 和 128 Mi 内存:kind: Subscription metadata: name: custom-operator spec: package: etcd channel: alpha config: resources: requests: memory: "64Mi" cpu: "250m" limits: memory: "128Mi" cpu: "500m"
5.5.7.4. 配置 ScanSetting 超时
ScanSetting
对象有一个 timeout 选项,可在 ComplianceScanSetting
对象中指定一个持续时间字符串,如 1h30m
。如果扫描没有在指定的超时时间内完成,则扫描会重新尝试,直到达到 maxRetryOnTimeout
限制为止。
流程
要在 ScanSetting 中设置
timeout
和maxRetryOnTimeout
,请修改现有ScanSetting
对象:apiVersion: compliance.openshift.io/v1alpha1 kind: ScanSetting metadata: name: default namespace: openshift-compliance rawResultStorage: rotation: 3 size: 1Gi roles: - worker - master scanTolerations: - effect: NoSchedule key: node-role.kubernetes.io/master operator: Exists schedule: '0 1 * * *' timeout: '10m0s' 1 maxRetryOnTimeout: 3 2
5.5.7.5. 获取支持
如果您在执行本文档所述的某个流程或 OpenShift Container Platform 时遇到问题,请访问 红帽客户门户网站。通过红帽客户门户网站:
- 搜索或者浏览红帽知识库,了解与红帽产品相关的文章和解决方案。
- 提交问题单给红帽支持。
- 访问其他产品文档。
要识别集群中的问题,您可以在 OpenShift Cluster Manager Hybrid Cloud Console 中使用 Insights。Insights 提供了问题的详细信息,并在有可用的情况下,提供了如何解决问题的信息。
如果您对本文档有任何改进建议,或发现了任何错误,请为相关文档组件提交 JIRA 问题。请提供具体详情,如章节名称和 OpenShift Container Platform 版本。
5.5.8. 使用 oc-compliance 插件
虽然 Compliance Operator 为集群自动执行许多检查和补救,但将集群设置为合规的完整过程通常需要管理员与 Compliance Operator API 和其他组件交互。oc-compliance
插件使进程变得更加容易。
5.5.8.1. 安装 oc-compliance 插件
流程
提取
oc-compliance
镜像以获取oc-compliance
二进制文件:$ podman run --rm -v ~/.local/bin:/mnt/out:Z registry.redhat.io/compliance/oc-compliance-rhel8:stable /bin/cp /usr/bin/oc-compliance /mnt/out/
输出示例
W0611 20:35:46.486903 11354 manifest.go:440] Chose linux/amd64 manifest from the manifest list.
现在,您可以运行
oc-compliance
。
5.5.8.2. 获取原始结果
当合规性扫描完成后,生成的 ComplianceCheckResult
自定义资源(CR)中会列出单个检查的结果。但是,管理员或审核员可能需要扫描的完整详情。OpenSCAP 工具创建带有详细结果的高级记录格式(ARF)格式的文件。这个 ARF 文件太大,无法存储在配置映射或其他标准 Kubernetes 资源中,因此会创建一个持久性卷(PV)来包含它。
流程
使用 Compliance Operator 从 PV 获取结果是一个包括四步的过程。但是,在
oc-compliance
插件中,您可以使用单个命令:$ oc compliance fetch-raw <object-type> <object-name> -o <output-path>
-
<object-type>
可以是scansettingbinding
、compliancescan
或compliancesuite
,具体取决于扫描通过哪个对象启动。 <object-name>
是用于收集 ARF 文件的绑定、套件或扫描对象的名称,<output-path>
是放置结果的本地目录。例如:
$ oc compliance fetch-raw scansettingbindings my-binding -o /tmp/
输出示例
Fetching results for my-binding scans: ocp4-cis, ocp4-cis-node-worker, ocp4-cis-node-master Fetching raw compliance results for scan 'ocp4-cis'....... The raw compliance results are available in the following directory: /tmp/ocp4-cis Fetching raw compliance results for scan 'ocp4-cis-node-worker'........... The raw compliance results are available in the following directory: /tmp/ocp4-cis-node-worker Fetching raw compliance results for scan 'ocp4-cis-node-master'...... The raw compliance results are available in the following directory: /tmp/ocp4-cis-node-master
查看目录中的文件列表:
$ ls /tmp/ocp4-cis-node-master/
输出示例
ocp4-cis-node-master-ip-10-0-128-89.ec2.internal-pod.xml.bzip2 ocp4-cis-node-master-ip-10-0-150-5.ec2.internal-pod.xml.bzip2 ocp4-cis-node-master-ip-10-0-163-32.ec2.internal-pod.xml.bzip2
提取结果:
$ bunzip2 -c resultsdir/worker-scan/worker-scan-stage-459-tqkg7-compute-0-pod.xml.bzip2 > resultsdir/worker-scan/worker-scan-ip-10-0-170-231.us-east-2.compute.internal-pod.xml
查看结果:
$ ls resultsdir/worker-scan/
输出示例
worker-scan-ip-10-0-170-231.us-east-2.compute.internal-pod.xml worker-scan-stage-459-tqkg7-compute-0-pod.xml.bzip2 worker-scan-stage-459-tqkg7-compute-1-pod.xml.bzip2
5.5.8.3. 重新运行扫描
虽然可以作为调度的作业运行扫描,但通常必须根据需要重新运行扫描,特别是在应用修复或进行其他更改集群时。
流程
使用 Compliance Operator 重新运行扫描需要使用扫描对象上的注解。但是,通过
oc-compliance
插件,您可以使用单个命令重新运行扫描。输入以下命令为名为my-binding
的ScanSettingBinding
对象重新运行扫描:$ oc compliance rerun-now scansettingbindings my-binding
输出示例
Rerunning scans from 'my-binding': ocp4-cis Re-running scan 'openshift-compliance/ocp4-cis'
5.5.8.4. 使用 ScanSettingBinding 自定义资源
当使用由 Compliance Operator 提供的 ScanSetting
和 ScanSettingBinding
自定义资源(CR)时,可以在使用一组常用的扫描选项时,对多个配置集运行扫描,如 schedule
、machine roles
、tolerations
等。虽然这比使用多个 ComplianceSuite
或 ComplianceScan
对象更容易,但可能会让新用户混淆。
oc compliance bind
子命令可帮助您创建 ScanSettingBinding
CR。
流程
运行:
$ oc compliance bind [--dry-run] -N <binding name> [-S <scansetting name>] <objtype/objname> [..<objtype/objname>]
-
如果省略
-S
标志,则使用 Compliance Operator 提供的default
扫描设置。 -
对象类型是 Kubernetes 对象类型,可以是
profile
或tailorprofile
。可以提供多个对象。 -
对象名称是 Kubernetes 资源的名称,如
.metadata.name
。 添加
--dry-run
选项,以显示所创建对象的 YAML 文件。例如,给定以下配置集和扫描设置:
$ oc get profile.compliance -n openshift-compliance
输出示例
NAME AGE ocp4-cis 9m54s ocp4-cis-node 9m54s ocp4-e8 9m54s ocp4-moderate 9m54s ocp4-ncp 9m54s rhcos4-e8 9m54s rhcos4-moderate 9m54s rhcos4-ncp 9m54s rhcos4-ospp 9m54s rhcos4-stig 9m54s
$ oc get scansettings -n openshift-compliance
输出示例
NAME AGE default 10m default-auto-apply 10m
-
如果省略
要将
default
设置应用到ocp4-cis
和ocp4-cis-node
配置集,请运行:$ oc compliance bind -N my-binding profile/ocp4-cis profile/ocp4-cis-node
输出示例
Creating ScanSettingBinding my-binding
创建
ScanSettingBinding
CR 后,绑定配置集开始使用相关设置扫描两个配置集。总体而言,这是开始使用 Compliance Operator 扫描的最快方法。
5.5.8.5. 打印控制
合规标准通常分为层次结构,如下所示:
- 基准是特定标准的一组控制的顶级定义。例如,FedRAMP Moderate 或 Center for Internet Security(CIS)v.1.6.0。
- 控制描述了遵守基准必须满足的一系列要求。例如,FedRAMP AC-01(访问控制政策和程序)。
- 规则是单一检查,特定于要纳入合规性的系统,以及一个或多个这些规则映射到控制。
- Compliance Operator 处理将规则分组到配置集中的单个基准测试。可能很难确定哪些控制配置集中的规则集是否满足要求。
流程
oc compliance
control
子命令提供有关给定配置集满足的标准和控制标准的报告:$ oc compliance controls profile ocp4-cis-node
输出示例
+-----------+----------+ | FRAMEWORK | CONTROLS | +-----------+----------+ | CIS-OCP | 1.1.1 | + +----------+ | | 1.1.10 | + +----------+ | | 1.1.11 | + +----------+ ...
5.5.8.6. 获取合规补救详情
Compliance Operator 提供了补救对象,用于自动执行与集群兼容所需的更改。fetch-fixes
子命令可帮助您准确了解使用了哪些配置修复。使用 fetch-fixes
子命令,将修复对象从配置集、规则或 ComplianceRemediation
对象提取到要检查的目录中。
流程
查看配置集的补救:
$ oc compliance fetch-fixes profile ocp4-cis -o /tmp
输出示例
No fixes to persist for rule 'ocp4-api-server-api-priority-flowschema-catch-all' 1 No fixes to persist for rule 'ocp4-api-server-api-priority-gate-enabled' No fixes to persist for rule 'ocp4-api-server-audit-log-maxbackup' Persisted rule fix to /tmp/ocp4-api-server-audit-log-maxsize.yaml No fixes to persist for rule 'ocp4-api-server-audit-log-path' No fixes to persist for rule 'ocp4-api-server-auth-mode-no-aa' No fixes to persist for rule 'ocp4-api-server-auth-mode-node' No fixes to persist for rule 'ocp4-api-server-auth-mode-rbac' No fixes to persist for rule 'ocp4-api-server-basic-auth' No fixes to persist for rule 'ocp4-api-server-bind-address' No fixes to persist for rule 'ocp4-api-server-client-ca' Persisted rule fix to /tmp/ocp4-api-server-encryption-provider-cipher.yaml Persisted rule fix to /tmp/ocp4-api-server-encryption-provider-config.yaml
- 1
- 当配置集中没有对应的修复规则时会出现
No fixes to persist
警告,因为规则无法自动修复,或者没有提供相应的补救。
您可以查看 YAML 文件示例。
head
命令将显示前 10 行:$ head /tmp/ocp4-api-server-audit-log-maxsize.yaml
输出示例
apiVersion: config.openshift.io/v1 kind: APIServer metadata: name: cluster spec: maximumFileSizeMegabytes: 100
查看扫描后创建的
ComplianceRemediation
对象的补救:$ oc get complianceremediations -n openshift-compliance
输出示例
NAME STATE ocp4-cis-api-server-encryption-provider-cipher NotApplied ocp4-cis-api-server-encryption-provider-config NotApplied
$ oc compliance fetch-fixes complianceremediations ocp4-cis-api-server-encryption-provider-cipher -o /tmp
输出示例
Persisted compliance remediation fix to /tmp/ocp4-cis-api-server-encryption-provider-cipher.yaml
您可以查看 YAML 文件示例。
head
命令将显示前 10 行:$ head /tmp/ocp4-cis-api-server-encryption-provider-cipher.yaml
输出示例
apiVersion: config.openshift.io/v1 kind: APIServer metadata: name: cluster spec: encryption: type: aescbc
在直接应用补救前请小心。有些补救可能不适用于批量,如中等配置集中的 usbguard 规则。在这些情况下,允许 Compliance Operator 应用规则,因为它解决了依赖项并确保集群处于良好状态。
5.5.8.7. 查看 ComplianceCheckResult 对象详情
扫描运行结束时,会针对各个扫描规则创建 ComplianceCheckResult
对象。view-result
子命令提供了 ComplianceCheckResult
对象详细信息人类可读的输出。
流程
运行:
$ oc compliance view-result ocp4-cis-scheduler-no-bind-address