Isovalent Cilium 企業版 包含一個基於 eBPF 的實時安全可觀測性和運行時增強（runtime enforcement）平臺，2022 年 5 月 16 日，Isovalent 終於決定將該平臺的主要功能開源，並將其命名爲 Tetragon。
什麼是 Tetragon？
#
Tetragon 提供了基於 eBPF 的完全透明的安全可觀測性能力以及實時的運行時增強（runtime enforcement）能力。由於基於 eBPF 的內核級收集器中直接內置了智能內核過濾能力和聚合邏輯，因此 Tetragon 無需更改應用程序即可以非常低的開銷實現深度的可觀測性。內嵌的運行時執行層不僅能夠在系統調用層面進行訪問控制，而且能夠檢測到特權、Capabilities 和命名空間的提權逃逸，並實時自動阻止受影響進程的進一步執行。
智能可觀測性
#
Tetragon 的基石是一個強大的可觀測層，它可以觀測整個系統，從低級別的內核可見性到跟蹤文件訪問、網絡活動或能力（capability）變化，一直到應用層，涵蓋了諸如對易受攻擊的共享庫的函數調用、跟蹤進程執行或解析發出的 HTTP 請求。總的來說，Tetragon 可以提供對各種內核子系統的可觀測性，涵蓋了命名空間逃逸、Capabilities 和特權升級、文件系統和數據訪問、HTTP、DNS、TLS 和 TCP 等協議的網絡活動，以及系統調用層的事件，以審計系統調用和跟蹤進程執行。
- 深度可觀測性：可以觀測整個系統和應用程序的幾乎所有調用環節。比如檢測 TCP 連接中的低級微突發（microbursts），爲黃金信號監控面板提供 HTTP 可見性，或者檢測特定易受攻擊的共享庫的使用的能力。Tetragon 提供了一個易於使用的框架，以涵蓋更多的可觀測性用例，因此可以探索更多的可能性。
- 完全透明：Tetragon 所有的可觀察性數據都是從內核中透明地收集的，無需更改應用程序代碼，應用也無法檢測到自己何時被監控，這是安全用例的理想選擇。
- 低開銷：Tetragon 直接在內核中使用 eBPF 執行過濾、聚合、度量統計和直方圖收集，大大減少了系統的開銷。此外，Tetragon 使用高效的數據結構，如每個 CPU 的哈希表、環形緩衝區和 LRU 地圖，以提供高效和快速的數據收集手段，並避免向用戶空間 agent 發送大量的低信號事件。
譯者注：微突發（microbursts）是指端口在非常短的時間（毫秒級別）內收到非常多的突發數據。
運行時增強（runtime enforcement）
#
基於豐富的可觀測性，Tetragon 還提供了實時的運行時增強（runtime enforcement）能力。大部份運行時增強（runtime enforcement）系統都只有有限的一組強制執行點（例如僅在系統調用級別），而 Tetragon 能夠以預防的方式在整個操作系統中執行安全策略，而不是對事件異步地做出反應。除了能夠爲多個層級的訪問控制指定允許列表外，Tetragon 還能夠自動檢測特權和 Capabilities 升級或命名空間提權（容器逃逸），並自動終止受影響的進程。安全策略可以通過 Kubernetes（CRD）、JSON API 或 Open Policy Agent（OPA）等系統注入。
- 預防式安全：Tetragon 的運行時策略直接在內核中執行，並且是同步的（實時的），這樣可以真正防止攻擊，而不僅僅是對攻擊做出異步的反應。
- 無需瞭解所有攻擊載體：Tetragon 無需瞭解單個攻擊載體並對其進行阻斷，它的做法是允許你定義一系列難以被攻破的隔離和特權限制保證措施，並自動執行這些保證措施。
- 可插拔策略架構：Tetragon 允許執行多種不同來源的安全策略，包括用戶自定義的策略，Open Policy Agent (OPA) 等系統定義的策略，以及通過可擴展的 Kubernetes CRD 和 JSON 接口對接來自第三方組件的安全策略。
運行時增強爲何是實時的？
#
除了有更多的位置（enforcement points）可以執行策略，eBPF 還使得我們在遭受漏洞攻擊時馬上作出反應，實時、同步地執行策略。當然，Tetragon 也能夠像其他運行時增強（runtime enforcement）系統一樣允許或拒絕與特定參數相匹配的特定系統調用，但它的殺手鐗是一旦觀察到特權/功能升級或命名空間提權，便立即阻止進程繼續運行，從而將運行時增強（runtime enforcement）功能提升到一個新的臺階。更厲害的是，Tetragon 甚至不需要了解這個攻擊載體是什麼。
Tetragon 另闢蹊徑，它不需要了解特定的漏洞或攻擊載體，而是直接定義執行策略，指定哪些應用程序應在運行時可以提升特權、附加額外的 Capabilities、跨越內核命名空間的邊界，而後便監視內核的提權和逃逸，並自動終止違反定義策略的進程。而且殺死進程是在內核中同步執行的，這意味着如果一個進程使用 write(2) 或 sendmsg(2) 來利用內核漏洞獲得權限，那麼這些系統調用將永遠不會返回，該進程及其所有線程都將被終止，不會再繼續執行。
爲什麼使用 Tetragon？
#
傳統的可觀測性和運行時增強（runtime enforcement）解決方案無外乎都是基於以下幾個方面來實現，它們都有各自的優勢和缺陷。而 Tetragon 利用 eBPF 將更多的優勢進行結合，並消除了絕大多數的缺陷。
| 應用檢測 | LD_PRELOAD | ptrace(2) |
|---|---|---|
| 應用檢測使用代碼依賴性來獲得對應用的可觀測性。 | LD_PRELOAD 可以在感知不到應用的情況下加載一個共享庫來攔截系統調用。 |
ptrace(2) 是一個由內核提供的調試接口，用於跟蹤進程和系統調用。 |
優勢：
|
優勢：
|
優勢:
|
缺陷：
|
缺陷：
|
缺陷：
|
上述解決方案都是在應用程序和系統調用層面上執行，並且可觀測性方案也各不相同。它們都有一個用戶空間代理，這個代理依賴於按定義收集的可觀測性數據，然後對其作出反應，且無法對內核級別的事件進行觀測。
| seccomp | SELinux / LSM | 內核模塊 |
|---|---|---|
| seccomp(-bpf) 允許對系統調用進行過濾。 | SELinux 和 LSM 是內置的內核安全框架，用於執行訪問控制 | Linux內核模塊可用於實現可觀測性和運行時增強（runtime enforcement）的自定義邏輯 |
優勢：
|
優勢：
|
優勢：
|
缺陷：
|
缺陷：
|
缺陷：
|
第二類解決方案都是直接在內核層面操作，主要針對運行時增強（runtime enforcement），觀測能力較弱（甚至沒有觀測能力）。內置的內核系統提供了非常多的策略執行選項，但內核在構建時卻只重點提供訪問控制的能力，而且非常難以擴展，例如內核是無法感知到 Kubernetes 和容器的。雖然內核模塊解決了可擴展性問題，但由於其產生的安全風險，在很多場景下往往不是一種明智的選擇。
像 LSM-eBPF 這樣年輕的內核子系統功能非常強大，也非常有前景，只是需要依賴最新的內核（≥5.7）。Tetragon 可以使用 eBPF-LSM 作爲策略執行點，而且不受 eBPF-LSM 所需的內核版本的限制。
由此可見，在 eBPF 的加持下，Tetragon 結合了現有解決方案的絕大多數優勢。
- 高效 & 透明：Tetragon 提供了對應用的可觀測性和高效的應用運行時檢測，並且完全透明，對應用無侵入性，無需更改應用代碼。
- 實時增強：Tetragon 提供了像 seccomp、SELinux 和 LSM 一樣的內核級別同步執行策略的能力，但它將策略執行從純粹的訪問控制提升到了防止對系統和組件造成傷害的級別，而不是僅僅限制對資源和數據的訪問。
- 深度可擴展的可觀測性：Tetragon 提供了深度的系統觀測能力和自定義 Linux 內核模塊的可擴展性，同時沒有安全和可用性風險。
此外，Tetragon 還提供了一個 agent，可以原生集成各種現代化的可觀測性系統和策略標準（例如 Kubernetes、Prometheus、fluentd、Open Telemetry、Open Policy Agent 以及傳統的 SIEM 平臺）。
自動緩解特權或容器逃逸
#
Linux 內核的安全漏洞緩解是一個具有挑戰性的問題。解決方案通常依賴於檢測和阻止已知的攻擊途徑、減少攻擊面或限制受損組件的爆炸半徑。Tetragon 通過檢測和停止相關進程來阻止內核中的特權、Capabilities 和命名空間提權。Kuberenetes 的每個應用程序都可以明確聲明一組特權、Capabilities 和跨特權的命名空間。
緩解 CVE-2021-22555 漏洞
#
如下是一個簡單的策略，它描述了在 CAP_SYS_ADMIN 能力更改時，進程將終止：
apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
name: "capability-protection"
spec:
[...]
selectors:
- matchCapabilityChanges:
- type: Effective
operator: In
values:
- "CAP_SYS_ADMIN"
matchActions:
- action: Sigkill
CVE-2021-22555 漏洞是通過 Netfilter 漏洞來獲取特權。在實施上面的策略情況下，運行該漏洞，讓我們看看會發生什麼：
root@ubuntu2:/# /root/cve-2021-22555
[+] Linux Privilege Escalation by theflow@ - 2021
[+] STAGE 0: Initialization
[*] Setting up namespace sandbox...
[...]
[+] STAGE 5: Post-exploitation
[*] Escaping container...
[*] Cleaning up...
[*] Popping root shell...
Killed
可以看到當利用該漏洞進行特權提權時，該進程直接被終止了。 請注意，上述的策略不包含漏洞本身的特定元素，所以使用不同攻擊途徑的不同漏洞進行攻擊，會獲得相同的結果。
使用 Tetragon CLI 進行應用行爲檢查
#
在 Isovalent 中，Tetragon CLI 代號爲 amazing-cli，可能是使用 Tetragon 進行可觀測性的第一個切入點。該 CLI 通常是令人喫驚，因爲它能以一種簡單易懂的形式公開復雜系統的大量信息。
在以下示例中，我們將展示如何使用 Tetragon 來觀測 Kubernetes Pod 的行爲，該 Pod 運行命令 curl -L github.com：
- 開始執行
curl -L github.com - 進行 github.com 的 DNS 解析，及端口 80 的 TCP 連接打開。
- github.com 在 7 毫秒內返回 HTTP 碼 301 ，將流量重定向到端口 443。啓用 TLS，curl 重定向並執行另一個 DNS 解析。
- TCP 連接端口 443 打開，開始 TLS 握手。 使用 TLS 1.3 協議，協商的密鑰是 AES-128-GCM-SHA256。
- 進行數據交換。端口 80 上總共接收約 80 個字節，端口 443 上接收 218KiB。
- 進程退出，錯誤碼爲 0。
網絡和運行時可觀測性的結合
#
Tetragon 使用 eBPF 的其中一個令人興奮的優勢是它可以結合多個方面的可觀測性，目前爲止，這些可觀測性通常都是單獨處理的。下面是一個結合網絡和運行時可觀測性的示例，以演示識別哪些進程涉及哪種類型的網絡通信的能力。以下示例顯示了使用 Tetragon 來觀測一個 Kubernetes Pod，該 Pod 被入侵併受到橫向移動攻擊：
在上圖中，我們看到了通過反向 Shell 進行的經典橫向移動攻擊：
- Kubernetes 的 Pod
crawler-c57f9778c-wtcbc在 Kubernetes 命名空間tenant-jobs中運行。Pod 是通過 Containerd 運行的，Containerd 作爲 PID 1 init 進程的子進程運行。在 Pod 內運行的二進制文件稱爲“爬蟲”，它會產生一個執行server.js的 Node 進程。 - Node 應用的出口網絡連接是
api.twitter.com和 Kubernetes 中的 Elasticsearch 服務。 - Pod 啓動 5 分鐘後，又啓動了另一個子進程調用 netcat (nc)。結合運行時和網絡可觀測性來看，很明顯這是一個正在進行的反向 Shell 攻擊。
- 然後，可以觀察到攻擊者正在運行 curl 訪問內部 es 服務器，然後使用 curl 將檢索到的數據上傳到 S3 存儲中。
監控對敏感文件的訪問
#
Tetragon 具有監控文件和數據訪問的能力。 以下示例說明了 Tetragon 與 Splunk 集成，以跟蹤對敏感文件的訪問，同時提供訪問的上下文（例如： Kubernetes 元數據、容器鏡像、二進制文件和用戶信息）。
上面的示例列出了對 /etcd/passwd 的訪問，包括進程、及容器鏡像和 Kubernetes 命名空間。除了監視 /etc/passwd 或 /etc/shadow 之外，還可以監控系統上其他的明顯文件，包括：容器運行時的 UNIX 套接字，及可能改變系統引導的 Systemd 單元或 Init 文件。
Tetragon 不僅提供了對此類敏感文件訪問的監控能力，而且可以阻止訪問此類文件。
檢測 TLS 弱密鑰和版本
#
TLS 是當今世界安全的基石，但使用較舊的 TLS 版本或不安全的 TLS 密鑰可能會構成嚴重的安全威脅。 無意識的錯誤使用 TLS 密鑰和版本會導致故意的 TLS 降級攻擊。
上面的儀表板顯示了 TLS 協議版本信息，並將其與 Kubernetes Pod 和命名空間上下文相關聯。 它還可以顯示密鑰信息，及更重要的是密鑰長度信息。
運行時感知的網絡策略
#
你可能熟悉 Kubernetes 的 NetworkPolicies，它定義了 Kubernetes 工作負載的允許和禁止的網絡通信。簡而言之，這些策略描述了允許 Pod A 與 Pod B 或 CIDR 10.0.0.0/8 通信，但禁止 Pod A 與 Pod C 或 CIDR 20.1.1.1/32 通信。
這些策略的粒度是在 Pod 級別。所以無論 Pod 中運行的 app.js 還是 attack.py 腳本調用 curl，這些策略都可以生效的。藉助 Tetragon 技術，可以擴展 Cilium 的網絡策略功能以包括運行時上下文：
kind: CiliumNetworkPolicy
[...]
endpointSelector:
- matchLabels:
- name: Frontend
egress:
- toEndpoints:
- matchLabels:
- name: Backend
fromRuntime:
- binary: app.py
privileged: false
上述策略獲得明顯更好的最小特權策略。它允許前端 Pod 與後端 Pod 對話，但前提是：
- 源 Pod 中的二進制文件爲 app.py
- 源 Pod 中的進程以非特權運行
上述示例將二進制名稱和特權執行上下文考慮在內，此概念可以擴展爲基於其他參數進行限制，例如：確保進程仍處於該命名空間、UID/GID 上下文，甚至考慮可執行文件的內存哈希。
總結
#
我們非常樂意將 Tetragon 開源。額外的可觀測性和安全控制將會幫助你們改善安全、平臺和應用程序團隊的工作，助力整體的基礎架構（特別是 Kubernetes 環境）更加安全。更重要的是，有了開源社區的加持，我們非常期待接下來會發生的故事。
如果你有興趣瞭解更多關於 Tetragon 的信息，我們將在接下來的幾周內舉辦一場關於 Tetragon 的網絡研討會，包括：介紹、演示和提問的機會。 同時，加入 Cilium Slack 上的 #tetragon 以開始與我們的團隊交流。
如果你對 Isovalent Tetragon Enterprise 感興趣，請隨時與我們聯繫。