作者 |  徐可甲(燁陌) 

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

安全風(fēng)險概述

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

隨著云計算、大數(shù)據(jù)、物聯(lián)網(wǎ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)程連接，甚至移動辦公的到來，使得個人手機等個人設(shè)備接入變成了可能。在這樣的背景下，零信任架構(gòu)（Zero Trust Architecture, ZTA）應(yīng)運而生。它打破傳統(tǒng)的認(rèn)證，即信任邊界防護(hù)、靜態(tài)訪問控制、以網(wǎng)絡(luò)為中心等防護(hù)思路，建立起一套以身份為中心，以持續(xù)認(rèn)證、動態(tài)訪問控制、審計以及監(jiān)測為鏈條，以最小化實時授權(quán)為核心，以多維信任算法為基礎(chǔ)，認(rèn)證達(dá)末端的動態(tài)安全架構(gòu)。

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

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

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

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

K8s安全體系

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

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

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

K8s信任邊界

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

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

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

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

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

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

K8s審計日志

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

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

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

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

Kubernetes Event

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

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

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

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

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

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

Ingress

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

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

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

K8s配置安全

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

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

K8s運行時安全

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

• 容器內(nèi)運行的 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ù)源特點

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

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

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

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

K8s采集技術(shù)

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

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

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

iLogtail核心優(yōu)勢

輕量級、高性能

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

超強可靠性

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

毫秒級延時

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

云原生支持

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

插件化擴展能力

上下游生態(tài)：通過插件系統(tǒng)的擴展，目前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逐步擴展到Kafka、gPRC等，未來也會支持ClickHouse、ElasticSearch等。

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

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

多租戶隔離

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

iLogtail部署模式

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

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

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

iLogtail采集原理

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

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

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

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

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

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

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

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

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

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

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

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

智能巡檢

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

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

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

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

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

安全態(tài)勢

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

告警與On-Call機制

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

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

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

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

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

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

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

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

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

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

iLogtail作為阿里云SLS提供的可觀測數(shù)據(jù)采集器，可以運行在服務(wù)器、容器、K8s、嵌入式等多種環(huán)境，支持采集數(shù)百種可觀測數(shù)據(jù)（日志、監(jiān)控、Trace、事件等），已經(jīng)有千萬級的安裝量。目前，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審計日志方案：https://developer.aliyun.com/article/686982
• Kubernetes可觀察性：全方位事件監(jiān)控：https://developer.aliyun.com/article/745567
• 零信任策略下云上安全信息與事件管理最佳實踐：https://developer.aliyun.com/article/812284
• 阿里可觀測性數(shù)據(jù)引擎的技術(shù)實踐：https://developer.aliyun.com/article/814339
• 阿里 PB 級 Kubernetes 日志平臺建設(shè)實踐：https://developer.aliyun.com/article/704058
• Kubernetes 安全風(fēng)險以及 29 個最佳實踐：https://mp.weixin.qq.com/s/aMadv2d3jHPJyV2h42r8sQ?