作者 |  徐可甲(燁陌) 

云原生架構(gòu)新風(fēng)險(xiǎn)與需求概述

安全風(fēng)險(xiǎn)概述

傳統(tǒng)的網(wǎng)絡(luò)安全架構(gòu)理念是基于邊界的安全架構(gòu)，企業(yè)構(gòu)建網(wǎng)絡(luò)安全體系時(shí)，首先要做的是尋找安全邊界，把網(wǎng)絡(luò)劃分為外網(wǎng)、內(nèi)網(wǎng)等不同的區(qū)域，然后在邊界上部署防火墻、入侵檢測(cè)、WAF等產(chǎn)品。然而這種網(wǎng)絡(luò)安全架構(gòu)是基于內(nèi)網(wǎng)比外網(wǎng)更安全的假設(shè)建立起來，在某種程度上預(yù)設(shè)了對(duì)內(nèi)網(wǎng)中的人、設(shè)備和系統(tǒng)的信任，忽視加強(qiáng)內(nèi)網(wǎng)安全措施。不法分子一旦突破企業(yè)的邊界安全防護(hù)進(jìn)入內(nèi)網(wǎng)，會(huì)像進(jìn)入無人之境，將帶來嚴(yán)重的后果。此外，內(nèi)部人員100%安全的假說也是不成立的，我們可以從《內(nèi)部威脅成本全球報(bào)告》里看到，不管是內(nèi)部威脅的數(shù)量，還是威脅成本都是呈顯著上升的趨勢(shì)。

隨著云計(jì)算、大數(shù)據(jù)、物聯(lián)網(wǎng)、移動(dòng)辦公等新技術(shù)與業(yè)務(wù)的深度融合，網(wǎng)絡(luò)安全邊界也逐漸變得更加模糊，傳統(tǒng)邊界安全防護(hù)理念面臨巨大挑戰(zhàn)。以辦公網(wǎng)絡(luò)安全為例，已經(jīng)逐步從僅支持公司內(nèi)部網(wǎng)絡(luò)設(shè)備連接，發(fā)展到使用辦公電腦通過VPN遠(yuǎn)程連接，甚至移動(dòng)辦公的到來，使得個(gè)人手機(jī)等個(gè)人設(shè)備接入變成了可能。在這樣的背景下，零信任架構(gòu)（Zero Trust Architecture, ZTA）應(yīng)運(yùn)而生。它打破傳統(tǒng)的認(rèn)證，即信任邊界防護(hù)、靜態(tài)訪問控制、以網(wǎng)絡(luò)為中心等防護(hù)思路，建立起一套以身份為中心，以持續(xù)認(rèn)證、動(dòng)態(tài)訪問控制、審計(jì)以及監(jiān)測(cè)為鏈條，以最小化實(shí)時(shí)授權(quán)為核心，以多維信任算法為基礎(chǔ)，認(rèn)證達(dá)末端的動(dòng)態(tài)安全架構(gòu)。

我們知道Kubernetes在容器編排市場(chǎng)中占據(jù)了主導(dǎo)地位，用戶基數(shù)呈逐年上升的趨勢(shì)。K8s提供了強(qiáng)大的運(yùn)維部署、彈性伸縮、故障恢復(fù)能力，極大地便利了分布式系統(tǒng)的開發(fā)和管理，但是隨之而來的安全問題卻也比較突出。

根據(jù)《容器和Kubernetes安全態(tài)勢(shì)報(bào)告》報(bào)告，針對(duì)云原生應(yīng)用的威脅已越來越多，僅有6%的人沒有經(jīng)歷過與容器或K8s相關(guān)的安全事件。同時(shí)，還指出近70%的安全風(fēng)險(xiǎn)都是由人為錯(cuò)誤配置而引發(fā)的，此外運(yùn)行時(shí)安全及重大安全漏洞引發(fā)的安全事件也是重要的因素?！吨袊圃脩粽{(diào)查報(bào)告》同樣也支持，容器安全問題成為用戶應(yīng)用的最大擔(dān)憂。63%的用戶認(rèn)為容器安全是緊迫的需求，大量用戶反饋網(wǎng)絡(luò)安全技術(shù)實(shí)施難度復(fù)雜度高，且監(jiān)控系統(tǒng)、日志系統(tǒng)不完善，很難進(jìn)行有效的安全監(jiān)控。

從上述的報(bào)告可以看出，K8s安全問題會(huì)分布在整個(gè)生命周期的各個(gè)階段。一些常見的安全風(fēng)險(xiǎn)表現(xiàn)為：容器鏡像漏洞或?yàn)E用鏡像倉庫導(dǎo)致的漏洞；容器大量部署導(dǎo)致很難發(fā)覺安全問題；K8s核心組件漏洞威脅，多個(gè)高危漏洞爆出；集群配置不當(dāng)，甚至一些默認(rèn)配置有安全隱患；沒有明確網(wǎng)絡(luò)邊界，網(wǎng)絡(luò)隔離性問題；攻擊面變大、監(jiān)控和防護(hù)難度大。因此，我們迫切需要建立一個(gè)全方位的安全體系，覆蓋整個(gè)容器生命周期的各個(gè)階段。

• 構(gòu)建時(shí)：基于安全的鏡像倉庫、權(quán)限最小化的安全鏡像構(gòu)建業(yè)務(wù)系統(tǒng)，及時(shí)修復(fù)已知漏洞。
• 部署時(shí)：按照K8s最佳實(shí)踐部署，修復(fù)錯(cuò)誤配置。
• 運(yùn)行時(shí)：持續(xù)監(jiān)控安全威脅，并及時(shí)做出相應(yīng)。

K8s安全體系

上圖為阿里云容器服務(wù)Kubernetes版給出的安全體系，可以看出構(gòu)建完善的安全體系從下到上需要覆蓋基礎(chǔ)架構(gòu)安全、可信軟件供應(yīng)鏈、運(yùn)行時(shí)安全三個(gè)維度。

• 基礎(chǔ)架構(gòu)安全：基于CIS kubernetes benchmark指導(dǎo)安全部署；依賴K8s的安全體系，建立細(xì)粒度的訪問控制機(jī)制。
• 可信軟件供應(yīng)鏈：通過鏡像掃描發(fā)現(xiàn)已知安全漏洞；通過鏡像簽名保障鏡像來源的安全性及不被篡改；通過DevSecOps集成，實(shí)現(xiàn)安全左移，與開發(fā)、測(cè)試、運(yùn)維等質(zhì)量動(dòng)作進(jìn)行深度融合。
• 運(yùn)行時(shí)安全：通過PodSecurityPolicy針對(duì)容器部署時(shí)進(jìn)行安全校驗(yàn)，有效約束應(yīng)用運(yùn)行時(shí)的行為安全；應(yīng)用運(yùn)行時(shí)的安全配置巡檢；持續(xù)的無處不在的運(yùn)行時(shí)安全監(jiān)控機(jī)制和異常事件告警通知機(jī)制，保證安全事件的及時(shí)發(fā)現(xiàn)及解決；選用安全沙箱，提供更強(qiáng)的隔離環(huán)境。

我們發(fā)現(xiàn)上述安全體系可以跟零信任策略的“從不信任、始終驗(yàn)證”的思想相呼應(yīng)的。

K8s信任邊界

為了更好的理解K8s系統(tǒng)的安全風(fēng)險(xiǎn)，接下來我們從K8s內(nèi)外部網(wǎng)絡(luò)邊界的角度展開分析。其中，紅色曲線部分可以被視為獨(dú)立邊界的子系統(tǒng)。

• 容器鏡像：主要涉及到的安全攻擊點(diǎn)就是鏡像倉庫和鏡像本身。其中，使用了不受信任的鏡像倉庫或被篡改的容器鏡像會(huì)導(dǎo)致惡意代碼被執(zhí)行。
• K8s控制平面：涉及K8s 的 API Server、scheduler 和 controller-manager核心組件等。其中API Server為K8s系統(tǒng)管控入口，是重點(diǎn)的攻擊對(duì)象。另外，核心組件之間調(diào)用鏈的安全也同樣重要。
• K8s數(shù)據(jù)平面：涉及Ingress Controller跟Service，Ingress作為內(nèi)部服務(wù)對(duì)外暴露的端口，被攻擊風(fēng)險(xiǎn)較大。
• 節(jié)點(diǎn)上運(yùn)行時(shí)安全：涉及kubelet、kube-proxy 和容器運(yùn)行時(shí)環(huán)境，需要避免運(yùn)行時(shí)容器越權(quán)或容器逃逸等風(fēng)險(xiǎn)。

K8s安全攻擊來源眾多，既可能是來自外部的控制平面攻擊，也可能是來自外部流量的數(shù)據(jù)面攻擊，甚至可能是來自內(nèi)部成員的惡意攻擊或者誤操作等。因此，K8s攻擊面特別廣，防護(hù)難度大，為了更好的保護(hù)K8s安全運(yùn)行，需要建議起一套策略防護(hù)跟監(jiān)控防護(hù)相結(jié)合的防護(hù)體系。本文重點(diǎn)將圍繞監(jiān)控防護(hù)展開，逐層遞進(jìn)地介紹如何在復(fù)雜的分布式容器化環(huán)境中借助可觀測(cè)性平臺(tái)，持續(xù)監(jiān)控K8s集群，及時(shí)發(fā)現(xiàn)異常的 API 訪問事件、異常流量、異常配置、異常日志等行為，并且結(jié)合合理的告警策略建立更主動(dòng)的安全防御體系。

K8s場(chǎng)景下安全數(shù)據(jù)采集技術(shù)方案

安全數(shù)據(jù)是作為K8s安全監(jiān)控的根本，如果沒有數(shù)據(jù)那就是“巧婦難為無米之炊”，任何高級(jí)的監(jiān)控策略都無從談起。因此，首先我們將會(huì)介紹K8s相關(guān)的安全數(shù)據(jù)源及相關(guān)的采集技術(shù)。

安全數(shù)據(jù)源

K8s審計(jì)日志

在 Kubernetes 中，Api Server是K8s集群資源變更、查詢的入口，所有對(duì)集群狀態(tài)的查詢和修改都是通過向 Api Server 發(fā)送請(qǐng)求，對(duì) Api Server 的請(qǐng)求來源可以分為4類：

• 控制面組件，例如 Scheduler，各種 Controller，Api Server 自身。
• 節(jié)點(diǎn)上的各種 Agent，例如 Kubelet、Kube-proxy 等。
• 集群的其它服務(wù)，例如 Coredns、Ingress-controller、各種第三方的 Operator 等。
• 外部用戶，例如運(yùn)維人員通過 Kubectl。

Kubernetes 審計(jì)日志是 Api Server 產(chǎn)生的結(jié)構(gòu)化日志，記錄了對(duì) Api Server 的訪問操作（包括時(shí)間、來源、操作結(jié)果、發(fā)起操作的用戶、操作的資源以及請(qǐng)求/響應(yīng)的詳細(xì)信息等）。通過審計(jì)日志，可以追溯對(duì)集群狀態(tài)的變更；了解集群的運(yùn)行狀況；排查異常；發(fā)現(xiàn)集群潛在的安全、性能風(fēng)險(xiǎn)等等。包括不限于如下行為：

• 當(dāng)前/歷史上集群發(fā)生了哪些變更事件。
• 這些變更操作者是誰，是系統(tǒng)組件還是用戶，是哪個(gè)系統(tǒng)組件/用戶。
• 重要變更事件的詳細(xì)內(nèi)容是什么，比如修改了POD中的哪個(gè)參數(shù)。
• 事件的結(jié)果是什么，成功還是失敗。
• 操作用戶來自哪里，集群內(nèi)還是集群外。

Kubernetes Event

事件（Event）主要是用來記錄K8s集群內(nèi)發(fā)生的狀態(tài)變更，大到集群節(jié)點(diǎn)異常，小到 Pod 啟動(dòng)、調(diào)度成功等。事件詳細(xì)記錄了集群狀態(tài)變更發(fā)生的時(shí)間、組件、等級(jí)（Normal、Warning、Error）、類型、詳細(xì)信息，通過事件能夠知道應(yīng)用的部署、調(diào)度、運(yùn)行、停止等整個(gè)生命周期，也能通過事件去了解系統(tǒng)中正在發(fā)生的一些異常。K8s事件存儲(chǔ)在etcd中，默認(rèn)情況下只保存1個(gè)小時(shí)，由于etcd并不支持一些復(fù)雜的分析操作，只提供了非常簡(jiǎn)單的過濾方式，比如通過Reason、時(shí)間、類型等。同時(shí)這些事件只是被動(dòng)的存在etcd中，并不支持主動(dòng)推送到其他系統(tǒng)，通常只能手動(dòng)的去查看。而實(shí)際上我們對(duì)事件的使用需求非常高，比較典型的場(chǎng)景如下：

• 對(duì)系統(tǒng)中的異常事件做實(shí)時(shí)告警，例如Failed、Evicted、FailedMount、FailedScheduling等。
• 通常問題排查可能要去查找歷史數(shù)據(jù)，因此需要去查詢更長(zhǎng)時(shí)間范圍的事件（幾天甚至幾個(gè)月）。
• 事件支持歸類統(tǒng)計(jì)，例如能夠計(jì)算事件發(fā)生的趨勢(shì)以及與上一時(shí)間段（昨天/上周/發(fā)布前）對(duì)比，以便基于統(tǒng)計(jì)指標(biāo)進(jìn)行判斷和決策。
• 支持不同的人員按照各種維度去做過濾、篩選。

支持自定義的訂閱這些事件去做自定義的監(jiān)控，以便和公司內(nèi)部的部署運(yùn)維平臺(tái)集成。

默認(rèn)情況下，Kubernetes事件只關(guān)注容器管理相關(guān)的問題，對(duì)于硬件、操作系統(tǒng)、容器運(yùn)行時(shí)、依賴系統(tǒng)（網(wǎng)絡(luò)、存儲(chǔ)等）并不會(huì)提供更多的檢測(cè)能力。NPD（node-problem-detector）作為Kubernetes節(jié)點(diǎn)診斷的工具，可以將節(jié)點(diǎn)的異常轉(zhuǎn)換為Node的事件，并推送到APIServer中，交由APIServer進(jìn)行事件的統(tǒng)一管理。NPD支持多種異常檢查，例如：

• 基礎(chǔ)服務(wù)問題：NTP服務(wù)未啟動(dòng)。
• 硬件問題：CPU、內(nèi)存、磁盤、網(wǎng)卡損壞Kernel問題：Kernel hang，文件系統(tǒng)損壞。
• 容器運(yùn)行時(shí)問題：Docker hang，Docker無法啟動(dòng)。

之后，可以借助開源事件工具kube-eventer，將集群的事件離線到釘釘、SLS、Kafka等系統(tǒng)，并提供不同等級(jí)的過濾條件，實(shí)現(xiàn)事件的實(shí)時(shí)采集、定向告警、異步歸檔。

Ingress

K8s中Ingress只是一種API資源的聲明，具體的實(shí)現(xiàn)需要安裝對(duì)應(yīng)的Ingress Controller，由Ingress Controller接管Ingress定義，將流量轉(zhuǎn)發(fā)到對(duì)應(yīng)的Service。目前Ingress Controller有非常多種實(shí)現(xiàn)，常用的的是Nginx Ingress Controller。

日志和監(jiān)控是所有Ingress Controller都會(huì)提供的基礎(chǔ)功能，日志一般包括訪問日志（Access Log）、控制日志（Controller Log）和錯(cuò)誤日志（Error Log），監(jiān)控主要從日志以及Controller中提取部分Metric信息。這些數(shù)據(jù)中訪問日志的量級(jí)最大、信息最多、價(jià)值也最高，一般7層的訪問日志包括：URL、源IP、UserAgent、狀態(tài)碼、入流量、出流量、響應(yīng)時(shí)間等，對(duì)于Ingress Controller這種轉(zhuǎn)發(fā)型的日志，還包括轉(zhuǎn)發(fā)的Service名、Service響應(yīng)時(shí)間等額外信息。從這些信息中，我們能夠分析出非常多的信息，例如：

• 網(wǎng)站訪問的PV、UV；
• 訪問的地域分布、設(shè)備端分布；
• 網(wǎng)站訪問的錯(cuò)誤比例；
• 后端服務(wù)的響應(yīng)延遲；
• 不同URL訪問分布。

K8s配置安全

CIS Kubernetes Benchmark是CIS推出的一系列用于構(gòu)建一個(gè)安全可靠的Kubernetes集群的安全配置建議，K8s使用者可以基于這些規(guī)范構(gòu)建安全的K8s集群。但是人工一個(gè)個(gè)去比對(duì)安全配置規(guī)則的建議顯然是不合適的，一般會(huì)結(jié)合一些巡檢工具進(jìn)行。

security-inspector是一款針對(duì)K8s Workload配置進(jìn)行多維度掃描工具，可以在巡檢報(bào)告中查看巡檢掃描結(jié)果，包括健康檢查、鏡像、網(wǎng)絡(luò)、資源、安全等掃描信息。此外，kube-bench、kube-hunter等其他開源項(xiàng)目也是可選用的CIS規(guī)則巡檢方案。

K8s運(yùn)行時(shí)安全

Falco是一款云原生運(yùn)行時(shí)安全開源項(xiàng)目，用于監(jiān)控Kubernetes上應(yīng)用的運(yùn)行時(shí)異?；顒?dòng)。Falco在內(nèi)核態(tài)通過監(jiān)控文件更改、網(wǎng)絡(luò)活動(dòng)、進(jìn)程表和其他數(shù)據(jù)是否存在可疑行為，并可以通過可插拔后端發(fā)送警報(bào)。通過 Falco 可輕松檢測(cè)以下異常：

• 容器內(nèi)運(yùn)行的 Shell
• 服務(wù)器進(jìn)程產(chǎn)生意外類型的子進(jìn)程
• 敏感文件讀取（如 /etc/shadow）
• 非設(shè)備文件寫入至 /dev
• 系統(tǒng)的標(biāo)準(zhǔn)二進(jìn)制文件（如 ls）產(chǎn)生出站流量

K8s安全數(shù)據(jù)源特點(diǎn)

以上我們列舉了一些K8s安全監(jiān)控場(chǎng)景下常見的數(shù)據(jù)源，而且每種日志特點(diǎn)各異。我們可以發(fā)現(xiàn)安全類數(shù)據(jù)種類繁多，來源眾多，格式也不統(tǒng)一?？偨Y(jié)下來具有如下特點(diǎn)：

• 安全數(shù)據(jù)類型包含了日志、指標(biāo)、事件。
• 安全數(shù)據(jù)可能是來自文件，也有可能來自標(biāo)準(zhǔn)輸出或者標(biāo)準(zhǔn)錯(cuò)誤，甚至可能是Syslog等標(biāo)準(zhǔn)協(xié)議。
• 安全文本數(shù)據(jù)可能會(huì)存在于容器內(nèi)的文件或者宿主機(jī)上的文件。
• Ingress訪問日志等涉及數(shù)據(jù)面流量的日志往往會(huì)數(shù)據(jù)量極大。
• 審計(jì)日志作為集群安全審計(jì)的必備日志，重要性極高，需要長(zhǎng)時(shí)間跨度存儲(chǔ)（等保2.0要求至少需要存180天），并且不能有采集的丟失。

為了更全面的采集安全數(shù)據(jù)，需要具備一個(gè)性能強(qiáng)大、生態(tài)支持全面、K8s原生支持的安全數(shù)據(jù)采集器。該采集器需要具備以下能力：

• 容器運(yùn)行時(shí)支持的全面性，可以支持Docker、Containerd等運(yùn)行時(shí)。
• K8s提供了強(qiáng)大的動(dòng)態(tài)擴(kuò)縮容能力，但也同時(shí)給數(shù)據(jù)采集帶了困難。因此，采集器需要適應(yīng)容器動(dòng)態(tài)的特點(diǎn)。
• 有些安全數(shù)據(jù)是通過Job觸發(fā)的，該類任務(wù)具有生命周期短的特點(diǎn)，采集器需要提供短生命周期容器的采集能力。
• 所采集需要具備關(guān)聯(lián)K8s上下文的能力，為后續(xù)分析提供便捷。
• 強(qiáng)大的數(shù)據(jù)處理能力，可以在不影響性能的前提下完成安全數(shù)據(jù)的處理需求，為后續(xù)分析場(chǎng)景打下基礎(chǔ)。
• K8s云上托管服務(wù)越來越流行，需要能夠支持云上服務(wù)的采集場(chǎng)景。

K8s采集技術(shù)

阿里云SLS開源的可觀測(cè)數(shù)據(jù)采集器iLogtail，可以完全滿足上述安全數(shù)據(jù)的特點(diǎn)及場(chǎng)景要求，并且經(jīng)過阿里雙十一、公有云等眾多復(fù)雜場(chǎng)景考驗(yàn)，在安全數(shù)據(jù)采集領(lǐng)域也是一個(gè)很好的選擇。接下來，我們重點(diǎn)介紹下iLogtail的技術(shù)特點(diǎn)及K8s下的采集原理。

可觀測(cè)數(shù)據(jù)采集器iLogtail

iLogtail的核心定位是可觀測(cè)數(shù)據(jù)的采集器，幫助開發(fā)者構(gòu)建統(tǒng)一的數(shù)據(jù)采集層，助力可觀測(cè)平臺(tái)打造各種上層的應(yīng)用場(chǎng)景。2022年6月底，阿里云iLogtail代碼完整開源，正式發(fā)布了完整功能的iLogtail社區(qū)版。

iLogtail核心優(yōu)勢(shì)

輕量級(jí)、高性能

• iLogtail主體部分通過C++，插件部分Golang實(shí)現(xiàn)，不管內(nèi)存還是CPU具有天然的性能優(yōu)勢(shì)。
• iLogtail也持續(xù)針對(duì)性的做了很多特定場(chǎng)景的優(yōu)化，比如針對(duì)日志的極簡(jiǎn)、Json、正則模式采集提供了C++加速能力，極大提升了日志采集效率，單核采集流量最高能到百M(fèi)/s。

超強(qiáng)可靠性

• iLogtail作為阿里集團(tuán)內(nèi)重要的可觀測(cè)數(shù)據(jù)采集基礎(chǔ)設(shè)施，多年來一直穩(wěn)定支持雙11等大促場(chǎng)景，在應(yīng)對(duì)網(wǎng)絡(luò)擁塞、流量洪峰、進(jìn)程重啟等方面表現(xiàn)突出。
• 公有云上iLogtail也持續(xù)支持著各行各業(yè)的客戶，眾多復(fù)雜業(yè)務(wù)場(chǎng)景對(duì)于iLogtail的可靠性提供了足夠的場(chǎng)景支持。

毫秒級(jí)延時(shí)

• iLogtail實(shí)現(xiàn)如此高吞吐的秘訣之一是使用了無鎖化事件處理模型。與業(yè)界其他開源Agent為每個(gè)配置分配獨(dú)立線程/Goroutine讀取數(shù)據(jù)不同，iLogtail數(shù)據(jù)的讀取只配置了一個(gè)線程。由于數(shù)據(jù)讀取的瓶頸并不在于計(jì)算而是磁盤，單線程足以完成所有配置的事件處理以及數(shù)據(jù)讀取。使用單線程使得iLogtail的事件處理和數(shù)據(jù)讀取都可以在無鎖環(huán)境下運(yùn)行，數(shù)據(jù)結(jié)構(gòu)更加輕量化，從而取得了相對(duì)多線程處理更優(yōu)的性價(jià)比。
• 文件采集基于inotify與polling相結(jié)合的發(fā)現(xiàn)機(jī)制，既借助了inotify的低延遲與低性能消耗的特點(diǎn)，也通過polling的方式兼顧了運(yùn)行環(huán)境的全面性。

云原生支持

• iLogtail提供了業(yè)務(wù)容器實(shí)時(shí)動(dòng)態(tài)發(fā)現(xiàn)能力，并支持通過K8s元信息（例如Label、環(huán)境變量等）進(jìn)行采集過濾。特別是一些短Job場(chǎng)景，比如一些機(jī)器學(xué)習(xí)的訓(xùn)練任務(wù)，生命周期只有幾分鐘甚至幾十秒，也提供了全面的友好的支持。
• 部署模式上，也支持DaemonsSet、Sidecar等多種模式。
• 為了更原生的K8s支持，也提供了Operator機(jī)制，用戶可以通過CRD的方式進(jìn)行采集配置管理。

插件化擴(kuò)展能力

上下游生態(tài)：通過插件系統(tǒng)的擴(kuò)展，目前iLogtail已經(jīng)支持了眾多數(shù)據(jù)源的接入，數(shù)據(jù)源類型覆蓋Log、Metric、Trace，數(shù)據(jù)源除了文件的采集，還包括了標(biāo)準(zhǔn)協(xié)議的支持，例如HTTP、Mysql Binlog、Prometheus、Skywalking、syslog等。數(shù)據(jù)輸出生態(tài)也從SLS逐步擴(kuò)展到Kafka、gPRC等，未來也會(huì)支持ClickHouse、ElasticSearch等。

處理能力擴(kuò)展：iLogtail采用PipeLine的設(shè)計(jì)，通過Input插件采集到數(shù)據(jù)，會(huì)經(jīng)過采集配置中設(shè)定的Processor處理，之后經(jīng)過Aggregator插件打包，最終通過Flusher發(fā)送到日志存儲(chǔ)系統(tǒng)。數(shù)據(jù)處理環(huán)境包含數(shù)據(jù)切分、字段提取、過濾、數(shù)據(jù)增強(qiáng)等環(huán)節(jié)，所有插件可以自由組合。此外，針對(duì)于正則、Json、分隔符等特定格式，iLogtail還提供了C++加速能力。

快速迭代：開發(fā)者也可以根據(jù)自己的需求，定制開發(fā)相應(yīng)的插件。因?yàn)槊總€(gè)插件相互獨(dú)立，所以開發(fā)者只需要按照接口規(guī)范開發(fā)即可，入手門檻較低。

多租戶隔離

• iLogtail采用基于時(shí)間片的采集調(diào)度、多級(jí)高低水位反饋隊(duì)列、事件非阻塞處理、流控/停采策略以及配置動(dòng)態(tài)更新等多項(xiàng)關(guān)鍵技術(shù)，融合實(shí)現(xiàn)了兼具隔離性、公平性、可靠性、可控性、性價(jià)比五大特性的多租戶隔離方案。

iLogtail部署模式

作為容器編排領(lǐng)域的標(biāo)準(zhǔn)，Kubernetes（K8s）應(yīng)用的場(chǎng)景越來越廣泛，iLogtail 在K8s下也提供了完備的采集能力。在K8s場(chǎng)景下，iLogtail主要常用的有3種工作模式：

• DaemonSet方式：在K8s的每個(gè)node上部署一個(gè)iLogtail，由該iLogtail采集節(jié)點(diǎn)上所有容器的日志到日志系統(tǒng)。此方式特點(diǎn)是運(yùn)維簡(jiǎn)單、資源占用少、支持采集容器的標(biāo)準(zhǔn)輸出和文本文件、配置方式靈活，但是在超大集群存在一定的性能瓶頸。

• Sidecar方式：一個(gè)POD中伴隨業(yè)務(wù)容器運(yùn)行一個(gè)iLogtail容器，用于采集該P(yáng)OD中業(yè)務(wù)容器產(chǎn)生的日志。此方式特點(diǎn)是多租戶隔離性好、性能好，但是資源占用較多。
• Deployment方式：當(dāng)業(yè)務(wù)容器用PVC掛載日志目錄或者需要全局連接API Server獲取K8s元數(shù)據(jù)等場(chǎng)景，可以選擇在集群中部署一個(gè)單副本的iLogtail Deployment進(jìn)行數(shù)據(jù)采集。

iLogtail采集原理

自K8s問世以來，Docker運(yùn)行時(shí)一直是主流，但是隨著K8s將dockershim移除，K8s官方推薦優(yōu)先選擇Containerd 或 CRI-O作為容器運(yùn)行時(shí)。Docker份額目前雖然還是主流但是已經(jīng)在呈逐年下降的趨勢(shì)，Containerd、CRI-O地位逐年都在快速上升。因此，從K8s支持全面性上，iLogtail需要支持主流的運(yùn)行時(shí)，目前已經(jīng)支持Docker和Containerd兩種容器引擎的數(shù)據(jù)采集。

K8s提供了強(qiáng)大的運(yùn)維部署、彈性伸縮、故障恢復(fù)能力，極大地便利了分布式系統(tǒng)的開發(fā)和管理，然而這也帶來了可觀測(cè)數(shù)據(jù)采集難度的增大。特別是一些短Job場(chǎng)景，比如一些機(jī)器學(xué)習(xí)的訓(xùn)練任務(wù)，生命周期只有幾分鐘甚至幾秒，如何快速準(zhǔn)確地發(fā)現(xiàn)所需要采集的容器至關(guān)重要。iLogtail在K8s場(chǎng)景下的采集分為如下幾個(gè)步驟：

• 容器自動(dòng)發(fā)現(xiàn)與釋放：iLogtail通過訪問位于宿主機(jī)上容器運(yùn)行時(shí)（Docker Engine/ContainerD）的sock獲取容器信息，并通過監(jiān)聽Docker Event及增量獲取機(jī)制，及時(shí)感知容器新增與釋放。
• 容器上下文信息獲?。喊ㄈ萜鲗蛹?jí)信息，例如容器名、ID、掛載點(diǎn)、環(huán)境變量、Label；以及K8s層級(jí)信息，例如Pod、命名空間、Labels。
• 容器過濾及隔離性：基于容器上下文信息，提供采集容器過濾能力，可以將不同采集配置應(yīng)用到不同的采集容器上，既可以保證采集的隔離性，也可以減少不必要的資源浪費(fèi)。
• 元信息關(guān)聯(lián)：基于容器上下文信息和容器環(huán)境變量，提供在日志中富化K8s元信息的能力。
• 采集路徑發(fā)現(xiàn)：根據(jù)容器元信息自動(dòng)識(shí)別不同運(yùn)行時(shí)的標(biāo)準(zhǔn)輸出格式和日志路徑；對(duì)于overlay、overlay2的存儲(chǔ)驅(qū)動(dòng)，可以根據(jù)日志類型及容器運(yùn)行時(shí)自動(dòng)拼接出采集路徑，簡(jiǎn)單高效。

此外，對(duì)于CICD自動(dòng)化部署和運(yùn)維程度要求較高的用戶，iLogtail還提供了K8s原生支持，支持通過CRD的方式進(jìn)行采集配置管理。目前該功能僅企業(yè)版可用，后續(xù)會(huì)逐步開源。該方案中，iLogtail K8s新增了一個(gè)CustomResourceDefinition擴(kuò)展，名為AliyunLogConfig。同時(shí)開發(fā)了alibaba-log-controller用于監(jiān)聽AliyunLogConfig事件并自動(dòng)創(chuàng)建iLogtail的采集配置，進(jìn)而完成日志采集工作。

安全數(shù)據(jù)監(jiān)測(cè)與響應(yīng)最佳實(shí)踐

統(tǒng)一存儲(chǔ)分析引擎

安全數(shù)據(jù)監(jiān)控一個(gè)重要的能力就是對(duì)采集到的數(shù)據(jù)，進(jìn)行實(shí)時(shí)的合規(guī)監(jiān)控分析，支持對(duì)歷史數(shù)據(jù)的合規(guī)審計(jì)，對(duì)來自外部的威脅和內(nèi)部的違規(guī)進(jìn)行審計(jì)分析。實(shí)際安全分析場(chǎng)景往往會(huì)面臨眾多困難：

• 安全威脅往往是一個(gè)逐步的過程，可能需要幾個(gè)月或更長(zhǎng)的時(shí)間才會(huì)真正暴露出來。因此，需要提供低成本的存儲(chǔ)能力，及強(qiáng)大的長(zhǎng)時(shí)間跨度數(shù)據(jù)分析能力。
• 安全數(shù)據(jù)來源眾多，格式不統(tǒng)一，日志、時(shí)序數(shù)據(jù)都可能涉及。有些安全威脅隱蔽性較強(qiáng)，需要多種數(shù)據(jù)的聯(lián)動(dòng)分析才能發(fā)現(xiàn)。因此，需要具備強(qiáng)大的關(guān)聯(lián)分析能力。

為此，我們?cè)O(shè)計(jì)了一套統(tǒng)一的可觀測(cè)數(shù)據(jù)存儲(chǔ)分析引擎。將日志、指標(biāo)、Meta等數(shù)據(jù)全部接入到統(tǒng)一的存儲(chǔ)中，在一些等保場(chǎng)景可以通過開啟智能冷熱分層存儲(chǔ)，降低不活躍數(shù)據(jù)的存儲(chǔ)成本。之后，我們構(gòu)建了一套統(tǒng)一的查詢分析引擎，該引擎以SQL為基礎(chǔ)，擴(kuò)展了關(guān)鍵詞查詢、PromQL語法能力及機(jī)器學(xué)習(xí)算子能力，可方便支撐查詢分析、可視化、監(jiān)控告警、AI 等上層應(yīng)用場(chǎng)景。同時(shí)，SQL作為頂層語言，可以起到串聯(lián)日志、時(shí)序、ML模型、CMDB、外部DB的能力，使得大規(guī)模多數(shù)據(jù)關(guān)聯(lián)分析成為可能。

可以認(rèn)為，SLS SQL = Search + SQL92（Agg，WIndow，GroupBy...）+ PromQL + ...以下就是一個(gè)比較典型的分析的例子：

• 我們可以通過標(biāo)準(zhǔn) SQL 語句對(duì)日志進(jìn)行分析。
• 還可以通過 PromQL 擴(kuò)展的 SQL 函數(shù)對(duì)指標(biāo)數(shù)據(jù)進(jìn)行分析。
• 還可以通過嵌套查詢，對(duì)指標(biāo)數(shù)據(jù)的分析結(jié)果進(jìn)行再聚合。
• 此外還可以再通過機(jī)器學(xué)習(xí)函數(shù)，給查詢和分析賦予 AI 的能力。

雖然不同階段的數(shù)據(jù)產(chǎn)生自不同的系統(tǒng)，也有著不同的格式，但是由于它們的存儲(chǔ)和分析是一致的，我們可以非常輕松地實(shí)現(xiàn)統(tǒng)一的安全態(tài)勢(shì)及安全事件監(jiān)控。

智能巡檢

Ingress訪問日志產(chǎn)生量極大，而且日積月累后會(huì)造成大量數(shù)據(jù)存儲(chǔ)，會(huì)造成存儲(chǔ)成本的急劇上升，并且在長(zhǎng)時(shí)間跨度查詢分析場(chǎng)景下也會(huì)效率極低。為了達(dá)到高性能、低成本、快速、智能等要求，我們對(duì)Ingress這種超大數(shù)據(jù)量的方案進(jìn)行了架構(gòu)升級(jí)。

• 原始訪問日志存儲(chǔ)：當(dāng)Ingress Controller產(chǎn)生訪問請(qǐng)求后，會(huì)實(shí)時(shí)將請(qǐng)求的訪問日志推送到用戶自身的日志庫中，SLS的Logstore具備高可靠、實(shí)時(shí)索引、自動(dòng)擴(kuò)容等功能，保證日志的可靠性和可擴(kuò)展性。
• 預(yù)聚和：由于原始訪問日志量巨大，基于原始日志計(jì)算指標(biāo)性能開銷較大，因此我們專門推出了基于訪問日志的指標(biāo)預(yù)聚和能力，能夠?qū)⑸习偃f甚至上億的訪問日志實(shí)時(shí)聚合成指標(biāo)類型的時(shí)序數(shù)據(jù)，數(shù)據(jù)量會(huì)降低1-2個(gè)數(shù)量級(jí)，后續(xù)的分析與監(jiān)控可直接基于時(shí)序數(shù)據(jù)進(jìn)行，大大提高效率。
• 智能巡檢：對(duì)于預(yù)聚和后的Metrics（指標(biāo)數(shù)據(jù)），我們提供了基于機(jī)器學(xué)習(xí)的智能巡檢功能，幫助用戶自動(dòng)去檢測(cè)Ingress的各個(gè)維度的指標(biāo)異常，將異常信息實(shí)時(shí)展現(xiàn)在時(shí)序的圖表中，結(jié)合實(shí)時(shí)告警能力及時(shí)通知給用戶解決。此外后續(xù)還會(huì)支持異常打標(biāo)，基于用戶反饋的信息進(jìn)行更加精確的檢測(cè)。

通過以上3層數(shù)據(jù)鏈路，實(shí)現(xiàn)了從原始訪問日志到預(yù)聚和的指標(biāo)最后再到機(jī)器學(xué)習(xí)的異常事件整個(gè)數(shù)據(jù)的流轉(zhuǎn)，對(duì)于用戶來說，告警和監(jiān)控只需要基于指標(biāo)和智能巡檢的結(jié)果進(jìn)行，而涉及到具體服務(wù)的問題分析可以再回到原始的訪問日志并基于統(tǒng)一查詢分析引擎進(jìn)行自定義的排查和分析。

• 成本高、查詢效率低：對(duì)于日志量極大場(chǎng)景，特別如果再加上長(zhǎng)時(shí)間跨度的因素，會(huì)造成存儲(chǔ)成本的急劇上升，查詢效率往往也很低。
• 效率低：對(duì)于異?，F(xiàn)場(chǎng)的定位，需要人工配置各種各樣的規(guī)則去進(jìn)行異常的捕獲。
• 時(shí)效差：大部分時(shí)序數(shù)據(jù)具有時(shí)效性特征。故障、變更都會(huì)引起對(duì)應(yīng)指標(biāo)形態(tài)的變化，前一種規(guī)則條件下的異?？赡茉谙乱粫r(shí)刻是正常狀態(tài)。
• 配置難：時(shí)序數(shù)據(jù)形態(tài)各異。有突刺變化、折點(diǎn)變化、周期變化等諸多形態(tài)，閾值范圍也各有不同。對(duì)于復(fù)雜形態(tài)下的異常，規(guī)則往往難以配置。
• 效果差：數(shù)據(jù)流不斷動(dòng)態(tài)變化，業(yè)務(wù)形態(tài)日新月異，固定的規(guī)則方法很難在新的業(yè)態(tài)下起作用，從而產(chǎn)生大量的誤報(bào)或者漏報(bào)。對(duì)于異常的程度，不同場(chǎng)景，不同用戶，對(duì)其容忍的程度不同。在排查問題中，有效異常點(diǎn)捕捉的越多，有助于具體問題的排查；而在告警通知中，高危異常點(diǎn)越少，越有助于提升告警處理的效率。

針對(duì)以上問題，我們推出智能巡檢功能，通過自研的人工智能算法，對(duì)指標(biāo)、日志等流數(shù)據(jù)進(jìn)行一站式整合、巡檢與告警。使用智能巡檢功能后，只需要組織一下具體的監(jiān)控項(xiàng)，算法模型就會(huì)自動(dòng)完成異常檢測(cè)、業(yè)態(tài)自適應(yīng)、告警精細(xì)。

安全態(tài)勢(shì)

我們提供了安全態(tài)勢(shì)大盤，幫助用戶全局了解安全事件、安全態(tài)勢(shì)，便于進(jìn)行告警鏈路查看及排錯(cuò)使用。此外，報(bào)表還可自由擴(kuò)展。例如審計(jì)日志、Ingress中心等大盤，可以清楚的展現(xiàn)K8s集群的控制面、數(shù)據(jù)面訪問情況，包括統(tǒng)計(jì)、趨勢(shì)、地域等；事件中心可以展現(xiàn)集群內(nèi)的一些異?；顒?dòng)，例如POD OOM、節(jié)點(diǎn)重啟等。

告警與On-Call機(jī)制

通過上文提到的統(tǒng)一的數(shù)據(jù)采集能力、統(tǒng)一的存儲(chǔ)及查詢分析能力，我們可以做到對(duì)安全威脅的基本探測(cè)能力。但是要構(gòu)建完備的監(jiān)控體系，接下來就要解決如何持續(xù)監(jiān)控的問題。為此，我們開發(fā)了一套一站式智能運(yùn)維告警系統(tǒng)。它提供對(duì)日志、時(shí)序等各類數(shù)據(jù)的告警監(jiān)控，告警模版化擴(kuò)展能力，亦可接受三方告警，對(duì)告警進(jìn)行降噪、事件管理、通知管理等。我們也針對(duì)K8s下一些典型安全場(chǎng)景的歷史經(jīng)驗(yàn)，提供了眾多內(nèi)置告警規(guī)則，開箱即用并持續(xù)增加中。這些規(guī)則庫有覆蓋了CIS和安全場(chǎng)景的最佳實(shí)踐，用戶僅需開啟對(duì)應(yīng)規(guī)則，即可享受到全天候的安全保障。

當(dāng)告警規(guī)則探測(cè)到異常發(fā)生時(shí)，需要盡快的將威脅事件通知給相應(yīng)的開發(fā)人員。我們對(duì)接了豐富的通知渠道，便于威脅事件的全方位觸達(dá)。

• 多渠道：支持短信、語音、郵件、釘釘、企業(yè)微信、飛書、Slack等多種通知渠道，同時(shí)還支持通過自定義 Webhook 進(jìn)行擴(kuò)展。同一個(gè)告警，支持同時(shí)通過多個(gè)渠道、每個(gè)渠道使用不同的通知內(nèi)容進(jìn)行發(fā)送。例如通過語音和釘釘來進(jìn)行告警通知，既可以保證觸達(dá)強(qiáng)度，又可以保證通知內(nèi)容的豐富程度。
• 動(dòng)態(tài)通知：可以根據(jù)告警屬性動(dòng)態(tài)分派通知。例如：測(cè)試環(huán)境的告警，通過短信通知到張三，并且只在工作時(shí)間通知；而生產(chǎn)環(huán)境的告警，通過電話通知到張三和李四，并且無論何時(shí)，都要進(jìn)行通知。
• 通知升級(jí)：長(zhǎng)時(shí)間未解決的告警要進(jìn)行升級(jí)。例如某告警觸發(fā)后，通過短信通知到了某員工，但是該問題長(zhǎng)時(shí)間未被處理，導(dǎo)致告警一直沒有恢復(fù)，此時(shí)需要通知升級(jí)，通過語音的方式通知到該員工的領(lǐng)導(dǎo)。

安全事件發(fā)生后，如果不及時(shí)處理或不慎遺漏都會(huì)造成更大的安全風(fēng)險(xiǎn)擴(kuò)展。因此，一定要建立完備的反饋機(jī)制，將安全問題處理形成閉環(huán)?；谶@個(gè)問題，我們提供了安全事件管理中心，便于用戶全局查看安全事件，并進(jìn)行相應(yīng)的管理動(dòng)作。當(dāng)開發(fā)或安全人員接收到安全告警事件通知后，可以登陸安全事件管理中心進(jìn)行事件的確認(rèn)、處理人的指派、處理動(dòng)作記錄等操作。

基于云原生可觀測(cè)平臺(tái)構(gòu)建K8s下的SecOps能力

綜上，我們可以基于阿里云SLS搭建一個(gè)功能完備的K8s安全監(jiān)控體系。整體分為四個(gè)層次：

• 數(shù)據(jù)采集層：主要提供安全數(shù)據(jù)接入能力。其中以iLogtail為最主要的數(shù)據(jù)采集方式（支持前置的數(shù)據(jù)處理能力），并且同時(shí)支持API方式，兼容眾多標(biāo)準(zhǔn)協(xié)議，例如OpenTelemetry、Prometheus、Syslog、Kafka等。
• 統(tǒng)一存儲(chǔ)分析層：提供了針對(duì)Logs、Metric、Trace、安全事件、Topo等多種數(shù)據(jù)的存儲(chǔ)層，并且在此基礎(chǔ)上提供了統(tǒng)一的數(shù)據(jù)關(guān)聯(lián)分析能力。對(duì)于不規(guī)則數(shù)據(jù)，提供了數(shù)據(jù)加工能力。
• 智能服務(wù)：基于智能告警服務(wù)，可以實(shí)現(xiàn)安全場(chǎng)景的持續(xù)監(jiān)控及通知響應(yīng)能力；智能算法服務(wù)提供了智能巡檢功能可以擴(kuò)展智能巡檢、分析的能力。
• 上層應(yīng)用：基于上述三層可以打造屬于用戶自己的SecOps應(yīng)用。當(dāng)然對(duì)于ITOps、DevOps、BussinessOPS也是不錯(cuò)的選擇。

K8s安全監(jiān)控體系展望

未來已來，K8s安全監(jiān)控體系未來將朝著生態(tài)化、輕量化、智能化、一體化的方向繼續(xù)發(fā)展，為企業(yè)安全保駕護(hù)航。

iLogtail已開源，歡迎使用及共建

iLogtail作為阿里云SLS提供的可觀測(cè)數(shù)據(jù)采集器，可以運(yùn)行在服務(wù)器、容器、K8s、嵌入式等多種環(huán)境，支持采集數(shù)百種可觀測(cè)數(shù)據(jù)（日志、監(jiān)控、Trace、事件等），已經(jīng)有千萬級(jí)的安裝量。目前，iLogtail已正式開源，歡迎使用及參與共建。

GitHub: https://github.com/alibaba/ilogtail

社區(qū)版文檔：https://ilogtail.gitbook.io/ilogtail-docs/about/readme

企業(yè)版官網(wǎng)：https://help.aliyun.com/document_detail/65018.html

參考：

• 最全Kubernetes審計(jì)日志方案：https://developer.aliyun.com/article/686982
• Kubernetes可觀察性：全方位事件監(jiān)控：https://developer.aliyun.com/article/745567
• 零信任策略下云上安全信息與事件管理最佳實(shí)踐：https://developer.aliyun.com/article/812284
• 阿里可觀測(cè)性數(shù)據(jù)引擎的技術(shù)實(shí)踐：https://developer.aliyun.com/article/814339
• 阿里 PB 級(jí) Kubernetes 日志平臺(tái)建設(shè)實(shí)踐：https://developer.aliyun.com/article/704058
• Kubernetes 安全風(fēng)險(xiǎn)以及 29 個(gè)最佳實(shí)踐：https://mp.weixin.qq.com/s/aMadv2d3jHPJyV2h42r8sQ?