譯者 | 涂承燁

審校 | 孫淑娟

保護容器化云原生應用程序威脅的要點

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

1 簡介

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

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

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

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

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

2 云原生安全方法概述

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

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

代碼

如圖1所示，代碼是最里面的一層，因為不僅要在代碼中加強安全性，而且還要在云、集群和容器層中加強安全性。然而，代碼不應該包含漏洞的后門，例如：

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

容器

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

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

集群

容器編排器對安全性至關重要，因為它們管理所有應用程序容器和服務。Kubernetes是一個廣泛使用的容器編制平臺，它的漏洞受到一長串安全準則的約束，具體如下：

• ?RBAC和身份驗證策略
• ??應用程序機密（Secrets）管理??
• ??網(wǎng)絡策略??
• ??TLS接入??
• ??Pod安全標準??

云和基礎設施

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

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

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

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

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

當我們在下一節(jié)中了解云和基礎設施安全時，會介紹更多的內(nèi)容。

3 常用云安全架構

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

AWS安全中心

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

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

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

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

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

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

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

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ā)人員可以配置他們的成員帳戶，實現(xiàn)規(guī)則集（如AWS - foundations -security-best-practices），并啟用AWS產(chǎn)品。

用于容器的Azure Defender

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

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

當使用Azure Defender保護容器時，需使用代理的自動配置功能。為此，請在??自動配置窗口??中啟用日志分析和漏洞評估擴展。

參考下面圖4中Azure Defender的云部署架構。它通過基于??eBPF??技術的Defender配置文件進行部署。

圖4：用于AKS集群的Azure Defender

該架構包括以下組件：

• DeamonSet（azuredefender-collector-ds-*, azuredefender-publisher-ds-*）是一組容器，用于收集集群環(huán)境的安全事件和遙測信息
• 部署（azuredefender-publisher-ds-*）應用程序，將收集到的數(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的服務和securityCenterPricing部分。本節(jié)是Defender資源定義。

谷歌云AppArmor

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

對于Docker容器，可以使用默認的安全配置文件，并使用以下命令運行默認的Docker配置文件：

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

發(fā)生讀取時，這段代碼將會限制對/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

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

了解Azure、AWS和谷歌云提供的服務和功能很重要，因為它們允許我們構建高效、安全的容器化架構。

4 關于容器安全和威脅檢測

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

容器（Containerd）

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

CRI-O

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

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

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

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

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

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

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

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

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

記住：威脅可以在??CVE報告??中查看。

5 容器威脅檢測的要點

團隊可以通過以下核心概念減輕或完全消除威脅和安全漏洞。

Docker網(wǎng)絡

Docker的網(wǎng)絡是Docker基礎設施的一個復雜部分，了解它是如何工作的至關重要。了解??Docker網(wǎng)絡驅動程序??是什么很重要，例如：

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

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

設定資源限制

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

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

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

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

漏洞和威脅檢測工具

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

容器注冊

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

??Harbor??-一個具有集成漏洞掃描功能的開源注冊表，它基于應用于Docker構件的安全策略上。

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

最小特權原則

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

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

此外，在創(chuàng)建用戶和組的同時，請確保使用官方驗證和簽名的鏡像。要查找和檢查鏡像，使用Docker信任檢查。請在下面的“容器的威脅檢測工具選擇標準”一節(jié)中查找更多選項和工具。

Linux安全模塊

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

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

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

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

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

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

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

• ??Clair ??-一個安全漏洞掃描工具，具有用于開發(fā)集成目的的API。它還可以創(chuàng)建您自己的divers來擴展和定制Clair功能。Clair有幾個??Indexer??、??match??、??notify??或combo模型。
•  ??Trivy ??-基于CVE威脅數(shù)據(jù)庫的安全容器掃描程序。Trivy可以安裝在你的PC上或Kubernetes節(jié)點上，使用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)圖像漏洞掃描的另一個關鍵是安全內(nèi)容自動化協(xié)議(SCAP)。SCAP為基于Linux的基礎設施定義安全合規(guī)性檢查。??OpenSCAP??是一種工具，包括復雜的安全審計選項。它允許您掃描、編輯和導出??SCAP文檔??，包括以下組件和工具：

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

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

oscap ds sds-validate scap-ds.xml

配置驗證

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

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

運行驗證，請使用下面的例子：

$ 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

機密（Secrets）掃描

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

管理控制臺和傳感器代理

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

例如，在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

完成安裝需兩個操作：

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

這兩個命令都非常簡單，可以很容易地集成到IaC進程中。

6 Kubernetes加固指南

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

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

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

確保Pod的進出流量

在保護Pod的入口和出口流量時，拒絕所有流量，然后逐個打開端口是很有幫助的。使用像Istio這樣的服務網(wǎng)格（service mesh）也很有幫助，因為它添加了額外的服務層，自動化流量，并有助于監(jiān)控。然而，在使用服務網(wǎng)格（Service Mesh）時要小心，因為它可能會增加更多的復雜性。

強認證和授權策略

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

使用日志審計

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

驗證和檢查錯誤配置

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

例如，拒絕運行帶有最新標簽的容器：

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)的實現(xiàn)

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

7 容器威脅檢測工具選擇標準

工具和平臺是威脅檢測基礎的基本組成部分。有許多原生云提供商和開源工具包含威脅檢測選項，包括以下服務：

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

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

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

威脅檢測架構示例

作為使用開源安全工具的一個例子，我們將從Kubernetes集群開始?？梢允褂迷铺峁┥蹋ɑ騼?nèi)部環(huán)境）進行部署。我們的示例架構包含以下開源平臺：

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

??Grafana??-通過導入所有組件來構建和配置儀表板和警報。

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

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

圖6：威脅檢測架構示例

要配置kube-bench，請使用YAML文件。例如,下面列出的YAML文件。它用于針對單個pod運行驗證過程：

---
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"
…

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

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

8 結論

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

譯者介紹

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

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