本文重點将圍繞監控防護展開，逐層遞進地介紹如何在複雜的分布式容器化環境中借助可觀測性平台，持續監控K8s叢集，及時發現異常的 API 通路事件、異常流量、異常配置、異常日志等行為，并且結合合理的告警政策建立更主動的安全防禦體系。歡迎閱讀~
一、雲原生架構新風險與需求概述
1.1 安全風險概述
傳統的網絡安全架構理念是基于邊界的安全架構，企業建構網絡安全體系時，首先要做的是尋找安全邊界，把網絡劃分為外網、内網等不同的區域，然後在邊界上部署防火牆、入侵檢測、WAF等産品。然而這種網絡安全架構是基于内網比外網更安全的假設建立起來，在某種程度上預設了對内網中的人、裝置和系統的信任，忽視加強内網安全措施。不法分子一旦突破企業的邊界安全防護進入内網，會像進入無人之境，将帶來嚴重的後果。此外，内部人員100%安全的假說也是不成立的，我們可以從《内部威脅成本全球報告》裡看到，不管是内部威脅的數量，還是威脅成本都是呈顯著上升的趨勢。
随着雲計算、大資料、物聯網、移動辦公等新技術與業務的深度融合，網絡安全邊界也逐漸變得更加模糊，傳統邊界安全防護理念面臨巨大挑戰。以辦公網絡安全為例，已經逐漸從僅支援公司内部網絡裝置連接配接，發展到使用辦公電腦通過VPN遠端連接配接，甚至移動辦公的到來，使得個人手機等個人裝置接入變成了可能。在這樣的背景下，零信任架構（Zero Trust Architecture, ZTA）應運而生。它打破傳統的認證，即信任邊界防護、靜态通路控制、以網絡為中心等防護思路，建立起一套以身份為中心，以持續認證、動态通路控制、審計以及監測為鍊條，以最小化實時授權為核心，以多元信任算法為基礎，認證達末端的動态安全架構。
我們知道Kubernetes在容器編排市場中占據了主導地位，使用者基數呈逐年上升的趨勢。K8s提供了強大的運維部署、彈性伸縮、故障恢複能力，極大地便利了分布式系統的開發和管理，但是随之而來的安全問題卻也比較突出。
根據《容器和Kubernetes安全态勢報告》報告，針對雲原生應用的威脅已越來越多，僅有6%的人沒有經曆過與容器或K8s相關的安全事件。同時，還指出近70%的安全風險都是由人為錯誤配置而引發的，此外運作時安全及重大安全漏洞引發的安全事件也是重要的因素。《中國雲原生使用者調查報告》同樣也支援，容器安全問題成為使用者應用的最大擔憂。63%的使用者認為容器安全是緊迫的需求，大量使用者回報網絡安全技術句實施難度複雜度高，且監控系統、日志系統不完善，很難進行有效的安全監控。
從上述的報告可以看出，K8s安全問題會分布在整個生命周期的各個階段。一些常見的安全風險表現為：容器鏡像漏洞或濫用鏡像倉庫導緻的漏洞；容器大量部署導緻很難發覺安全問題；K8s核心元件漏洞威脅，多個高危漏洞爆出；叢集配置不當，甚至一些預設配置有安全隐患；沒有明确網絡邊界，網絡隔離性問題；攻擊面變大、監控和防護難度大。是以，我們迫切需要建立一個全方位的安全體系，覆寫整個容器生命周期的各個階段。
- 建構時：基于安全的鏡像倉庫、權限最小化的安全鏡像建構業務系統，及時修複已知漏洞。
- 部署時：按照K8s最佳實踐部署，修複錯誤配置。
- 運作時：持續監控安全威脅，并及時做出響應。
1.2 K8s安全體系
上圖為阿裡雲容器服務Kubernetes版給出的安全體系，可以看出建構完善的安全體系從下到上需要覆寫基礎架構安全、可信軟體供應鍊、運作時安全三個次元。
- 基礎架構安全：基于CIS kubernetes benchmark指導安全部署；依賴K8s的安全體系，建立細粒度的通路控制機制。
- 可信軟體供應鍊：通過鏡像掃描發現已知安全漏洞；通過鏡像簽名保障鏡像來源的安全性及不被篡改；通過DevSecOps內建，實作安全左移，與開發、測試、運維等品質動作進行深度融合。
- 運作時安全：通過PodSecurityPolicy針對容器部署時進行安全校驗，有效限制應用運作時的行為安全；應用運作時的安全配置巡檢；持續的無處不在的運作時安全監控機制和異常事件告警通知機制，保證安全事件的及時發現及解決；選用安全沙箱，提供更強的隔離環境。
我們發現上述安全體系可以跟零信任政策的“從不信任、始終驗證”的思想相呼應的。
1.3 K8s信任邊界
為了更好的了解K8s系統的安全風險，接下來我們從K8s内外部網絡邊界的角度展開分析。其中，紅色曲線部分可以被視為獨立邊界的子系統。
- 容器鏡像：主要涉及到的安全攻擊點就是鏡像倉庫和鏡像本身。其中，使用了不受信任的鏡像倉庫或被篡改的容器鏡像會導緻惡意代碼被執行。
- K8s控制平面：涉及K8s 的 API Server、scheduler 和 controller-manager核心元件等。其中API Server為K8s系統管控入口，是重點的攻擊對象。另外，核心元件之間調用鍊的安全也同樣重要。
- K8s資料平面：涉及Ingress Controller跟Service，Ingress作為内部服務對外暴露的端口，被攻擊風險較大。
- 節點上運作時安全：涉及kubelet、kube-proxy 和容器運作時環境，需要避免運作時容器越權或容器逃逸等風險。
二、K8s場景下安全資料采集技術方案
安全資料是作為K8s安全監控的根本，如果沒有資料那就是“巧婦難為無米之炊”，任何進階的監控政策都無從談起。是以，首先我們将會介紹K8s相關的安全資料源及相關的采集技術。
2.1 安全資料源
2.1.1 K8s審計日志
在 Kubernetes 中，Api Server是K8s叢集資源變更、查詢的入口，所有對叢集狀态的查詢和修改都是通過向 Api Server 發送請求，對 Api Server 的請求來源可以分為4類：
- 控制面元件，例如 Scheduler，各種 Controller，Api Server 自身。
- 節點上的各種 Agent，例如 Kubelet、Kube-proxy 等。
- 叢集的其它服務，例如 Coredns、Ingress-controller、各種第三方的 Operator 等。
- 外部使用者，例如運維人員通過 Kubectl。
2.1.2 KubernetesEvent
事件（Event）主要是用來記錄K8s叢集内發生的狀态變更，大到叢集節點異常，小到 Pod 啟動、排程成功等。事件詳細記錄了叢集狀态變更發生的時間、元件、等級（Normal、Warning、Error）、類型、詳細資訊，通過事件能夠知道應用的部署、排程、運作、停止等整個生命周期，也能通過事件去了解系統中正在發生的一些異常。
K8s事件存儲在etcd中，預設情況下隻儲存1個小時，由于etcd并不支援一些複雜的分析操作，隻提供了非常簡單的過濾方式，比如通過Reason、時間、類型等。同時這些事件隻是被動的存在etcd中，并不支援主動推送到其他系統，通常隻能手動的去檢視。而實際上我們對事件的使用需求非常高，比較典型的場景如下：
- 對系統中的異常事件做實時告警，例如Failed、Evicted、FailedMount、FailedScheduling等。
- 通常問題排查可能要去查找曆史資料，是以需要去查詢更長時間範圍的事件（幾天甚至幾個月）。
- 事件支援歸類統計，例如能夠計算事件發生的趨勢以及與上一時間段（昨天/上周/釋出前）對比，以便基于統計名額進行判斷和決策。
- 支援不同的人員按照各種次元去做過濾、篩選。
- 支援自定義的訂閱這些事件去做自定義的監控，以便和公司内部的部署運維平台內建。
預設情況下，Kubernetes事件隻關注容器管理相關的問題，對于硬體、作業系統、容器運作時、依賴系統（網絡、存儲等）并不會提供更多的檢測能力。NPD（node-problem-detector）作為Kubernetes節點診斷的工具，可以将節點的異常轉換為Node的事件，并推送到APIServer中，交由APIServer進行事件的統一管理。NPD支援多種異常檢查，例如：
- 基礎服務問題：NTP服務未啟動。
- 硬體問題：CPU、記憶體、磁盤、網卡損壞Kernel問題：Kernel hang，檔案系統損壞。
- 容器運作時問題：Docker hang，Docker無法啟動。
之後，可以借助開源事件工具kube-eventer，将叢集的事件離線到釘釘、SLS、Kafka等系統，并提供不同等級的過濾條件，實作事件的實時采集、定向告警、異步歸檔。
2.1.3 Ingress
K8s中Ingress隻是一種API資源的聲明，具體的實作需要安裝對應的Ingress Controller，由Ingress Controller接管Ingress定義，将流量轉發到對應的Service。目前Ingress Controller有非常多種實作，常用的的是Nginx Ingress Controller。
日志和監控是所有Ingress Controller都會提供的基礎功能，日志一般包括通路日志（Access Log）、控制日志（Controller Log）和錯誤日志（Error Log），監控主要從日志以及Controller中提取部分Metric資訊。這些資料中通路日志的量級最大、資訊最多、價值也最高，一般7層的通路日志包括：URL、源IP、UserAgent、狀态碼、入流量、出流量、響應時間等，對于Ingress Controller這種轉發型的日志，還包括轉發的Service名、Service響應時間等額外資訊。從這些資訊中，我們能夠分析出非常多的資訊，例如：
- 網站通路的PV、UV；
- 通路的地域分布、裝置端分布；
- 網站通路的錯誤比例；
- 後端服務的響應延遲；
- 不同URL通路分布。
2.1.4 K8s配置安全
CIS Kubernetes Benchmark是CIS推出的一系列用于建構一個安全可靠的Kubernetes叢集的安全配置建議，K8s使用者可以基于這些規範建構安全的K8s叢集。但是人工一個個去比對安全配置規則的建議顯然是不合适的，一般會結合一些巡檢工具進行。
security-inspector是一款針對K8s Workload配置進行多元度掃描工具，可以在巡檢報告中檢視巡檢掃描結果，包括健康檢查、鏡像、網絡、資源、安全等掃描資訊。此外，kube-bench、kube-hunter等其他開源項目也是可選用的CIS規則巡檢方案。
2.1.5 K8s運作時安全
Falco是一款雲原生運作時安全開源項目，用于監控Kubernetes上應用的運作時異常活動。Falco在核心态通過監控檔案更改、網絡活動、程序表和其他資料是否存在可疑行為，并可以通過可插拔後端發送警報。
通過 Falco 可輕松檢測以下異常：
- 容器内運作的 Shell
- 伺服器程序産生意外類型的子程序
- 敏感檔案讀取（如 /etc/shadow）
- 非裝置檔案寫入至 /dev
- 系統的标準二進制檔案（如 ls）産生出站流量
2.1.6 K8s安全資料源特點
以上我們列舉了一些K8s安全監控場景下常見的資料源，而且每種日志特點各異。我們可以發現安全類資料種類繁多，來源衆多，格式也不統一。總結下來具有如下特點：
- 安全資料類型包含了日志、名額、事件。
- 安全資料可能是來自檔案，也有可能來自标準輸出或者标準錯誤，甚至可能是Syslog等标準協定。
- 安全文本資料可能會存在于容器内的檔案或者主控端上的檔案。
- Ingress通路日志等涉及資料面流量的日志往往會資料量極大。
- 審計日志作為叢集安全審計的必備日志，重要性極高，需要長時間跨度存儲（等保2.0要求至少需要存180天），并且不能有采集的丢失。
為了更全面的采集安全資料，需要具備一個性能強大、生态支援全面、K8s原生支援的安全資料采集器。該采集器需要具備以下能力：
- 容器運作時支援的全面性，可以支援Docker、Containerd等運作時。
- K8s提供了強大的動态擴縮容能力，但也同時給資料采集帶了困難。是以，采集器需要适應容器動态的特點。
- 有些安全資料是通過Job觸發的，該類任務具有生命周期短的特點，采集器需要提供短生命周期容器的采集能力。
- 所采集需要具備關聯K8s上下文的能力，為後續分析提供便捷。
- 強大的資料處理能力，可以在不影響性能的前提下完成安全資料的處理需求，為後續分析場景打下基礎。
- K8s雲上托管服務越來越流行，需要能夠支援雲上服務的采集場景。
2.2 K8s采集技術
阿裡雲SLS開源的可觀測資料采集器iLogtail，可以完全滿足上述安全資料的特點及場景要求，并且經過阿裡雙十一、公有雲等衆多複雜場景考驗，在安全資料采集領域也是一個很好的選擇。接下來，我們重點介紹下iLogtail的技術特點及K8s下的采集原理。
2.2.1 可觀測資料采集器iLogtail
iLogtail的核心定位是可觀測資料的采集器，幫助開發者建構統一的資料采集層，助力可觀測平台打造各種上層的應用場景。2022年6月底，阿裡雲iLogtail代碼完整開源，正式釋出了完整功能的iLogtail社群版。
2.2.2 iLogtail核心優勢
輕量級、高性能
- iLogtail主體部分通過C++，插件部分Golang實作，不管記憶體還是CPU具有天然的性能優勢。
- iLogtail也持續針對性的做了很多特定場景的優化，比如針對日志的極簡、Json、正則模式采集提供了C++加速能力，極大提升了日志采集效率，單核采集流量最高能到百M/s。
超強可靠性
- iLogtail作為阿裡集團内重要的可觀測資料采集基礎設施，多年來一直穩定支援雙11等大促場景，在應對網絡擁塞、流量洪峰、程序重新開機等方面表現突出。
- 公有雲上iLogtail也持續支援着各行各業的客戶，衆多複雜業務場景對于iLogtail的可靠性提供了足夠的場景支援。
毫秒級延時
- iLogtail實作如此高吞吐的秘訣之一是使用了無鎖化事件處理模型。與業界其他開源Agent為每個配置配置設定獨立線程/Goroutine讀取資料不同，iLogtail資料的讀取隻配置了一個線程。由于資料讀取的瓶頸并不在于計算而是磁盤，單線程足以完成所有配置的事件處理以及資料讀取。使用單線程使得iLogtail的事件處理和資料讀取都可以在無鎖環境下運作，資料結構更加輕量化，進而取得了相對多線程處理更優的成本效益。
- 檔案采集基于inotify與polling相結合的發現機制，既借助了inotify的低延遲與低性能消耗的特點，也通過polling的方式兼顧了運作環境的全面性。
雲原生支援
- iLogtail提供了業務容器實時動态發現能力，并支援通過K8s元資訊（例如Label、環境變量等）進行采集過濾。特别是一些短Job場景，比如一些機器學習的訓練任務，生命周期隻有幾分鐘甚至幾十秒，也提供了全面的友好的支援。
- 部署模式上，也支援DaemonsSet、Sidecar等多種模式。
- 為了更原生的K8s支援，也提供了Operator機制，使用者可以通過CRD的方式進行采集配置管理。
插件化擴充能力
- 上下遊生态：通過插件系統的擴充，目前iLogtail已經支援了衆多資料源的接入，資料源類型覆寫Log、Metric、Trace，資料源除了檔案的采集，還包括了标準協定的支援，例如HTTP、Mysql Binlog、Prometheus、Skywalking、syslog等。資料輸出生态也從SLS逐漸擴充到Kafka、gPRC等，未來也會支援ClickHouse、ElasticSearch等。
- 處理能力擴充：iLogtail采用PipeLine的設計，通過Input插件采集到資料，會經過采集配置中設定的Processor處理，之後經過Aggregator插件打包，最終通過Flusher發送到日志存儲系統。資料處理環境包含資料切分、字段提取、過濾、資料增強等環節，所有插件可以自由組合。此外，針對于正則、Json、分隔符等特定格式，iLogtail還提供了C++加速能力。
- 快速疊代：開發者也可以根據自己的需求，定制開發相應的插件。因為每個插件互相獨立，是以開發者隻需要按照接口規範開發即可，入手門檻較低。
多租戶隔離
- iLogtail采用基于時間片的采集排程、多級高低水位回報隊列、事件非阻塞處理、流控/停采政策以及配置動态更新等多項關鍵技術，融合實作了兼具隔離性、公平性、可靠性、可控性、成本效益五大特性的多租戶隔離方案。
2.2.3 iLogtail部署模式
作為容器編排領域的标準，Kubernetes（K8s）應用的場景越來越廣泛，iLogtail 在K8s下也提供了完備的采集能力。在K8s場景下，iLogtail主要常用的有3種工作模式：
- DaemonSet方式：在K8s的每個node上部署一個iLogtail，由該iLogtail采集節點上所有容器的日志到日志系統。此方式特點是運維簡單、資源占用少、支援采集容器的标準輸出和文本檔案、配置方式靈活，但是在超大叢集存在一定的性能瓶頸。
- Sidecar方式：一個POD中伴随業務容器運作一個iLogtail容器，用于采集該POD中業務容器産生的日志。此方式特點是多租戶隔離性好、性能好，但是資源占用較多。
- Deployment方式：當業務容器用PVC挂載日志目錄或者需要全局連接配接API Server擷取K8s中繼資料等場景，可以選擇在叢集中部署一個單副本的iLogtail Deployment進行資料采集。
2.3.4 iLogtail采集原理
自K8s問世以來，Docker運作時一直是主流，但是随着K8s将dockershim移除，K8s官方推薦優先選擇Containerd 或 CRI-O作為容器運作時。Docker份額目前雖然還是主流但是已經在呈逐年下降的趨勢，Containerd、CRI-O地位逐年都在快速上升。是以，從K8s支援全面性上，iLogtail需要支援主流的運作時，目前已經支援Docker和Containerd兩種容器引擎的資料采集。
K8s提供了強大的運維部署、彈性伸縮、故障恢複能力，極大地便利了分布式系統的開發和管理，然而這也帶來了可觀測資料采集難度的增大。特别是一些短Job場景，比如一些機器學習的訓練任務，生命周期隻有幾分鐘甚至幾秒，如何快速準确地發現所需要采集的容器至關重要。iLogtail在K8s場景下的采集分為如下幾個步驟：
- 容器自動發現與釋放：iLogtail通過通路位于主控端上容器運作時（Docker Engine/ContainerD）的sock擷取容器資訊，并通過監聽Docker Event及增量擷取機制，及時感覺容器新增與釋放。
- 容器上下文資訊擷取：包括容器層級資訊，例如容器名、ID、挂載點、環境變量、Label；以及K8s層級資訊，例如Pod、命名空間、Labels。
- 容器過濾及隔離性：基于容器上下文資訊，提供采集容器過濾能力，可以将不同采集配置應用到不同的采集容器上，既可以保證采集的隔離性，也可以減少不必要的資源浪費。
- 元資訊關聯：基于容器上下文資訊和容器環境變量，提供在日志中富化K8s元資訊的能力。
- 采集路徑發現：根據容器元資訊自動識别不同運作時的标準輸出格式和日志路徑；對于overlay、overlay2的存儲驅動，可以根據日志類型及容器運作時自動拼接出采集路徑，簡單高效。
此外，對于CICD自動化部署和運維程度要求較高的使用者，iLogtail還提供了K8s原生支援，支援通過CRD的方式進行采集配置管理。目前該功能僅企業版可用，後續會逐漸開源。該方案中，iLogtail K8s新增了一個CustomResourceDefinition擴充，名為AliyunLogConfig。同時開發了alibaba-log-controller用于監聽AliyunLogConfig事件并自動建立iLogtail的采集配置，進而完成日志采集工作。
三、安全資料監測與響應最佳實踐
3.1 統一存儲分析引擎
安全資料監控一個重要的能力就是對采集到的資料，進行實時的合規監控分析，支援對曆史資料的合規審計，對來自外部的威脅和内部的違規進行審計分析。實際安全分析場景往往會面臨衆多困難：
- 安全威脅往往是一個逐漸的過程，可能需要幾個月或更長的時間才會真正暴露出來。是以，需要提供低成本的存儲能力，及強大的長時間跨度資料分析能力。
- 安全資料來源衆多，格式不統一，日志、時序資料都可能涉及。有些安全威脅隐蔽性較強，需要多種資料的關聯分析才能發現。是以，需要具備強大的關聯分析能力。
為此，我們設計了一套統一的可觀測資料存儲分析引擎。将日志、名額、Meta等資料全部接入到統一的存儲中，在一些等保場景可以通過開啟智能冷熱分層存儲，降低不活躍資料的存儲成本。之後，我們建構了一套統一的查詢分析引擎，該引擎以SQL為基礎，擴充了關鍵詞查詢、PromQL文法能力及機器學習算子能力，可友善支撐查詢分析、可視化、監控告警、AI 等上層應用場景。同時，SQL作為頂層語言，可以起到串聯日志、時序、ML模型、CMDB、外部DB的能力，使得大規模多資料關聯分析成為可能。
可以認為，SLS SQL = Search + SQL92（Agg，WIndow，GroupBy...）+ PromQL + ...
以下就是一個比較典型的分析的例子：
- 我們可以通過标準 SQL 語句對日志進行分析。
- 還可以通過 PromQL 擴充的 SQL 函數對名額資料進行分析。
- 還可以通過嵌套查詢，對名額資料的分析結果進行再聚合。
- 此外還可以再通過機器學習函數，給查詢和分析賦予 AI 的能力。
雖然不同階段的資料産生自不同的系統，也有着不同的格式，但是由于它們的存儲和分析是一緻的，我們可以非常輕松地實作統一的安全态勢及安全事件監控。
3.2 智能巡檢
Ingress通路日志産生量極大，而且日積月累後會造成大量資料存儲，會造成存儲成本的急劇上升，并且在長時間跨度查詢分析場景下也會效率極低。
為了達到高性能、低成本、快速、智能等要求，我們對Ingress這種超大資料量的方案進行了架構更新。
- 原始通路日志存儲：當Ingress Controller産生通路請求後，會實時将請求的通路日志推送到使用者自身的日志庫中，SLS的Logstore具備高可靠、實時索引、自動擴容等功能，保證日志的可靠性和可擴充性。
- 預聚和：由于原始通路日志量巨大，基于原始日志計算名額性能開銷較大，是以我們專門推出了基于通路日志的名額預聚和能力，能夠将上百萬甚至上億的通路日志實時聚合成名額類型的時序資料，資料量會降低1-2個數量級，後續的分析與監控可直接基于時序資料進行，大大提高效率。
- 智能巡檢：對于預聚和後的Metrics（名額資料），我們提供了基于機器學習的智能巡檢功能，幫助使用者自動去檢測Ingress的各個次元的名額異常，将異常資訊實時展現在時序的圖表中，結合實時告警能力及時通知給使用者解決。此外後續還會支援異常打标，基于使用者回報的資訊進行更加精确的檢測。
通過以上3層資料鍊路，實作了從原始通路日志到預聚和的名額最後再到機器學習的異常事件整個資料的流轉，對于使用者來說，告警和監控隻需要基于名額和智能巡檢的結果進行，而涉及到具體服務的問題分析可以再回到原始的通路日志并基于統一查詢分析引擎進行自定義的排查和分析。
- 成本高、查詢效率低：對于日志量極大場景，特别如果再加上長時間跨度的因素，會造成存儲成本的急劇上升，查詢效率往往也很低。
- 效率低：對于異常現場的定位，需要人工配置各種各樣的規則去進行異常的捕獲。
- 時效差：大部分時序資料具有時效性特征。故障、變更都會引起對應名額形态的變化，前一種規則條件下的異常可能在下一時刻是正常狀态。
- 配置難：時序資料形态各異。有突刺變化、折點變化、周期變化等諸多形态，門檻值範圍也各有不同。對于複雜形态下的異常，規則往往難以配置。
- 效果差：資料流不斷動态變化，業務形态日新月異，固定的規則方法很難在新的業态下起作用，進而産生大量的誤報或者漏報。對于異常的程度，不同場景，不同使用者，對其容忍的程度不同。在排查問題中，有效異常點捕捉的越多，有助于具體問題的排查；而在告警通知中，高危異常點越少，越有助于提升告警處理的效率。
針對以上問題，我們推出智能巡檢功能，通過自研的人工智能算法，對名額、日志等流資料進行一站式整合、巡檢與告警。使用智能巡檢功能後，隻需要組織一下具體的監控項，算法模型就會自動完成異常檢測、業态自适應、告警精細。
3.3 安全态勢
我們提供了安全态勢大盤，幫助使用者全局了解安全事件、安全态勢，便于進行告警鍊路檢視及排錯使用。此外，報表還可自由擴充。例如審計日志、Ingress中心等大盤，可以清楚的展現K8s叢集的控制面、資料面通路情況，包括統計、趨勢、地域等；事件中心可以展現叢集内的一些異常活動，例如POD OOM、節點重新開機等。
3.4 告警與On-Call機制
通過上文提到的統一的資料采集能力、統一的存儲及查詢分析能力，我們可以做到對安全威脅的基本探測能力。但是要建構完備的監控體系，接下來就要解決如何持續監控的問題。為此，我們開發了一套一站式智能運維告警系統。它提供對日志、時序等各類資料的告警監控，告警模版化擴充能力，亦可接受三方告警，對告警進行降噪、事件管理、通知管理等。
我們也針對K8s下一些典型安全場景的曆史經驗，提供了衆多内置告警規則，開箱即用并持續增加中。這些規則庫有覆寫了CIS和安全場景的最佳實踐，使用者僅需開啟對應規則，即可享受到全天候的安全保障。
當告警規則探測到異常發生時，需要盡快的将威脅事件通知給相應的開發人員。我們對接了豐富的通知管道，便于威脅事件的全方位觸達。
- 多管道：支援短信、語音、郵件、釘釘、企業微信、飛書、Slack等多種通知管道，同時還支援通過自定義 Webhook 進行擴充。同一個告警，支援同時通過多個管道、每個管道使用不同的通知内容進行發送。例如通過語音和釘釘來進行告警通知，既可以保證觸達強度，又可以保證通知内容的豐富程度。
- 動态通知：可以根據告警屬性動态分派通知。例如：測試環境的告警，通過短信通知到張三，并且隻在工作時間通知；而生産環境的告警，通過電話通知到張三和李四，并且無論何時，都要進行通知。
- 通知更新：長時間未解決的告警要進行更新。例如某告警觸發後，通過短信通知到了某員工，但是該問題長時間未被處理，導緻告警一直沒有恢複，此時需要通知更新，通過語音的方式通知到該員工的上司。
安全事件發生後，如果不及時處理或不慎遺漏都會造成更大的安全風險擴充。是以，一定要建立完備的回報機制，将安全問題處理形成閉環。基于這個問題，我們提供了安全事件管理中心，便于使用者全局檢視安全事件，并進行相應的管理動作。當開發或安全人員接收到安全告警事件通知後，可以登陸安全事件管理中心進行事件的确認、處理人的指派、處理動作記錄等操作。
3.5 基于雲原生可觀測平台建構K8s下的SecOps能力
綜上，我們可以基于阿裡雲SLS搭建一個功能完備的K8s安全監控體系。整體分為四個層次：
- 資料采集層：主要提供安全資料接入能力。其中以iLogtail為最主要的資料采集方式（支援前置的資料處理能力），并且同時支援API方式，相容衆多标準協定，例如OpenTelemetry、Prometheus、Syslog、Kafka等。
- 統一存儲分析層：提供了針對Logs、Metric、Trace、安全事件、Topo等多種資料的存儲層，并且在此基礎上提供了統一的資料關聯分析能力。對于不規則資料，提供了資料加工能力。
- 智能服務：基于智能告警服務，可以實作安全場景的持續監控及通知響應能力；智能算法服務提供了智能巡檢功能可以擴充智能巡檢、分析的能力。
- 上層應用：基于上述三層可以打造屬于使用者自己的SecOps應用。當然對于ITOps、DevOps、BussinessOPS也是不錯的選擇。
四、K8s安全監控體系展望
未來已來，K8s安全監控體系未來将朝着生态化、輕量化、智能化、一體化的方向繼續發展，為企業安全保駕護航。
五、iLogtail已開源，歡迎使用及共建！
iLogtail作為阿裡雲SLS提供的可觀測資料采集器，可以運作在伺服器、容器、K8s、嵌入式等多種環境，支援采集數百種可觀測資料（日志、監控、Trace、事件等），已經有千萬級的安裝量。目前，iLogtail已正式開源，歡迎使用及參與共建。
文章來源：https://developer.aliyun.com/article/1128404