4.1　容器云的安全加固

2021年很多客戶都展開了“護網(wǎng)行動”。大多數(shù)在生產(chǎn)上使用OpenShift的客戶，也針對OpenShift做了安全加固。在本節(jié)中，我們將分析容器云安全加固的思路以及如何采用企業(yè)方案進行安全加固。

4.1.1　手工安全加固手段

首先，我們看一下常見的網(wǎng)絡攻擊方式及其說明，如表4-1所示。

結合上表，我們看一下容器云平臺常被攻擊的點，如表4-2所示。

接下來，我們針對上述六種攻擊方式，看如何對容器云進行安全加固。

1. 認證方案優(yōu)化

OpenShift使用htpasswd認證方式。OpenShift平臺與集中認證中心方案集成（如RHSSO），對平臺用戶認證進行加固和優(yōu)化。設置密碼的時候，應設置如下策略：

• 采用嚴格密碼策略；
• 設置復雜密碼規(guī)則，如數(shù)字位數(shù)、大小字母位數(shù)、特殊字符等；
• 禁止與用戶名一致；
• 設置密碼過期時間，如30天，過期后需要修改密碼；
• 禁止使用已用過的密碼，即修改密碼時不能使用以前設置過的密碼；
• 設置最大登錄失敗次數(shù)（Max Login Failure）；
• 采用雙因子認證（Two-Factor Authentication）。

2. DDoS防御

DDoS防御，應采取多層防御的方式，如圖4-1所示。

DDoS防御具體有兩種方式，分析如下。

1）在F5上開啟DDoS防御。

2）在OpenShift Router上增加相應配置實現(xiàn)DDoS防御：

• 設置http-request超時時間；
• 設置TCP并發(fā)連接數(shù)；
• 設置單個客戶端TCP請求速率；
• 設置單個客戶端HTTP請求速率。

需要注意的是，我們在OpenShift Router上設置DDoS防御的參數(shù)時，需要設置合理的數(shù)值，防止請求被誤殺。

3. 鏡像安全檢查

在容器云中，鏡像安全檢查非常重要。我們有以下幾條建議：

• 建議使用集成鏡像掃描方案（如Clair）對平臺及應用進行安全掃描；
• 避免使用非官方鏡像（如社區(qū)鏡像）；
• 標記鏡像健康狀況；
• 禁止使用低安全級別的鏡像；
• 及時更新應用基礎鏡像。

紅帽官方提供了300多種容器鏡像，并劃分了明確的健康等級。我們通常選取健康等級為A的鏡像，如圖4-2所示。

4. 權限檢查

OpenShift權限檢查應該包含以下幾個方面：

• OpenShift平臺用戶及角色梳理；
• Service Account使用情況梳理；
• 容器SCC策略授權情況梳理；
• 網(wǎng)絡隔離情況分析。

5. 漏洞修復

漏洞修復包含兩個層面：

• OpenShift平臺漏洞修復（OCP升級、OCP遷移）；
• 宿主機（Linux操作系統(tǒng)）漏洞修復。

OpenShift和Linux操作系統(tǒng)都會定期發(fā)布漏洞列表，如圖4-3所示。我們應該多關注該列表并及時進行漏洞修復。

針對容器云的宿主機RHEL操作系統(tǒng)（OpenShift 4使用CoreOS，不用單獨加固宿主機操作系統(tǒng)），應進行如下加固：

• 安全基線加固項審查，對安全基線不合規(guī)項目制定分類、分批次整改計劃；
• 梳理防火墻規(guī)則，禁用不必要的ACL控制規(guī)則；
• 禁止root用戶通過SSH登錄；
• 對登錄用戶進行弱密碼掃描，弱密碼庫由客戶提供；
• 各系統(tǒng)管理員根據(jù)業(yè)務需要判斷是否把某些非登錄用途的賬號設置為nologin；
• 各系統(tǒng)管理員檢查/etc/sudoer文件中是否有過多提權命令供非root用戶執(zhí)行；
• 禁止各系統(tǒng)管理員使用chpasswd命令修改賬戶密碼的行為；
• 護網(wǎng)行動結束后根據(jù)采取的安全整改措施，更新安全基線、Linux模板及規(guī)范配置文檔；
• 獲得最新CVE漏洞報告，根據(jù)CVE列表進行漏洞評估并修復（第三方報告或者巡檢）；
• 整理每臺主機對外監(jiān)聽的應用，應用中的RHEL層面組件進行重要級別安全補丁分析和修復。

6. 應用安全檢查和防護

應用安全檢查和防護包括平臺方面防護和應用方面防護，具體分析如下。

平臺方面防護要做到如下幾點：

• 啟用HTTPS/SSL安全網(wǎng)絡傳輸（在Router上開啟HTTPS設置）；
• DDoS防御（通過在Router開啟DDoS防御對應用進行保護）。

應用方面防護需做到以下幾點：

• 密碼、證書等敏感信息管理，避免明文配置（如Hashicorp Vault）；
• 不要在日志中輸出用戶名、密碼、Token等敏感信息；
• 應用SQL注入檢查（如防止SQL拼接，增加Filter檢查）；
• XSS防御（如通過Filter對HTML標簽進行轉(zhuǎn)義）。

在介紹了容器云手工安全加固手段后，接下來我們介紹如何使用工具對容器云進行安全加固。

4.1.2　傳統(tǒng)的DevSecOps

DevSecOps，顧名思義，是針對DevOps的安全治理。DevSecOps是一種旨在將安全性嵌入DevOps鏈條中每個部分的新方法，它有助于在開發(fā)過程早期而不是產(chǎn)品發(fā)布后識別安全問題，目標是讓每個人對信息安全負責，而不僅僅是讓安全部門負責。

DevSevOps的Web類安全工具大體分為靜態(tài)安全工具和動態(tài)應用安全工具兩類。

• 靜態(tài)安全工具主要通過分析或者檢查Web應用程序源代碼的語法、結構、過程、接口等來保證程序的正確性。靜態(tài)安全工具使我們能在開發(fā)階段（而非應用開發(fā)完成后）探測出源碼中的安全漏洞，從而大大降低修復安全問題的成本。
• 相比靜態(tài)安全分析工具在開發(fā)階段發(fā)現(xiàn)問題，動態(tài)應用安全工具是在Web應用運行時模擬黑客攻擊，從而無須源代碼即可識別安全漏洞，并確定組織的實際風險。

在開源界，靜態(tài)應用安全工具如SonaQube，動態(tài)應用安全工具如OWASP（Open Web Application Security Project，開放式Web應用程序安全項目）都被廣泛使用。

我們通過一個基于OpenShift的DevSecOps模型展示DevSecOps實現(xiàn)的方式。OpenShift通過將安全嵌入應用開發(fā)中來實現(xiàn)DevSecOps，主要包含以下三部分內(nèi)容。

• CI/CD的實現(xiàn)：通過OpenShift Pipeline（OpenShift 3通過Jenkins實現(xiàn)，OpenShift 4通過Teckton實現(xiàn)）、S2I實現(xiàn)CI/CD。
• 內(nèi)置的安全檢查：將安全檢查工具部署在OpenShift中，并通過OpenShift Pipeline串接。安全檢查工具包括SonarQube、OWASP、OpenSCAP等。
• 自動化操作：利用OpenShift的監(jiān)控功能，監(jiān)控并響應不斷變化的需求、負載、威脅等。例如當有應用代碼提交時，自動觸發(fā)構建；當應用性能不足時，自動擴展Pod的實例；當發(fā)現(xiàn)安全相關的問題時，自動發(fā)送告警等。

接下來，我們查看基于OpenShift實現(xiàn)DevSecOps的模型架構圖，如圖4-4所示。

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

在Jenkins界面中啟動Pipeline，如圖4-5所示。

啟動Pipeline后，通過Jenkins Blue Ocean界面進行觀測，如圖4-6所示。

在Jenkins Blue Ocean界面觀測Pipeline的執(zhí)行情況。在執(zhí)行到Promote to Stage時，引入人工審批，如圖4-7所示。

此時，可以根據(jù)動態(tài)掃描和靜態(tài)掃描的報告來做決策。在Jenkins Blue Ocean界面點擊制品，如圖4-8所示，可以看到生成的三個檢查報告和pipeline.log。三個檢查結果分別是OpenSCAP掃描結果和OWASP ZAP動態(tài)掃描結果。

為了判斷是否批準Pipeline繼續(xù)執(zhí)行，可以查看openscap-compliance-report.html，分析應用容器鏡像的漏洞掃描結果。從圖4-9中可以看出，檢查通過了34項，失敗了35項。

查看openscap-cve-report.html報告中對應用容器鏡像的CVE掃描結果，如圖4-10所示。

查看owasp-zap-baseline.html報告中應用動態(tài)安全掃描的結果，可以看到不同風險級別對應的數(shù)量，中等級別的漏洞有兩個，低級別的告警有兩個，如圖4-11所示。

查看owasp報告中一個中等級別漏洞的問題，如圖4-12所示，發(fā)現(xiàn)均屬于較為常見的Web安全問題。

在分析了動態(tài)掃描結果和OpenSCAP掃描結果后，接下來我們查看靜態(tài)代碼掃描結果。登錄SonarQube，可以看到應用掃描發(fā)現(xiàn)3個漏洞、11個代碼異味（Code Smell）、單元測試代碼的覆蓋率為56.9%等信息，如圖4-13所示。

我們查看3個漏洞的具體描述，如圖4-14所示。

查看掃描結果中11個代碼異味的具體內(nèi)容，如圖4-15所示。

在查看了動態(tài)掃描、OpenSCAP掃描和靜態(tài)代碼掃描的結果后，如果均符合我們的要求，可以分別批準將應用部署到Stage和Prod環(huán)境。

我們批準應用在Stage和Prod環(huán)境部署，然后可以看到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.1.3　借助StackRox實現(xiàn)DevSecOps

上一節(jié)介紹的DevSecOps模型存在一個問題，即無法從Kubernetes層做安全加固，例如：已運行的容器應用漏洞分析、Kubernetes層面的應用配置分析、Kubernetes層面的合規(guī)評估、Kubernetes層面的風險分析、Kubernetes層面的運行時行為分析、Kubernetes層面的自動建議網(wǎng)絡策略、Kubernetes層面的威脅檢測及事件響應。

目前在開源社區(qū)，常用的Kubernetes相關的安全工具主要有8個，具體分析如下。

1. OPA

OPA（Open Policy Agent，開放策略代理）是一個非常強大的工具，可以執(zhí)行上下文感知的安全策略。隨著Kubernetes 1.21版本啟動的Pod安全策略（Pod Security Policy）的廢棄（以及在1.25版本中已完全刪除），許多組織可能會轉(zhuǎn)向OPA來填補這一空白。

2. KubeLinter

KubeLinter是一個靜態(tài)分析工具，可以掃描、分析YAML文件和Helm圖表，并根據(jù)各種最佳實踐對其進行檢查。

KubeLinter帶有默認檢查，旨在提供有關Kubernetes YAML文件和Helm圖表的有用信息。這有助于團隊及早檢查并發(fā)現(xiàn)安全錯誤配置和DevOps最佳實踐。其中一些常見的例子包括以非root用戶身份運行容器，執(zhí)行最小權限，以及只在Kubernetes Secret中存儲敏感信息。

3. Kube-bench

Kube-bench可以根據(jù)Kubernetes的CIS安全基準中推薦的安全檢查來審計Kubernetes的設置。它的掃描功能是用YAML文件配置的，工具本身是用Go語言編寫的，這是Kubernetes開發(fā)者熟悉的語言。

4. Kube-hunter

Kube-hunter與Kube-bench是由同一個團隊開發(fā)，它尋找Kubernetes集群中可利用的安全弱點。Kube-hunter更有用的功能之一是利用它發(fā)現(xiàn)的漏洞能夠?qū)ふ疫M一步的漏洞。

5. Terrascan

Terracan建立在OPA之上，是一個開源的靜態(tài)代碼分析器，用于IaC。Terrascan擁有超過500個跨越各種應用的安全最佳實踐策略，包括Terraform、Kubernetes（JSON/YAML）、AWS、Azure、GCP和GitHub，它可以檢測安全漏洞和是否違反合規(guī)性，并在配置基礎設施之前減輕風險。

6. Falco

Falco是本節(jié)中唯一一個為運行時安全而構建的開源工具。Falco還提供安全策略，使用來自Kubernetes和內(nèi)核事件的上下文數(shù)據(jù)來檢測異常應用行為。

7. Clair

Clair是一個開源的安全工具，用于掃描容器鏡像的已知漏洞。它是一個靜態(tài)分析工具，所以不能在運行時檢測漏洞。

8. Checkov

Checkov是一款針對IaC的靜態(tài)代碼分析工具。最新版本的Chekov引入了基于上下文的分析。它通過對云基礎設施進行基于圖形的掃描來檢測錯誤配置，這些基礎設施是用Terraform、Cloudformation、Kubernetes、Dockerfile、Serverless或ARM模板等應用配置的。

對于以上開源社區(qū)的Kubernetes安全工具，企業(yè)在使用時，往往需要使用多個，復雜度較高。我們可以借助企業(yè)級開源安全工具，如StackRox來實現(xiàn)容器云的安全。

StackRox成立于2014年，它的業(yè)務重心是保障企業(yè)級Kubernetes平臺安全性。StackRox通過在Kubernetes集群基礎設施中直接部署可實施深度數(shù)據(jù)收集的組件，提供對所有Kubernetes集群的可見性，減少提高安全性所需的時間和精力，簡化安全分析、調(diào)查和補救過程。StackRox策略引擎包含數(shù)百個內(nèi)置控件，用于強制執(zhí)行最佳安全實踐、行業(yè)標準（如CIS安全基準和NIST）、容器和Kubernetes的配置管理以及運行時安全性。

2020年紅帽收購StackRox，把StackRox強大的Kubernetes本地安全功能引入OpenShift，進一步實現(xiàn)其愿景：提供一個整體平臺，使用戶可以在混合云環(huán)境中，部署并且安全運行幾乎所有的應用程序云。

借助StackRox，紅帽將專注于改變云原生工作負載的保護方式，通過擴展和完善Kubernetes原生控件，并將安全性工作轉(zhuǎn)移到容器構建和CI/CD階段，打造DevSecOps。StackRox將繼續(xù)支持多個Kubernetes平臺，包括Amazon Elastic Kubernetes Service、Microsoft Azure Kubernetes Service、Google Kubernetes Engine。

StackRox的架構如圖4-17所示，我們看到StackRox是被部署到一個Kubernetes集群，然后由被管集群上運行的Pod管理。

我們登錄到被管容器云平臺，查看StackRox對應的組件，這些組件和圖4-17是對應的，如圖4-18所示。

那么，StackRox能夠?qū)崿F(xiàn)什么安全功能呢？StackRox能夠幫助客戶實現(xiàn)DevSecOps，即安全左移。具體而言，StackRox在DevSecOps中能做的事情包括以下幾類，如圖4-19下半部分方格所示。

通過OpenShift與StackRox以及其他安全工具相結合，我們可以實現(xiàn)完整的堆棧的DevSecOps。

接下來，我們登錄StackRox界面，看看它的實際效果。

首先查看Dashboard，如圖4-20所示。可以看到本例納管了1個集群、5個節(jié)點。我們也可以看到安全合規(guī)的情況。

通過Dashboard可以看到有風險的Deployment，排在第一位的是名為visa-processor的Deployment，如圖4-21所示。

這個Deployment違反的安全策略如圖4-22所示。

我們可以查看容器云中Pod網(wǎng)絡通信情況，如圖4-23所示。

StackRox默認用幾個國際規(guī)范來掃描容器云，掃描結果如圖4-24所示。

可以看出，CIS Docker通過率最高，NIST SP 800-53標準通過率最低。

查看風險管理情況，如圖4-25所示。

我們看到容器鏡像也被掃描了，其中有一個不合規(guī)的鏡像，鏡像不合規(guī)的組件如圖4-26所示。

針對不合規(guī)的組件，StackRox會自動掃描出對應的CVE，如圖4-27所示。

接下來，我們通過一個簡單的實驗，驗證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，發(fā)現(xiàn)任務運行失敗，因為鏡像違反了測試，即鏡像中不能有curl命令，如圖4-28所示。

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

接下來，修改這個策略，當檢查到鏡像中有curl命令時，不阻止構建和部署，如圖4-30所示。

保存策略后，再次執(zhí)行Pipeline，雖然也能檢測到鏡像中含有curl命令，但并未阻止Pipeline的運行，如圖4-31所示。

本案例只是簡單展現(xiàn)了StackRox與Tekton相結合的例子。在實際的場景中，我們可以將本案例的rox-image-scan和rox-image-check任務嵌入復雜的Pipeline中。例如，在做應用容器化前（如S2I）進行類似rox-image-scan和rox-image-check的操作，如果不能通過這兩項檢查，則自動拒絕應用容器化。除了參與到DevSecOps Pipeline中，StackRox更為強大的功能體現(xiàn)在對容器云運行狀態(tài)的安全掃描。