下载掌阅APP，畅读海量书库
立即打开
2021年很多客户都展开了“护网行动”。大多数在生产上使用OpenShift的客户，也针对OpenShift做了安全加固。在本节中，我们将分析容器云安全加固的思路以及如何采用企业方案进行安全加固。
首先，我们看一下常见的网络攻击方式及其说明，如表4-1所示。
表4-1 常见的网络攻击方式及其说明
结合上表，我们看一下容器云平台常被攻击的点，如表4-2所示。
表4-2 容器云平台常被攻击的点
接下来，我们针对上述六种攻击方式，看如何对容器云进行安全加固。
OpenShift使用htpasswd认证方式。OpenShift平台与集中认证中心方案集成（如RHSSO），对平台用户认证进行加固和优化。设置密码的时候，应设置如下策略：
DDoS防御，应采取多层防御的方式，如图4-1所示。
图4-1 DDoS多层防御
DDoS防御具体有两种方式，分析如下。
1）在F5上开启DDoS防御。
2）在OpenShift Router上增加相应配置实现DDoS防御：
需要注意的是，我们在OpenShift Router上设置DDoS防御的参数时，需要设置合理的数值，防止请求被误杀。
在容器云中，镜像安全检查非常重要。我们有以下几条建议：
红帽官方提供了300多种容器镜像，并划分了明确的健康等级。我们通常选取健康等级为A的镜像，如图4-2所示。
图4-2 红帽容器镜像健康等级
OpenShift权限检查应该包含以下几个方面：
漏洞修复包含两个层面：
OpenShift和Linux操作系统都会定期发布漏洞列表，如图4-3所示。我们应该多关注该列表并及时进行漏洞修复。
图4-3 OpenShift云与Linux的漏洞列表
针对容器云的宿主机RHEL操作系统（OpenShift 4使用CoreOS，不用单独加固宿主机操作系统），应进行如下加固：
应用安全检查和防护包括平台方面防护和应用方面防护，具体分析如下。
平台方面防护要做到如下几点：
应用方面防护需做到以下几点：
在介绍了容器云手工安全加固手段后，接下来我们介绍如何使用工具对容器云进行安全加固。
DevSecOps，顾名思义，是针对DevOps的安全治理。DevSecOps是一种旨在将安全性嵌入DevOps链条中每个部分的新方法，它有助于在开发过程早期而不是产品发布后识别安全问题，目标是让每个人对信息安全负责，而不仅仅是让安全部门负责。
DevSevOps的Web类安全工具大体分为静态安全工具和动态应用安全工具两类。
在开源界，静态应用安全工具如SonaQube，动态应用安全工具如OWASP（Open Web Application Security Project，开放式Web应用程序安全项目）都被广泛使用。
我们通过一个基于OpenShift的DevSecOps模型展示DevSecOps实现的方式。OpenShift通过将安全嵌入应用开发中来实现DevSecOps，主要包含以下三部分内容。
接下来，我们查看基于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 浏览器访问部署好的应用
上一节介绍的DevSecOps模型存在一个问题，即无法从Kubernetes层做安全加固，例如：已运行的容器应用漏洞分析、Kubernetes层面的应用配置分析、Kubernetes层面的合规评估、Kubernetes层面的风险分析、Kubernetes层面的运行时行为分析、Kubernetes层面的自动建议网络策略、Kubernetes层面的威胁检测及事件响应。
目前在开源社区，常用的Kubernetes相关的安全工具主要有8个，具体分析如下。
OPA（Open Policy Agent，开放策略代理）是一个非常强大的工具，可以执行上下文感知的安全策略。随着Kubernetes 1.21版本启动的Pod安全策略（Pod Security Policy）的废弃（以及在1.25版本中已完全删除），许多组织可能会转向OPA来填补这一空白。
KubeLinter是一个静态分析工具，可以扫描、分析YAML文件和Helm图表，并根据各种最佳实践对其进行检查。
KubeLinter带有默认检查，旨在提供有关Kubernetes YAML文件和Helm图表的有用信息。这有助于团队及早检查并发现安全错误配置和DevOps最佳实践。其中一些常见的例子包括以非root用户身份运行容器，执行最小权限，以及只在Kubernetes Secret中存储敏感信息。
Kube-bench可以根据Kubernetes的CIS安全基准中推荐的安全检查来审计Kubernetes的设置。它的扫描功能是用YAML文件配置的，工具本身是用Go语言编写的，这是Kubernetes开发者熟悉的语言。
Kube-hunter与Kube-bench是由同一个团队开发，它寻找Kubernetes集群中可利用的安全弱点。Kube-hunter更有用的功能之一是利用它发现的漏洞能够寻找进一步的漏洞。
Terracan建立在OPA之上，是一个开源的静态代码分析器，用于IaC。Terrascan拥有超过500个跨越各种应用的安全最佳实践策略，包括Terraform、Kubernetes（JSON/YAML）、AWS、Azure、GCP和GitHub，它可以检测安全漏洞和是否违反合规性，并在配置基础设施之前减轻风险。
Falco是本节中唯一一个为运行时安全而构建的开源工具。Falco还提供安全策略，使用来自Kubernetes和内核事件的上下文数据来检测异常应用行为。
Clair是一个开源的安全工具，用于扫描容器镜像的已知漏洞。它是一个静态分析工具，所以不能在运行时检测漏洞。
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包含如下两个任务：
实际上，这两个任务可以被嵌入更为复杂的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更为强大的功能体现在对容器云运行状态的安全扫描。