金融级IT架构与运维：云原生、分布式与安全最新章节_魏新宇著

4.1　容器云的安全加固

2021年很多客户都展开了“护网行动”。大多数在生产上使用OpenShift的客户，也针对OpenShift做了安全加固。在本节中，我们将分析容器云安全加固的思路以及如何采用企业方案进行安全加固。

4.1.1　手工安全加固手段

首先，我们看一下常见的网络攻击方式及其说明，如表4-1所示。

表4-1　常见的网络攻击方式及其说明

结合上表，我们看一下容器云平台常被攻击的点，如表4-2所示。

表4-2　容器云平台常被攻击的点

接下来，我们针对上述六种攻击方式，看如何对容器云进行安全加固。

1. 认证方案优化

OpenShift使用htpasswd认证方式。OpenShift平台与集中认证中心方案集成（如RHSSO），对平台用户认证进行加固和优化。设置密码的时候，应设置如下策略：

采用严格密码策略；
设置复杂密码规则，如数字位数、大小字母位数、特殊字符等；
禁止与用户名一致；
设置密码过期时间，如30天，过期后需要修改密码；
禁止使用已用过的密码，即修改密码时不能使用以前设置过的密码；
设置最大登录失败次数（Max Login Failure）；
采用双因子认证（Two-Factor Authentication）。

2. DDoS防御

DDoS防御，应采取多层防御的方式，如图4-1所示。

图4-1　DDoS多层防御

DDoS防御具体有两种方式，分析如下。

1）在F5上开启DDoS防御。

2）在OpenShift Router上增加相应配置实现DDoS防御：

设置http-request超时时间；
设置TCP并发连接数；
设置单个客户端TCP请求速率；
设置单个客户端HTTP请求速率。

需要注意的是，我们在OpenShift Router上设置DDoS防御的参数时，需要设置合理的数值，防止请求被误杀。

3. 镜像安全检查

在容器云中，镜像安全检查非常重要。我们有以下几条建议：

建议使用集成镜像扫描方案（如Clair）对平台及应用进行安全扫描；
避免使用非官方镜像（如社区镜像）；
标记镜像健康状况；
禁止使用低安全级别的镜像；
及时更新应用基础镜像。

红帽官方提供了300多种容器镜像，并划分了明确的健康等级。我们通常选取健康等级为A的镜像，如图4-2所示。

图4-2　红帽容器镜像健康等级

4. 权限检查

OpenShift权限检查应该包含以下几个方面：

OpenShift平台用户及角色梳理；
Service Account使用情况梳理；
容器SCC策略授权情况梳理；
网络隔离情况分析。

5. 漏洞修复

漏洞修复包含两个层面：

OpenShift平台漏洞修复（OCP升级、OCP迁移）；
宿主机（Linux操作系统）漏洞修复。

OpenShift和Linux操作系统都会定期发布漏洞列表，如图4-3所示。我们应该多关注该列表并及时进行漏洞修复。

图4-3　OpenShift云与Linux的漏洞列表

针对容器云的宿主机RHEL操作系统（OpenShift 4使用CoreOS，不用单独加固宿主机操作系统），应进行如下加固：

安全基线加固项审查，对安全基线不合规项目制定分类、分批次整改计划；
梳理防火墙规则，禁用不必要的ACL控制规则；
禁止root用户通过SSH登录；
对登录用户进行弱密码扫描，弱密码库由客户提供；
各系统管理员根据业务需要判断是否把某些非登录用途的账号设置为nologin；
各系统管理员检查/etc/sudoer文件中是否有过多提权命令供非root用户执行；
禁止各系统管理员使用chpasswd命令修改账户密码的行为；
护网行动结束后根据采取的安全整改措施，更新安全基线、Linux模板及规范配置文档；
获得最新CVE漏洞报告，根据CVE列表进行漏洞评估并修复（第三方报告或者巡检）；
整理每台主机对外监听的应用，应用中的RHEL层面组件进行重要级别安全补丁分析和修复。

6. 应用安全检查和防护

应用安全检查和防护包括平台方面防护和应用方面防护，具体分析如下。

平台方面防护要做到如下几点：

启用HTTPS/SSL安全网络传输（在Router上开启HTTPS设置）；
DDoS防御（通过在Router开启DDoS防御对应用进行保护）。

应用方面防护需做到以下几点：

密码、证书等敏感信息管理，避免明文配置（如Hashicorp Vault）；
不要在日志中输出用户名、密码、Token等敏感信息；
应用SQL注入检查（如防止SQL拼接，增加Filter检查）；
XSS防御（如通过Filter对HTML标签进行转义）。

在介绍了容器云手工安全加固手段后，接下来我们介绍如何使用工具对容器云进行安全加固。

4.1.2　传统的DevSecOps

DevSecOps，顾名思义，是针对DevOps的安全治理。DevSecOps是一种旨在将安全性嵌入DevOps链条中每个部分的新方法，它有助于在开发过程早期而不是产品发布后识别安全问题，目标是让每个人对信息安全负责，而不仅仅是让安全部门负责。

DevSevOps的Web类安全工具大体分为静态安全工具和动态应用安全工具两类。

静态安全工具主要通过分析或者检查Web应用程序源代码的语法、结构、过程、接口等来保证程序的正确性。静态安全工具使我们能在开发阶段（而非应用开发完成后）探测出源码中的安全漏洞，从而大大降低修复安全问题的成本。
相比静态安全分析工具在开发阶段发现问题，动态应用安全工具是在Web应用运行时模拟黑客攻击，从而无须源代码即可识别安全漏洞，并确定组织的实际风险。

在开源界，静态应用安全工具如SonaQube，动态应用安全工具如OWASP（Open Web Application Security Project，开放式Web应用程序安全项目）都被广泛使用。

我们通过一个基于OpenShift的DevSecOps模型展示DevSecOps实现的方式。OpenShift通过将安全嵌入应用开发中来实现DevSecOps，主要包含以下三部分内容。

CI/CD的实现：通过OpenShift Pipeline（OpenShift 3通过Jenkins实现，OpenShift 4通过Teckton实现）、S2I实现CI/CD。
内置的安全检查：将安全检查工具部署在OpenShift中，并通过OpenShift Pipeline串接。安全检查工具包括SonarQube、OWASP、OpenSCAP等。
自动化操作：利用OpenShift的监控功能，监控并响应不断变化的需求、负载、威胁等。例如当有应用代码提交时，自动触发构建；当应用性能不足时，自动扩展Pod的实例；当发现安全相关的问题时，自动发送告警等。

接下来，我们查看基于OpenShift实现DevSecOps的模型架构图，如图4-4所示。

图4-4　DevSecOps模型架构图

由于篇幅有限，Pipeline的yaml文件会放在repo上，地址为https://github.com/davidsajare/FSI-IT-construction/blob/main/Chapter4/Jenkinsfile。

在Jenkins界面中启动Pipeline，如图4-5所示。

图4-5　在Jenkins中启动Pipeline

启动Pipeline后，通过Jenkins Blue Ocean界面进行观测，如图4-6所示。

图4-6　切换到Jenkins Blue Ocean界面

在Jenkins Blue Ocean界面观测Pipeline的执行情况。在执行到Promote to Stage时，引入人工审批，如图4-7所示。

图4-7　Pipeline引入人工审批

此时，可以根据动态扫描和静态扫描的报告来做决策。在Jenkins Blue Ocean界面点击制品，如图4-8所示，可以看到生成的三个检查报告和pipeline.log。三个检查结果分别是OpenSCAP扫描结果和OWASP ZAP动态扫描结果。

图4-8　查看Pipeline执行过程中生成的制品

为了判断是否批准Pipeline继续执行，可以查看openscap-compliance-report.html，分析应用容器镜像的漏洞扫描结果。从图4-9中可以看出，检查通过了34项，失败了35项。

图4-9　查看openscap-compliance-report.html

查看openscap-cve-report.html报告中对应用容器镜像的CVE扫描结果，如图4-10所示。

图4-10　查看openscap-cev-report.html

查看owasp-zap-baseline.html报告中应用动态安全扫描的结果，可以看到不同风险级别对应的数量，中等级别的漏洞有两个，低级别的告警有两个，如图4-11所示。

图4-11　查看owasp-zap-baseline.html报告

查看owasp报告中一个中等级别漏洞的问题，如图4-12所示，发现均属于较为常见的Web安全问题。

图4-12　查看一个中等级别的漏洞

在分析了动态扫描结果和OpenSCAP扫描结果后，接下来我们查看静态代码扫描结果。登录SonarQube，可以看到应用扫描发现3个漏洞、11个代码异味（Code Smell）、单元测试代码的覆盖率为56.9%等信息，如图4-13所示。

图4-13　查看静态代码扫描结果

我们查看3个漏洞的具体描述，如图4-14所示。

图4-14　查看3个漏洞的描述

查看扫描结果中11个代码异味的具体内容，如图4-15所示。

图4-15　查看代码异味的具体内容

在查看了动态扫描、OpenSCAP扫描和静态代码扫描的结果后，如果均符合我们的要求，可以分别批准将应用部署到Stage和Prod环境。

我们批准应用在Stage和Prod环境部署，然后可以看到user1-stage和user1-prod项目中会部署应用。

[root@bastion 0 ～]# oc get pods -n user1-stage
NAME                  READY     STATUS    RESTARTS   AGE
ecommerce-1-1-l47rq   1/1       Running   0          3m
ecommerce-1-bllkf     1/1       Running   0          3m

[root@bastion 0 ～]# oc get pods -n user1-prod
NAME                  READY     STATUS    RESTARTS   AGE
ecommerce-1-1-b9h9x   1/1       Running   0          3m
ecommerce-1-9w5lf     1/1       Running   0          3m

通过浏览器可以分别访问两个项目中的应用路由，如图4-16所示。

图4-16　浏览器访问部署好的应用

4.1.3　借助StackRox实现DevSecOps

上一节介绍的DevSecOps模型存在一个问题，即无法从Kubernetes层做安全加固，例如：已运行的容器应用漏洞分析、Kubernetes层面的应用配置分析、Kubernetes层面的合规评估、Kubernetes层面的风险分析、Kubernetes层面的运行时行为分析、Kubernetes层面的自动建议网络策略、Kubernetes层面的威胁检测及事件响应。

目前在开源社区，常用的Kubernetes相关的安全工具主要有8个，具体分析如下。

1. OPA

OPA（Open Policy Agent，开放策略代理）是一个非常强大的工具，可以执行上下文感知的安全策略。随着Kubernetes 1.21版本启动的Pod安全策略（Pod Security Policy）的废弃（以及在1.25版本中已完全删除），许多组织可能会转向OPA来填补这一空白。

2. KubeLinter

KubeLinter是一个静态分析工具，可以扫描、分析YAML文件和Helm图表，并根据各种最佳实践对其进行检查。

KubeLinter带有默认检查，旨在提供有关Kubernetes YAML文件和Helm图表的有用信息。这有助于团队及早检查并发现安全错误配置和DevOps最佳实践。其中一些常见的例子包括以非root用户身份运行容器，执行最小权限，以及只在Kubernetes Secret中存储敏感信息。

3. Kube-bench

Kube-bench可以根据Kubernetes的CIS安全基准中推荐的安全检查来审计Kubernetes的设置。它的扫描功能是用YAML文件配置的，工具本身是用Go语言编写的，这是Kubernetes开发者熟悉的语言。

4. Kube-hunter

Kube-hunter与Kube-bench是由同一个团队开发，它寻找Kubernetes集群中可利用的安全弱点。Kube-hunter更有用的功能之一是利用它发现的漏洞能够寻找进一步的漏洞。

5. Terrascan

Terracan建立在OPA之上，是一个开源的静态代码分析器，用于IaC。Terrascan拥有超过500个跨越各种应用的安全最佳实践策略，包括Terraform、Kubernetes（JSON/YAML）、AWS、Azure、GCP和GitHub，它可以检测安全漏洞和是否违反合规性，并在配置基础设施之前减轻风险。

6. Falco

Falco是本节中唯一一个为运行时安全而构建的开源工具。Falco还提供安全策略，使用来自Kubernetes和内核事件的上下文数据来检测异常应用行为。

7. Clair

Clair是一个开源的安全工具，用于扫描容器镜像的已知漏洞。它是一个静态分析工具，所以不能在运行时检测漏洞。

8. Checkov

Checkov是一款针对IaC的静态代码分析工具。最新版本的Chekov引入了基于上下文的分析。它通过对云基础设施进行基于图形的扫描来检测错误配置，这些基础设施是用Terraform、Cloudformation、Kubernetes、Dockerfile、Serverless或ARM模板等应用配置的。

对于以上开源社区的Kubernetes安全工具，企业在使用时，往往需要使用多个，复杂度较高。我们可以借助企业级开源安全工具，如StackRox来实现容器云的安全。

StackRox成立于2014年，它的业务重心是保障企业级Kubernetes平台安全性。StackRox通过在Kubernetes集群基础设施中直接部署可实施深度数据收集的组件，提供对所有Kubernetes集群的可见性，减少提高安全性所需的时间和精力，简化安全分析、调查和补救过程。StackRox策略引擎包含数百个内置控件，用于强制执行最佳安全实践、行业标准（如CIS安全基准和NIST）、容器和Kubernetes的配置管理以及运行时安全性。

2020年红帽收购StackRox，把StackRox强大的Kubernetes本地安全功能引入OpenShift，进一步实现其愿景：提供一个整体平台，使用户可以在混合云环境中，部署并且安全运行几乎所有的应用程序云。

借助StackRox，红帽将专注于改变云原生工作负载的保护方式，通过扩展和完善Kubernetes原生控件，并将安全性工作转移到容器构建和CI/CD阶段，打造DevSecOps。StackRox将继续支持多个Kubernetes平台，包括Amazon Elastic Kubernetes Service、Microsoft Azure Kubernetes Service、Google Kubernetes Engine。

StackRox的架构如图4-17所示，我们看到StackRox是被部署到一个Kubernetes集群，然后由被管集群上运行的Pod管理。

图4-17　StackRox的架构

我们登录到被管容器云平台，查看StackRox对应的组件，这些组件和图4-17是对应的，如图4-18所示。

图4-18　StackRox对应的组件

那么，StackRox能够实现什么安全功能呢？StackRox能够帮助客户实现DevSecOps，即安全左移。具体而言，StackRox在DevSecOps中能做的事情包括以下几类，如图4-19下半部分方格所示。

图4-19　StackRox的功能

通过OpenShift与StackRox以及其他安全工具相结合，我们可以实现完整的堆栈的DevSecOps。

接下来，我们登录StackRox界面，看看它的实际效果。

首先查看Dashboard，如图4-20所示。可以看到本例纳管了1个集群、5个节点。我们也可以看到安全合规的情况。

图4-20　查看Dashboard

通过Dashboard可以看到有风险的Deployment，排在第一位的是名为visa-processor的Deployment，如图4-21所示。

图4-21　查看有风险的deployment

这个Deployment违反的安全策略如图4-22所示。

图4-22　Deployment违反的安全策略

我们可以查看容器云中Pod网络通信情况，如图4-23所示。

图4-23　容器云中Pod网络通信

StackRox默认用几个国际规范来扫描容器云，扫描结果如图4-24所示。

图4-24　StackRox安全扫描结果

可以看出，CIS Docker通过率最高，NIST SP 800-53标准通过率最低。

查看风险管理情况，如图4-25所示。

图4-25　查看风险管理情况

我们看到容器镜像也被扫描了，其中有一个不合规的镜像，镜像不合规的组件如图4-26所示。

图4-26　扫描出的镜像不合规的组件

针对不合规的组件，StackRox会自动扫描出对应的CVE，如图4-27所示。

图4-27　自动扫描出漏洞对应的CVE

接下来，我们通过一个简单的实验，验证StackRox在Pipeline中的应用。

在OpenShift的一个Namespace中，有Tekton的Pipeline，我们查看其关键部分：

description: Rox demo pipeline
params:
- description: 'Full name of image to scan (example -- gcr.io/rox/sample:5.0-rc1)'
name: image
type: string
tasks:
- name: image-scan
params:
- name: image
value: $(params.image)
- name: rox_api_token
value: roxsecrets
- name: rox_central_endpoint
value: roxsecrets
- name: output_format
value: pretty
taskRef:
kind: ClusterTask
name: rox-image-scan
- name: image-check
params:
- name: image
value: $(params.image)
- name: rox_api_token
value: roxsecrets
- name: rox_central_endpoint
value: roxsecrets
taskRef:
kind: ClusterTask
name: rox-image-check

这个Pipeline包含如下两个任务：

rox-image-scan (image-scan)：用于镜像扫描。
rox-image-check (image-check)：用于镜像检查。

实际上，这两个任务可以被嵌入更为复杂的Pipeline中的镜像扫描部分。

下面查看这两个任务的yaml文件中的关键部分。

1）rox-image-scan任务：

image: centos
name: rox-image-scan
resources: {}
script: >-
        #!/usr/bin/env bash
        set +x
curl -k -L -H "Authorization: Bearer $ROX_API_TOKEN"
https://$ROX_CENTRAL_ENDPOINT/api/cli/download/roxctl-linux --output
./roxctl  > /dev/null; echo "Getting roxctl"

chmod +x ./roxctl > /dev/null

./roxctl image scan --insecure-skip-tls-verify -e $ROX_CENTRAL_ENDPOINT
--image $(params.image) --format $(params.output_format)

2）rox-image-check任务：

image: centos
name: rox-image-check
resources: {}
script: >-
        #!/usr/bin/env bash
        set +x
curl -k -L -H "Authorization: Bearer $ROX_API_TOKEN"
https://$ROX_CENTRAL_ENDPOINT/api/cli/download/roxctl-linux --output
        ./roxctl  > /dev/null; echo "Getting roxctl"
        chmod +x ./roxctl  > /dev/null
./roxctl image check --insecure-skip-tls-verify -e $ROX_CENTRAL_ENDPOINT
--image $(params.image)

我们看到，上面两个任务中用到了roxctl。roxctl是StackRox Kubernetes安全平台的命令行客户端，就像Kubernetes的kubectl一样。

运行Pipeline，发现任务运行失败，因为镜像违反了测试，即镜像中不能有curl命令，如图4-28所示。

图4-28　任务运行失败

我们到StackRox中查看Curl in Image策略，如图4-29所示。

图4-29　查看Curl in Image策略

接下来，修改这个策略，当检查到镜像中有curl命令时，不阻止构建和部署，如图4-30所示。

图4-30　修改策略

保存策略后，再次执行Pipeline，虽然也能检测到镜像中含有curl命令，但并未阻止Pipeline的运行，如图4-31所示。

图4-31　任务成功运行

本案例只是简单展现了StackRox与Tekton相结合的例子。在实际的场景中，我们可以将本案例的rox-image-scan和rox-image-check任务嵌入复杂的Pipeline中。例如，在做应用容器化前（如S2I）进行类似rox-image-scan和rox-image-check的操作，如果不能通过这两项检查，则自动拒绝应用容器化。除了参与到DevSecOps Pipeline中，StackRox更为强大的功能体现在对容器云运行状态的安全扫描。

4.1 容器云的安全加固

4.1.1 手工安全加固手段