零信任策略下K8s安全監控最佳實踐（K+）

作者：阿里開發者 2022-09-13 09:04:20

隨著云計算、大數據、物聯網、移動辦公等新技術與業務的深度融合，網絡安全邊界也逐漸變得更加模糊，傳統邊界安全防護理念面臨巨大挑戰。

作者 | 徐可甲(燁陌)

云原生架構新風險與需求概述

安全風險概述

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

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

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

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

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

構建時：基于安全的鏡像倉庫、權限最小化的安全鏡像構建業務系統，及時修復已知漏洞。
部署時：按照K8s最佳實踐部署，修復錯誤配置。
運行時：持續監控安全威脅，并及時做出相應。

K8s安全體系

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

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

我們發現上述安全體系可以跟零信任策略的“從不信任、始終驗證”的思想相呼應的。

K8s信任邊界

為了更好的理解K8s系統的安全風險，接下來我們從K8s內外部網絡邊界的角度展開分析。其中，紅色曲線部分可以被視為獨立邊界的子系統。

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

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

K8s場景下安全數據采集技術方案

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

安全數據源

K8s審計日志

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

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

Kubernetes 審計日志是 Api Server 產生的結構化日志，記錄了對 Api Server 的訪問操作（包括時間、來源、操作結果、發起操作的用戶、操作的資源以及請求/響應的詳細信息等）。通過審計日志，可以追溯對集群狀態的變更；了解集群的運行狀況；排查異常；發現集群潛在的安全、性能風險等等。包括不限于如下行為：

當前/歷史上集群發生了哪些變更事件。
這些變更操作者是誰，是系統組件還是用戶，是哪個系統組件/用戶。
重要變更事件的詳細內容是什么，比如修改了POD中的哪個參數。
事件的結果是什么，成功還是失敗。
操作用戶來自哪里，集群內還是集群外。

Kubernetes Event

事件（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等系統，并提供不同等級的過濾條件，實現事件的實時采集、定向告警、異步歸檔。

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訪問分布。

K8s配置安全

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

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

K8s運行時安全

Falco是一款云原生運行時安全開源項目，用于監控Kubernetes上應用的運行時異常活動。Falco在內核態通過監控文件更改、網絡活動、進程表和其他數據是否存在可疑行為，并可以通過可插拔后端發送警報。通過 Falco 可輕松檢測以下異常：

容器內運行的 Shell
服務器進程產生意外類型的子進程
敏感文件讀取（如 /etc/shadow）
非設備文件寫入至 /dev
系統的標準二進制文件（如 ls）產生出站流量

K8s安全數據源特點

以上我們列舉了一些K8s安全監控場景下常見的數據源，而且每種日志特點各異。我們可以發現安全類數據種類繁多，來源眾多，格式也不統一。總結下來具有如下特點：

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

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

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

K8s采集技術

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

可觀測數據采集器iLogtail

iLogtail的核心定位是可觀測數據的采集器，幫助開發者構建統一的數據采集層，助力可觀測平臺打造各種上層的應用場景。2022年6月底，阿里云iLogtail代碼完整開源，正式發布了完整功能的iLogtail社區版。

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采用基于時間片的采集調度、多級高低水位反饋隊列、事件非阻塞處理、流控/停采策略以及配置動態更新等多項關鍵技術，融合實現了兼具隔離性、公平性、可靠性、可控性、性價比五大特性的多租戶隔離方案。

iLogtail部署模式

作為容器編排領域的標準，Kubernetes（K8s）應用的場景越來越廣泛，iLogtail 在K8s下也提供了完備的采集能力。在K8s場景下，iLogtail主要常用的有3種工作模式：

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

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

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的采集配置，進而完成日志采集工作。

安全數據監測與響應最佳實踐

統一存儲分析引擎

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

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

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

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

我們可以通過標準 SQL 語句對日志進行分析。
還可以通過 PromQL 擴展的 SQL 函數對指標數據進行分析。
還可以通過嵌套查詢，對指標數據的分析結果進行再聚合。
此外還可以再通過機器學習函數，給查詢和分析賦予 AI 的能力。

雖然不同階段的數據產生自不同的系統，也有著不同的格式，但是由于它們的存儲和分析是一致的，我們可以非常輕松地實現統一的安全態勢及安全事件監控。

智能巡檢

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

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

通過以上3層數據鏈路，實現了從原始訪問日志到預聚和的指標最后再到機器學習的異常事件整個數據的流轉，對于用戶來說，告警和監控只需要基于指標和智能巡檢的結果進行，而涉及到具體服務的問題分析可以再回到原始的訪問日志并基于統一查詢分析引擎進行自定義的排查和分析。

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

針對以上問題，我們推出智能巡檢功能，通過自研的人工智能算法，對指標、日志等流數據進行一站式整合、巡檢與告警。使用智能巡檢功能后，只需要組織一下具體的監控項，算法模型就會自動完成異常檢測、業態自適應、告警精細。

安全態勢

我們提供了安全態勢大盤，幫助用戶全局了解安全事件、安全態勢，便于進行告警鏈路查看及排錯使用。此外，報表還可自由擴展。例如審計日志、Ingress中心等大盤，可以清楚的展現K8s集群的控制面、數據面訪問情況，包括統計、趨勢、地域等；事件中心可以展現集群內的一些異常活動，例如POD OOM、節點重啟等。

告警與On-Call機制

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

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

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

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

基于云原生可觀測平臺構建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已正式開源，歡迎使用及參與共建。

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

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

企業版官網：https://help.aliyun.com/document_detail/65018.html

參考：

最全Kubernetes審計日志方案：https://developer.aliyun.com/article/686982
Kubernetes可觀察性：全方位事件監控：https://developer.aliyun.com/article/745567
零信任策略下云上安全信息與事件管理最佳實踐：https://developer.aliyun.com/article/812284
阿里可觀測性數據引擎的技術實踐：https://developer.aliyun.com/article/814339
阿里 PB 級 Kubernetes 日志平臺建設實踐：https://developer.aliyun.com/article/704058
Kubernetes 安全風險以及 29 個最佳實踐：https://mp.weixin.qq.com/s/aMadv2d3jHPJyV2h42r8sQ?

責任編輯：武曉燕來源：阿里開發者

云計算移動辦公大數據