譯者 | 涂承燁

審校 | 孫淑娟

保護(hù)容器化云原生應(yīng)用程序威脅的要點(diǎn)

引言：隨著容器應(yīng)用的指數(shù)級(jí)增長，對(duì)于團(tuán)隊(duì)來說，確保適當(dāng)?shù)陌踩屯{管理基礎(chǔ)設(shè)施和實(shí)踐變得比以往任何時(shí)候都重要。本Refcard對(duì)容器化環(huán)境的威脅檢測進(jìn)行了全面的研究，跨越了幾個(gè)重點(diǎn)領(lǐng)域，如常見的云安全架構(gòu)和Kubernetes加固指南。Refcard的核心是容器威脅檢測的基礎(chǔ)，包括資源限制、靜態(tài)圖像漏洞掃描、配置驗(yàn)證等概念。

1 簡介

如今，容器化解決方案已成為云原生應(yīng)用程序開發(fā)的事實(shí)標(biāo)準(zhǔn)。Docker、containerd、CRI-O和Kubernetes等工具在容器操作系統(tǒng)領(lǐng)域處于領(lǐng)先地位。數(shù)以百萬計(jì)的開發(fā)和架構(gòu)團(tuán)隊(duì)選擇基于容器的解決方案來幫助構(gòu)建他們的產(chǎn)品，杰出的云提供商提供了大量基于Kubernetes、Docker和其他容器編排平臺(tái)的服務(wù)。

?隨著容器采用的增加，安全和威脅管理比以往任何時(shí)候都更加關(guān)鍵。根據(jù)??云原生計(jì)算基金會(huì)(CNCF)??和國家安全局(NSA)/CISA指南：

• 發(fā)現(xiàn)大多數(shù)安全問題和威脅是因?yàn)??56%的開發(fā)人員目前甚至沒有掃描他們的容器！???
• 高德納公司（Gartner）預(yù)計(jì)，到2023年，??超過70%的公司將運(yùn)行容器化應(yīng)用程序。??
• ??紅帽公司（Red Hat）2022年的一份報(bào)告顯示??，至少59%的Kubernetes安全問題與錯(cuò)誤配置有關(guān)。

本Refcard將討論容器化環(huán)境的關(guān)鍵安全和威脅檢?測主題，包括：

• 介紹Docker、containerd和CRI-O等知名的容器編排平臺(tái)及其相應(yīng)的安全挑戰(zhàn)
• 云原生安全性和合規(guī)性標(biāo)準(zhǔn)概述
• 威脅檢測工具選擇標(biāo)準(zhǔn)簡介
• 容器威脅檢測的要點(diǎn)，包括OWASP和Kubernetes安全指南
• 基于Azure、AWS和谷歌云的安全云架構(gòu)示例

2 云原生安全方法概述

容器的云原生安全表現(xiàn)為四層安全邊界（也稱為4Cs）。這四層由代碼、容器、集群和云組成。請(qǐng)參閱下面圖1所示的4Cs。

圖1:云原生安全的4Cs（云、集群、容器、代碼）

代碼

如圖1所示，代碼是最里面的一層，因?yàn)椴粌H要在代碼中加強(qiáng)安全性，而且還要在云、集群和容器層中加強(qiáng)安全性。然而，代碼不應(yīng)該包含漏洞的后門，例如：

• 所有通信都應(yīng)該通過TLS或mTLS進(jìn)行
• 掃描依賴項(xiàng)并為代碼提供靜態(tài)分析
• 限制對(duì)所有常見端口的訪問

容器

容器及其容器環(huán)境是云原生安全解決方案的基本組成部分。現(xiàn)在，應(yīng)用程序不僅基于Docker，還基于containerd，CRI-O和其他類似的平臺(tái)。有幾種常見的安全規(guī)則可以應(yīng)用于容器平臺(tái)：

• 掃描容器的漏洞，并使用安全掃描工具
• 使用最小特權(quán)原則
• 容器運(yùn)行時(shí)隔離用戶
• 禁用root權(quán)限
• 引入資源限制

集群

容器編排器對(duì)安全性至關(guān)重要，因?yàn)樗鼈児芾硭袘?yīng)用程序容器和服務(wù)。Kubernetes是一個(gè)廣泛使用的容器編制平臺(tái)，它的漏洞受到一長串安全準(zhǔn)則的約束，具體如下：

• ?RBAC和身份驗(yàn)證策略
• ??應(yīng)用程序機(jī)密（Secrets）管理??
• ??網(wǎng)絡(luò)策略??
• ??TLS接入??
• ??Pod安全標(biāo)準(zhǔn)??

云和基礎(chǔ)設(shè)施

所有知名的云提供商都有安全指南和資源來保護(hù)應(yīng)用程序集群。例如，Azure擁有強(qiáng)大的平臺(tái)，如??Sentinel??和??Defender For Cloud??，它們?yōu)榛A(chǔ)設(shè)施內(nèi)的威脅檢測提供邏輯。AWS的安全中心（Security Hub）是一種云安全管理服務(wù)，為AWS中的資源提供自動(dòng)化安全驗(yàn)證。所有安全驗(yàn)證和檢查都基于??AWS基礎(chǔ)安全最佳實(shí)踐標(biāo)準(zhǔn)??。

最后，谷歌云將安全威脅檢測作為安全指揮中心的一部分。安全指揮中心是一個(gè)集中式的漏洞和威脅報(bào)告服務(wù)。它不僅包含威脅檢測，還包含漏洞掃描選項(xiàng)。

圖2：谷歌云安全命令中心

此外，開源和第三方云安全工具是可以考慮的強(qiáng)大選項(xiàng)，特別是在處理多云或混合云環(huán)境時(shí)。除了云安全，還要關(guān)注基礎(chǔ)設(shè)施。如果使用Kubernetes，那么需要關(guān)注這些關(guān)鍵方面，比如：

• 訪問Kube控制面板、節(jié)點(diǎn)或公共網(wǎng)絡(luò)，特別是集群網(wǎng)絡(luò)
• 為您的Kubernetes云提供商設(shè)置權(quán)限策略
• 采用??最小特權(quán)原則??
• 限制對(duì)etcd集群的訪問，并通過TLS提供加密

當(dāng)我們?cè)谙乱还?jié)中了解云和基礎(chǔ)設(shè)施安全時(shí)，會(huì)介紹更多的內(nèi)容。

3 常用云安全架構(gòu)

云基礎(chǔ)設(shè)施是云原生應(yīng)用程序的基本組成部分。在本節(jié)中，讓我們探索一些提供全棧安全和威脅檢測選項(xiàng)的主要云提供商。

AWS安全中心

??AWS安全中心??（AWS Security Hub）?是一個(gè)安全服務(wù)，它包含聚合、優(yōu)先級(jí)排序和管理來自不同AWS服務(wù)的警報(bào)的選項(xiàng)。AWS安全中心可用于：

• Amazon S3桶
• 包含敏感數(shù)據(jù)的S3桶
• Amazon機(jī)器鏡像(AMIs)
• AWS服務(wù)帳戶
• Amazon EC2實(shí)例

此外，AWS安全中心通過自動(dòng)化遙測修復(fù)和自定義操作(如電子郵件、短信甚至票務(wù)系統(tǒng))來幫助實(shí)現(xiàn)自動(dòng)化。AWS的最大優(yōu)勢(shì)是其對(duì)AWS區(qū)域內(nèi)所有AWS賬戶的統(tǒng)一視圖。

讓我們通過AWS安全中心的檢測系統(tǒng)來了解一個(gè)簡單的AWS體系結(jié)構(gòu)：

圖3：AWS安全中心檢測系統(tǒng)

上面的體系結(jié)構(gòu)展示了AWS Security Hub（AWS安全中心）與Cloud Watch的集成。Cloud Watch規(guī)則觸發(fā)事件，然后與Lambda函數(shù)集成。因此，一個(gè)特定的函數(shù)將處理AWS安全中心的事件。

AWS安全中心的創(chuàng)建和配置可以通過以下Terraform模塊輕松實(shí)現(xiàn)自動(dòng)化：

module "security_hub" {
    source        = "clouddrove/security-hub/aws"
    version       = "1.0.1"
    name          = "security-hub"
    security_hub_enabled = true

    #member account add
    enable_member_account = true
    member_account_id     = "123344847783"
    member_mail_id        = "example@mail.com"

    #standards 
    enabled_standards = [
    "standards/aws-foundational-security-best-practices/v/1.0.0",
    "ruleset/cis-aws-foundations-benchmark/v/1.2.0"
    ]
    #products
    enabled_products = [
    "product/aws/guardduty",
    "product/aws/inspector",
    "product/aws/macie"
    ]
    }

通過此模塊，開發(fā)人員可以配置他們的成員帳戶，實(shí)現(xiàn)規(guī)則集（如AWS - foundations -security-best-practices），并啟用AWS產(chǎn)品。

用于容器的Azure Defender

??用于容器的Azure Defender ??是一個(gè)復(fù)雜的云原生安全服務(wù)。它包含容器監(jiān)視、容器注冊(cè)指導(dǎo)服務(wù)和AKS集群安全工具集。Azure Defender包含AKS安全加固功能。它允許將Defender代理直接設(shè)置到工作節(jié)點(diǎn)和控制面板，以便可以運(yùn)行安全和威脅檢測。

Azure Defender有一個(gè)關(guān)于威脅和安全漏洞的大型數(shù)據(jù)庫。因此，Azure Defender將UI儀表板集成到Azure Portal中。在儀表板中，可以監(jiān)視集群安全問題并糾正安全檢查。要查看它，請(qǐng)?jiān)L問??Azure Defender文檔。??

當(dāng)使用Azure Defender保護(hù)容器時(shí)，需使用代理的自動(dòng)配置功能。為此，請(qǐng)?jiān)?/span>??自動(dòng)配置窗口??中啟用日志分析和漏洞評(píng)估擴(kuò)展。

參考下面圖4中Azure Defender的云部署架構(gòu)。它通過基于??eBPF??技術(shù)的Defender配置文件進(jìn)行部署。

圖4：用于AKS集群的Azure Defender

該架構(gòu)包括以下組件：

• DeamonSet（azuredefender-collector-ds-*, azuredefender-publisher-ds-*）是一組容器，用于收集集群環(huán)境的安全事件和遙測信息
• 部署（azuredefender-publisher-ds-*）應(yīng)用程序，將收集到的數(shù)據(jù)發(fā)布到Defender的后端

使用Bicep模板為容器部署Defender：

targetScope = 'subscription'

var enableSecurityCenterFor = [
  'KubernetesService'
]

resource securityCenterPricing 'Microsoft.Security/pricings@2018-06-01' = [for name in enableSecurityCenterFor: {
  name: name
  properties: {
    pricingTier: 'Standard'
  }
}]

如上所示，Defender仍然被命名為安全中心。該模板非常簡單，包含enableSecurityCenterFor部分。此部分包含將為其啟用Defender的服務(wù)和securityCenterPricing部分。本節(jié)是Defender資源定義。

谷歌云AppArmor

最后但并非最不重要的是??AppArmor??-一個(gè)基于Linux內(nèi)核安全性的安全模塊。它基于安全配置文件限制在操作系統(tǒng)中運(yùn)行的進(jìn)程。通過安全配置文件，可以限制網(wǎng)絡(luò)通信和活動(dòng)、文件和存儲(chǔ)。

對(duì)于Docker容器，可以使用默認(rèn)的安全配置文件，并使用以下命令運(yùn)行默認(rèn)的Docker配置文件：

docker run --rm -it debian:jessie bash -i

發(fā)生讀取時(shí)，這段代碼將會(huì)限制對(duì)/proc/sysrq-trigger的訪問。

使用下面的示例代碼創(chuàng)建自己的安全配置文件：

cat > /etc/apparmor.d/no_raw_net <<EOF
#include <tunables/global>

profile no-ping flags=(attach_disconnected,mediate_deleted) {
  #include <abstractions/base>

  network inet tcp,
  network inet udp,
  network inet icmp, 

  deny network raw,
  deny network packet,
  file,
  mount,
}
EOF

此代碼塊限制對(duì)原始網(wǎng)絡(luò)和分組網(wǎng)絡(luò)的訪問，但允許訪問tcp、udp和icmp協(xié)議。

了解Azure、AWS和谷歌云提供的服務(wù)和功能很重要，因?yàn)樗鼈冊(cè)试S我們構(gòu)建高效、安全的容器化架構(gòu)。

4 關(guān)于容器安全和威脅檢測

所有的容器引擎都基于容器運(yùn)行時(shí)引擎(CREs)。Docker是使用最廣泛的CREs之一。然而，就安全性和Kubernetes-ready解決方案而言，Docker可能并不總是一個(gè)好的選擇。還有其他選擇，如容器或CRI-O。讓我們快速看看這些選項(xiàng)。

容器（Containerd）

由于Docker是一個(gè)集成的工具，包含CLI、存儲(chǔ)管理、復(fù)雜的網(wǎng)絡(luò)、權(quán)限邏輯等，這些工具為Kubernetes中的漏洞攻擊創(chuàng)造了巨大的開銷和攻擊面?？紤]到這些問題，Docker將容器運(yùn)行時(shí)提取到一個(gè)名為??containerd??的獨(dú)立項(xiàng)目中。Containerd比Docker小得多，提供了用于管理圖像傳輸邏輯的低級(jí)存儲(chǔ)。containerd是CNCF的一部分。

CRI-O

??CRI- O??比containerd更深入，提供原生和輕量級(jí)的CRI。CRI-O不包含運(yùn)行在Kubernetes中的任何額外的層。Kubelet直接與CRI-O運(yùn)行時(shí)對(duì)話，以提取圖像。請(qǐng)參見下面圖5中的Docker層、容器層和CRI-O層：

圖5：Docker層、容器層和CRI-O層

Docker、容器和CRI-O的安全方面

當(dāng)涉及Docker、容器和CRI-O時(shí)，許多針對(duì)容器化環(huán)境的攻擊和威脅都是基于相同的場景。例如：

• 提高CPU、RAM和磁盤使用率以攻擊相鄰容器
• 使用容器的root權(quán)限來公開主機(jī)網(wǎng)絡(luò)，從而應(yīng)用特權(quán)標(biāo)志
• 在鏡像或Kubernetes配置中硬編碼機(jī)密（Secrets）
• ??Linux內(nèi)核漏洞??
• 使用惡意或虛假的鏡像，包含所謂的中間人攻擊

由于Docker是具有多層的整體架構(gòu)，因此容易受到上述所有場景的影響。例如：

•  ??CVE-2020-8554??-此漏洞允許攻擊者通過創(chuàng)建ClusterIPs服務(wù)來訪問集群。
• ??Siloscape??-Windows容器中的惡意軟件。Silocape為整個(gè)Kubernetes集群創(chuàng)建了一個(gè)后門，包括敏感數(shù)據(jù)和CPU、GPU、存儲(chǔ)資源。
• ??CVE-2018-15664??-以root權(quán)限訪問Docker系統(tǒng)。

容器（Containerd）是一個(gè)更輕量級(jí)引擎。它不包含來自Docker的很多層。但是，它具有諸如audit_write、mknod、net_raw和sys_chroot等Linux特性。容器（Containerd）為主機(jī)網(wǎng)絡(luò)容器提供了一個(gè)通往攻擊面的后門，如??中毒鏡像??或??容器逃逸??。

CRI-O不包含Docker這樣的層，因?yàn)殚_發(fā)團(tuán)隊(duì)排除了所有不必要的提供了后門的Linux特性。然而，CRI-O也包含一些可能導(dǎo)致cgroup??內(nèi)存不足（OOM）??情況的漏洞，這將導(dǎo)致容器和??鏡像沒有TLS連接??。

記住：威脅可以在??CVE報(bào)告??中查看。

5 容器威脅檢測的要點(diǎn)

團(tuán)隊(duì)可以通過以下核心概念減輕或完全消除威脅和安全漏洞。

Docker網(wǎng)絡(luò)

Docker的網(wǎng)絡(luò)是Docker基礎(chǔ)設(shè)施的一個(gè)復(fù)雜部分，了解它是如何工作的至關(guān)重要。了解??Docker網(wǎng)絡(luò)驅(qū)動(dòng)程序??是什么很重要，例如：

• ??網(wǎng)橋（Bridge）??
• ??主機(jī)（Host）??
• ??覆蓋網(wǎng)絡(luò)/疊加網(wǎng)絡(luò)（Overlay）??（譯者注：overlay(又叫疊加網(wǎng)絡(luò)、覆蓋網(wǎng)絡(luò))簡單理解就是把一個(gè)邏輯網(wǎng)絡(luò)建立在一個(gè)實(shí)體網(wǎng)絡(luò)之上。其在大體框架上對(duì)基礎(chǔ)網(wǎng)絡(luò)不進(jìn)行大規(guī)模修改就能實(shí)現(xiàn)應(yīng)用在網(wǎng)絡(luò)上的承載，并能與其他網(wǎng)絡(luò)業(yè)務(wù)分離，通過控制協(xié)議對(duì)邊緣的網(wǎng)絡(luò)設(shè)備進(jìn)行網(wǎng)絡(luò)構(gòu)建和擴(kuò)展是SD-WAN以及數(shù)據(jù)中心等解決方案使用的核心組網(wǎng)技術(shù)。）

默認(rèn)情況下，一個(gè)容器網(wǎng)絡(luò)棧不能訪問另一個(gè)容器。但是，如果將網(wǎng)橋或主機(jī)配置為接受來自任何其他容器或外部網(wǎng)絡(luò)的流量，則可能為攻擊創(chuàng)建一個(gè)潛在的安全后門。你也可以在??Docker Daemon??中使用set flag - icc=false來禁用容器間通信。

設(shè)定資源限制

為Docker容器設(shè)置??內(nèi)存和CPU限制??非常重要，因?yàn)镈ocker是一個(gè)默認(rèn)情況下不提供此選項(xiàng)的容器。這是一種防止DoS攻擊的有效方法。例如，可以設(shè)置內(nèi)存限制，以防止容器消耗所有內(nèi)存。這同樣適用于CPU限制。此外，還有一個(gè)選項(xiàng)可以在Kubernetes級(jí)別上設(shè)置資源限制-這將在下面的Kubernetes加固指南一節(jié)中詳細(xì)介紹。

避免容器鏡像中的敏感數(shù)據(jù)

這一原則對(duì)于將所有敏感數(shù)據(jù)移出容器非常重要。你可以使用不同的選項(xiàng)來管理你的機(jī)密信息和其他敏感數(shù)據(jù)：

• ??Docker secrets??允許你在鏡像外部存儲(chǔ)機(jī)密。
• 如果你在Kubernetes中運(yùn)行Docker容器，請(qǐng)使用??機(jī)密（Secrets）??存儲(chǔ)您的密碼、證書或任何其他敏感數(shù)據(jù)。
• 對(duì)敏感數(shù)據(jù)使用特定于云的存儲(chǔ)-例如，??Azure密鑰庫??或??AWS機(jī)密管理器??。

漏洞和威脅檢測工具

漏洞掃描工具是檢測可能包含安全缺陷的鏡像的重要組成部分。此外,你也可以適當(dāng)選擇工具集成到CI / CD的過程。第三方供應(yīng)商和一些常見的開源工具提供了這種功能。這些開源工具的一些例子可以在“關(guān)于容器安全和威脅檢測”一節(jié)中找到。

容器注冊(cè)

為了保護(hù)鏡像，創(chuàng)建一個(gè)額外的安全層，并使用來自受保護(hù)的注冊(cè)表的鏡像。下面是一些開源注冊(cè)平臺(tái)的例子：

??Harbor??-一個(gè)具有集成漏洞掃描功能的開源注冊(cè)表，它基于應(yīng)用于Docker構(gòu)件的安全策略上。

??Quay ??-一個(gè)掃描鏡像漏洞的開源鏡像注冊(cè)表。在RedHat的支持下，Quay還提供了一個(gè)獨(dú)立的鏡像存儲(chǔ)庫，允許你在組織內(nèi)部安裝和使用它。下面，我們將深入研究它如何掃描容器中的漏洞。

最小特權(quán)原則

這個(gè)原則意味著你不應(yīng)該使用管理員（admin）用戶來操作容器。相反，你應(yīng)該創(chuàng)建具有管理員權(quán)限且只能操作此特定容器的用戶。群組那里還可以再添加用戶。請(qǐng)閱讀??Docker引擎安全文檔??。下面是如何創(chuàng)建用戶和組的示例：

RUN groupadd -r postgres && useradd --no-log-init -r -g postgres postgres
USER postgres

此外，在創(chuàng)建用戶和組的同時(shí)，請(qǐng)確保使用官方驗(yàn)證和簽名的鏡像。要查找和檢查鏡像，使用Docker信任檢查。請(qǐng)?jiān)谙旅娴摹叭萜鞯耐{檢測工具選擇標(biāo)準(zhǔn)”一節(jié)中查找更多選項(xiàng)和工具。

Linux安全模塊

為了加強(qiáng)安全性，請(qǐng)使用默認(rèn)的Linux安全配置文件，不要禁用默認(rèn)配置文件。對(duì)于Docker，你可以使用??AppArmor??或??Seccomp??。Kubernetes中的安全上下文規(guī)則也可以用allowPrivilegeEscalation來設(shè)置，該選項(xiàng)擁有控制容器的權(quán)限。此外，readOnlyRootFilesystem標(biāo)志將容器根文件系統(tǒng)設(shè)置為只讀模式。

靜態(tài)鏡像漏洞掃描

現(xiàn)在，我們已經(jīng)知道了威脅檢測工具是如何協(xié)同工作的，以及我們可以使用的策略，讓我們定義一下靜態(tài)圖像漏洞掃描、機(jī)密掃描和配置驗(yàn)證的含義。靜態(tài)安全漏洞掃描基于OCI (??Open Container Initiative??)格式。它根據(jù)眾所周知的威脅和漏洞信息源對(duì)鏡像進(jìn)行驗(yàn)證和索引，如??CVE Tracker??、??Red Hat安全數(shù)據(jù)??和??Debian安全漏洞跟蹤器??。

靜態(tài)安全漏洞掃描機(jī)制可用于掃描多個(gè)源，如：

• 容器的鏡像
• 文件系統(tǒng)和存儲(chǔ)
• Kubernetes集群

靜態(tài)鏡像漏洞掃描還可以掃描錯(cuò)誤配置、機(jī)密、軟件依賴關(guān)系，并生成軟件材料清單(??Software Bill of Materials??, SBOM)。SBOM是應(yīng)用程序中開源、第三方工具和組件的組合，其中包含所有組件的許可信息。該信息對(duì)于快速識(shí)別安全風(fēng)險(xiǎn)非常重要。

下面，我們列出了一系列開源工具，涵蓋了上面解釋的邏輯。這只是可以使用的眾多工具中的一小部分：

• ??Clair ??-一個(gè)安全漏洞掃描工具，具有用于開發(fā)集成目的的API。它還可以創(chuàng)建您自己的divers來擴(kuò)展和定制Clair功能。Clair有幾個(gè)??Indexer??、??match??、??notify??或combo模型。
•  ??Trivy ??-基于CVE威脅數(shù)據(jù)庫的安全容器掃描程序。Trivy可以安裝在你的PC上或Kubernetes節(jié)點(diǎn)上，使用npm, apt-get, brew和其他包管理器，比如：

1. apt-get install trivy  
2. yum install trivy
3. brew install aquasecurity/trivy/trivy

使用如下命令掃描圖像：

$ trivy image app-backend:1.9-test

靜態(tài)圖像漏洞掃描的另一個(gè)關(guān)鍵是安全內(nèi)容自動(dòng)化協(xié)議(SCAP)。SCAP為基于Linux的基礎(chǔ)設(shè)施定義安全合規(guī)性檢查。??OpenSCAP??是一種工具，包括復(fù)雜的安全審計(jì)選項(xiàng)。它允許您掃描、編輯和導(dǎo)出??SCAP文檔??，包括以下組件和工具：

• OpenSCAP Base -用于漏洞和配置掃描
• oscap-docker-用于合規(guī)掃描
• SCAP工作臺(tái)-一個(gè)圖形實(shí)用工具，用于典型的OpenSCAP任務(wù)的執(zhí)行

下面是一個(gè)關(guān)于如何運(yùn)行SCAP內(nèi)容驗(yàn)證過程的示例：

oscap ds sds-validate scap-ds.xml

配置驗(yàn)證

靜態(tài)鏡像驗(yàn)證是威脅檢測過程中的重要組成部分。然而，靜態(tài)鏡像掃描無法檢測到Y(jié)AML和JSON配置中的錯(cuò)誤配置，并且可能導(dǎo)致復(fù)雜YAML配置中的中斷。因此，要實(shí)現(xiàn)一種簡單且自動(dòng)化的方法，就需要像Kubeval這樣的配置驗(yàn)證和掃描工具。我們可以引入配置驗(yàn)證，它可以解決靜態(tài)配置的問題并簡化自動(dòng)化過程。

作為一個(gè)例子，我們將合并??Kubeval??，這是一個(gè)用于驗(yàn)證一個(gè)或多個(gè)Kubernetes配置文件的開源工具，經(jīng)常在本地作為開發(fā)工作流的一部分和/或在CI/CD管道中使用。

運(yùn)行驗(yàn)證，請(qǐng)使用下面的例子：

$ kubeval my-invalid-rc.yaml
WARN - fixtures/my-invalid-rc.yaml contains an invalid ReplicationController - spec.replicas: Invalid type. Expected: [integer,null], given: string
$ echo $?
1

機(jī)密（Secrets）掃描

機(jī)密（Secrets）掃描的主要目標(biāo)是查看容器鏡像、作為代碼的基礎(chǔ)設(shè)施文件、JSON日志文件等，以獲得硬編碼的和默認(rèn)的秘密、密碼、AWS訪問id、AWS秘密訪問密鑰、谷歌OAuth密鑰、SSH密鑰、令牌等。

管理控制臺(tái)和傳感器代理

管理控制臺(tái)是一種UI工具，用于構(gòu)建安全基礎(chǔ)設(shè)施概述，并提供漏洞和威脅報(bào)告。另一方面，傳感器代理是一種掃描集群節(jié)點(diǎn)并收集安全遙測數(shù)據(jù)的工具。因此，傳感器代理向管理控制臺(tái)報(bào)告遙測。

例如，在AKS集群中安裝傳感器代理，需要遵循以下原則：

helm repo add deepfence https://deepfence-helm-charts.s3.amazonaws.com/threatmapper
helm show readme deepfence/deepfence-agent
helm show values deepfence/deepfence-agent

# helm v2
helm install deepfence/deepfence-agent \
    --name=deepfence-agent \
    --set managementConsoleUrl=x.x.x.x \
 --set deepfenceKey=C8TtyEtNB0gBo1wGhpeAZICNSAaGWw71BSdS2kLELY0

例如，在AKS集群中安裝傳感器代理，需要遵循以下原則：

helm repo add deepfence

??https://deepfence-helm-charts.s3.amazonaws.com/threatmapper??

helm install deepfence-console deepfence/deepfence-console

完成安裝需兩個(gè)操作：

• 從https://deepfence-helm-charts.s3.amazonaws.com/threatmapper下載Helm包
• 將Helm包直接安裝到集群名稱空間

這兩個(gè)命令都非常簡單，可以很容易地集成到IaC進(jìn)程中。

6 Kubernetes加固指南

因?yàn)镵ubernetes是最流行的編排平臺(tái)，它需要經(jīng)常進(jìn)行安全調(diào)整。因此，美國國家安全局制定了??K8加固指南??。讓我們根據(jù)國家安全局的強(qiáng)化指南來探索最常見的安全規(guī)則。

組網(wǎng)與網(wǎng)絡(luò)策略

理解Kubernetes網(wǎng)絡(luò)模型是如何工作的，對(duì)于在pods之間設(shè)置正確的網(wǎng)絡(luò)通信，假裝創(chuàng)建開放端口或直接訪問節(jié)點(diǎn)至關(guān)重要。??網(wǎng)絡(luò)策略??可以幫助組織這種通信。

確保Pod的進(jìn)出流量

在保護(hù)Pod的入口和出口流量時(shí)，拒絕所有流量，然后逐個(gè)打開端口是很有幫助的。使用像Istio這樣的服務(wù)網(wǎng)格（service mesh）也很有幫助，因?yàn)樗砑恿祟~外的服務(wù)層，自動(dòng)化流量，并有助于監(jiān)控。然而，在使用服務(wù)網(wǎng)格（Service Mesh）時(shí)要小心，因?yàn)樗赡軙?huì)增加更多的復(fù)雜性。

強(qiáng)認(rèn)證和授權(quán)策略

• 加強(qiáng)傳輸層安全-傳輸層安全(TLS)應(yīng)該用于Kubernetes集群服務(wù)之間的通信。
• 采用??RBAC??和最小特權(quán)原則。
• 限制對(duì)Kubelet的訪問-啟用使用該工具的身份驗(yàn)證和授權(quán)；只有管理員才能訪問Kubelet。

使用日志審計(jì)

啟用Kubernetes??控制面板審計(jì)??，以便向安全團(tuán)隊(duì)提供完整的信息。通常，這可以通過將日志轉(zhuǎn)發(fā)到監(jiān)視平臺(tái)來實(shí)現(xiàn)。

驗(yàn)證和檢查錯(cuò)誤配置

要檢查錯(cuò)誤配置，可以采用自動(dòng)化方法和配置掃描工具。可用CNCF項(xiàng)目??Open Policy Agent??創(chuàng)建安全策略，以防止創(chuàng)建錯(cuò)誤配置。

例如，拒絕運(yùn)行帶有最新標(biāo)簽的容器：

package K ubernetes

import data.kubernetes
import data.lib as l

check03 := “K8S_03”

exception[rules] {
  make_exception(check03)
  rules = [“usage_of_latest_tag”]
}

deny_usage_of_latest_tag[msg] {
   ubernetes.containers[container]
  [image_name, “l(fā)atest”] =  ubernetes.split_image(container.image)
  msg =  ubern(“%s: %s in the %s %s has an image, %s, using the latest tag. More info: %s”, [check03, container.name,  ubernetes.kind, image_name,  ubernetes.name, l.get_url(check03)])
}

更多的策略示例可以在??Open Policy Agent policies??中找到。

入侵檢測系統(tǒng)與安全信息系統(tǒng)的實(shí)現(xiàn)

入侵檢測系統(tǒng)是Kubernetes安全系統(tǒng)的重要組成部分。這些系統(tǒng)檢查主機(jī)的行為是否有可疑活動(dòng)和/或異常流量，并向管理員發(fā)出警報(bào)。

7 容器威脅檢測工具選擇標(biāo)準(zhǔn)

工具和平臺(tái)是威脅檢測基礎(chǔ)的基本組成部分。有許多原生云提供商和開源工具包含威脅檢測選項(xiàng)，包括以下服務(wù)：

• 靜態(tài)鏡像漏洞掃描
• 配置驗(yàn)證
• 機(jī)密（Secrets）掃描

問題是如何為你的架構(gòu)選擇合適的安全工具。讓我們回顧一下選擇合適的威脅檢測工具的一些要求和策略：

讓我們看一下下面的本地混合場景示例，在該場景中，我們使用開源工具和服務(wù)的組合構(gòu)建模型架構(gòu)。

威脅檢測架構(gòu)示例

作為使用開源安全工具的一個(gè)例子，我們將從Kubernetes集群開始。可以使用云提供商（或內(nèi)部環(huán)境）進(jìn)行部署。我們的示例架構(gòu)包含以下開源平臺(tái)：

??Cadvisor??-用于檢測漏洞。

??Grafana??-通過導(dǎo)入所有組件來構(gòu)建和配置儀表板和警報(bào)。

Prometheus-一個(gè)功能強(qiáng)大的開源選項(xiàng)，用于監(jiān)控CPU、GPU、內(nèi)存、圖像和其他指標(biāo)。

??Kube-bench??-檢測Kubernetes集群的威脅和安全問題。它的安全檢查基于CIS Kubernetes基準(zhǔn)。

圖6：威脅檢測架構(gòu)示例

要配置kube-bench，請(qǐng)使用YAML文件。例如,下面列出的YAML文件。它用于針對(duì)單個(gè)pod運(yùn)行驗(yàn)證過程：

---
apiVersion: batch/v1
kind: Job
metadata:
  name: kube-bench
spec:
  template:
    metadata:
      labels:
        app: kube-bench
    spec:
      hostPID: true
      containers:
        - name: kube-bench
          image: docker.io/aquasec/kube-bench:v0.6.8
          command: ["kube-bench"]
          volumeMounts:
            - name: var-lib-etcd
              mountPath: /var/lib/etcd
              readOnly: true
            - name: var-lib-kubelet
              mountPath: /var/lib/kubelet
              readOnly: true
            - name: var-lib-kube-scheduler
              mountPath: /var/lib/kube-scheduler
              readOnly: true
            - name: usr-bin
              mountPath: /usr/local/mount-from-host/bin
              readOnly: true
            - name: etc-cni-netd
              mountPath: /etc/cni/net.d/
              readOnly: true
            - name: opt-cni-bin
              mountPath: /opt/cni/bin/
              readOnly: true
…
      restartPolicy: Never
      volumes:
        - name: var-lib-etcd
          hostPath:
            path: "/var/lib/etcd"
        - name: var-lib-kubelet
          hostPath:
            path: "/var/lib/kubelet"
…

讓我們將這個(gè)文檔內(nèi)容保存到文件job.ymal中，然后使用apply命令運(yùn)行：$ kubectl apply -f job.yaml

??你可以在這里找到完整的版本。??

8 結(jié)論

在本Refcard中，我們介紹了容器化云原生應(yīng)用程序的威脅和漏洞檢測機(jī)制的完整指南。從云原生環(huán)境的安全基線到Kubernetes的加固指南，這個(gè)Refcard提供了開始為云原生應(yīng)用程序構(gòu)建安全容器化架構(gòu)所需的一切。

譯者介紹

涂承燁，51CTO社區(qū)編輯，信息系統(tǒng)項(xiàng)目管理師、信息系統(tǒng)監(jiān)理師、PMP，某省綜合性評(píng)標(biāo)專家，擁有15年的開發(fā)經(jīng)驗(yàn)。對(duì)項(xiàng)目管理、前后端開發(fā)、微服務(wù)、架構(gòu)設(shè)計(jì)、物聯(lián)網(wǎng)、大數(shù)據(jù)等較為關(guān)注。

原文標(biāo)題：??Essentials to Securing Threats for Containerized Cloud-Native Applications??，作者：Boris Zaikin