麻豆影视在线观看av-麻豆影视在线观看-麻豆一区二区在我观看-麻豆一区二区三区精品视频-麻豆一级毛片-麻豆一二三四区乱码

Hello folks，我是 Luga，今天我們來聊一聊在 Kubernetes Cluster 編排生態環境中一個至關重要的安全 Topic：Kubectl Plugin。

(相關資料圖)

基于 Go 語言的優勢，Kubernetes 在設計上往往具有令人難以置信的可定制性。Kubernetes 支持針對特定用例場景的自定義配置，從而消除了對底層功能應用補丁的需要。因此，插件化便是擴展 Kubernetes 功能和提供開箱即用產品的最佳實踐方法。

讓我們更深入地研究 Kubectl Plugin 列表，這里，筆者強烈安利這些插件，畢竟，在實際的業務場景中，基于不同的業務訴求，這些插件可能對任何角色的人員都非常有用，尤其是維護、安全工程師等。

接下來，讓我們進入今天的主題 ...??

Kubernetes Plugin 概述

通常情況下，基于 Kubernetes 自身特性，用戶可以為 Kubernetes 命令行工具 Kubectl 安裝和編寫接口擴展以滿足實際的業務場景需要。?

通過將核心 Kubectl 命令視為與 Kubernetes Cluster 交互的基本構建塊，集群管理員可以將插件視為利用這些構建塊創建更復雜行為的一種方式。

基于插件，我們可以使用新的子命令擴展 Kubectl，以及允許使用 Kubectl 主要發行版中未包含的新功能和自定義功能以滿足特定功能的需要。

在實際的業務場景中，Kubernetes 插件能夠為所構建的容器平臺提供無數的安全優勢。基于業務訴求，事件響應者或維護者能夠可以使用他們所選擇的語言進行“即時”附加功能的擴展或二次開發。

在某些特定的場景中，由于 Kubernetes 功能在企業需要實現“范圍外”功能的情況下往往不足，因此，團隊通常需要實施自己的自定義插件開發操作。

Kubernetes 安全插件解析????

在本文中，筆者將從 Krew 插件管理器以及自定義插件開發等 2 個方面簡要為大家解析不同場景下的 Kubectl 安全插件實踐 。

Krew Plugin

Krew 是由 Kubernetes 特別興趣小組 ( SIG ) CLI 社區維護的插件管理器。從本質上來講，Krew 本身就是一個插件，基于此 ，使得 Kubectl 所維護插件的使用變得更加容易，并能夠幫助我們在機器上發現、安裝和管理它們，類似于 apt、dnf 或 brew 等工具。其項目地址：https://github.com/kubernetes-sigs/krew

截至目前，Krew 上已經提供了 210 多個 Kubectl 插件——而且這個數字還在不斷增加。隨著時間的推移，一些項目被積極使用，同時，一些項目也被逐漸棄用，但仍然可以通過 Krew 訪問。

作為一款強大的插件及平臺，Krew 適用于所有主流平臺，例如 macOS、Linux 和 Windows。對于 Kubectl 用戶：Krew 幫助我們以一致的方式查找、安裝和管理 Kubectl 插件。除此，Krew 還能過幫助 Kubectl 插件開發人員：使得我們在多個平臺上打包和分發所構建的插件，并通過 Krew 的集中式插件存儲庫使得它們可被發現。

通過 Krew 安裝 Kubectl 插件的命令，具體如下所示：

[leonli@Leon ~ % ]kubectl krew install 

通過 Krew 插件索引提供的 Kubectl 插件若未經審計，這可能會導致供應鏈出現問題。如上述所述，Krew 插件索引包含數百個 kubectl 插件：https ://krew.sigs.k8s.io/plugins/

當我們無意或有意安裝和運行第三方插件時，可能需要自行承擔未知的潛在風險。歸根結底，Kubectl 插件只是一個在 Shell 中運行的任意程序而已。

這里，筆者將為大家分享如下不同的 Kubectl 安全插件，基于大家的實際業務環境，使得這些插件或多或少能夠改善我們所構建的 Kubernetes Cluster 的安全狀況。

1、 Stern Plugin

作為一個 Kubectl 插件，Stern 的工作方式更像 Linux 系統命令中的 “ tail -f ”。與 kubectl log -f 不同的是，kubectl log -f 對輸入參數有其自身的限制，而 Stern 則允許我們將 Pod ID 和 Container ID 指定為正則表達式。

Stern 遵循任何匹配并將輸出多路復用在一起，以 Pod 和容器 ID 為前綴，并進行顏色編碼以供大家使用。

我們可以使用以下 Krew 命令安裝 Stern，具體如下所示：?

[leonli@Leon ~ % ]kubectl krew install stern

在 Stern 中跟蹤應用程序名稱的命令，具體如下：

[leonli@Leon ~ % ]kubectl stern appname

這將匹配任何包含單詞 Service 的 Pod 并監聽其中的所有容器。如果我們只想查看服務器容器 Container 的流量，可以這樣操作：

[leonli@Leon ~ % ]kubectl stern --container

這將流式傳輸所有服務器容器的日志，即使在多個 Pod 中運行也是如此。

Stern 插件的一個有趣的安全用例便是查看 Kubernetes Cluster 的身份驗證活動。若要顯示過去 15 分鐘內的身份驗證活動以及突出顯示的相關時間戳詳情，我們可以運行如下命令查看：

[leonli@Leon ~ % ]kubectl stern -t --since 15m auth

2、Kubectl-trace Plugin

作為另一款 Kubectl 安全插件，Kubectl-trace 允許我們在 Kubernetes Cluster 中安排 bpftrace 程序的執行。簡而言之，Kubectl-trace 插件是一個在 Kubernetes Cluster 中進行分布式跟蹤的工具。它允許請求通過集群的不同組件（包括 Pod、服務和入口控制器）時跟蹤請求的執行情況。

我們可以使用以下 Krew 命令安裝 Kubectl-trace 插件，具體如下所示：

[leonli@Leon ~ % ]kubectl krew install trace

使用 Kubectl-trace 插件的一個潛在安全優勢是它可以幫助我們識別和解決與集群內請求處理相關的問題。例如，如果懷疑某個特定請求由于集群中的某些問題而被阻止或減慢，我們可以使用 Kubectl-trace 來跟蹤請求在集群中傳播并確定問題的根源。

這個插件運行一個程序來探測所選節點上的跟蹤點：

[leonli@Leon ~ % ]kubectl trace run  -e "tracepoint:syscalls:sys_enter_* { @[probe] = count(); }"

另一個潛在的安全優勢是 Kubectl-trace 可以幫助我們了解請求是如何在集群中處理的，這對于識別潛在的漏洞或錯誤配置很有用。例如，如果發現某個請求正在由遭到破壞的 Pod 或服務處理，我們可以使用 Kubectl-trace 來跟蹤該請求并確定問題的來源。

總的來說，Kubectl-trace 插件可以通過幫助識別和解決與請求處理和執行相關的問題來提高 Kubernetes 集群的安全性。

3、Kubectl-capture Plugin

Sysdig 開源（Sysdig Inspect）的一個用于容器故障排除、性能調優和安全調查的強大工具。Sysdig 的團隊創建了一個 Kubectl 插件，它在運行 Pod 的底層主機中觸發數據包捕獲。

我們可以使用以下 Krew 命令安裝 kubectl-capture 插件，具體如下所示：

[leonli@Leon ~ % ]kubectl krew install kubectl-capture

數據包捕獲對于 Kubernetes 中的事件響應和取證非常有用。捕獲文件在一段時間內創建并下載到本地，以便將其與 Sysdig Inspect 一起使用，Sysdig Inspect 是一個強大的開源界面，旨在直觀地導航數據密集的 Sysdig 捕獲，其中包含細粒度的系統、網絡和應用程序活動 Linux 系統。

只需對集群中任何正在運行的 Pod 運行以下命令：

[leonli@Leon ~ % ]kubectl capture kinsing-78f5d695bd-bcbd8

在旋轉捕獲容器時，需要一些時間來編譯 Sysdig 內核模塊和捕獲系統調用。完成后，我們可以從工作站讀取 Sysdig Inspect UI 中的內容，如下所示：

使用這些工具，分析人員將更容易找到問題的根源或審核發生的情況。如果想更深入，可以閱讀使用 Sysdig Inspect 進行容器故障排除或對惡意容器進行分類。

4、Kube Policy Advisor Plugin

Kube-policy-advisor 插件為所構建的 Kubernetes 集群建議 PodSecurityPolicies 和 Open Policy Agent (OPA) 策略。雖然 PodSecurityPolicies 已被棄用，因此不應使用，但 OPA 是非常推薦的準入控制器工具。

我們可以使用以下 Krew 命令安裝 advise-policy 插件，具體如下所示：

[leonli@Leon ~ % ]kubectl krew install advise-policy

這個 Kubectl 插件為 Kubernetes Cluster 提供安全性和合規性檢查，除此之外，可以幫助識別集群配置中潛在的安全風險和違反最佳實踐的行為，并提供有關如何修復這些問題的建議。kube-policy-advisor 可以執行的檢查類型的一些示例包括：

（1）確保 Pod 以最低權限運行，并且不會被授予不必要的權限；?

（2）檢查密鑰和其他敏感數據是否未以純文本形式存儲或簽入源代碼管理；

（3）驗證網絡策略是否到位以防止對資源的未授權訪問；?

（4）評估容器鏡像的安全性并確保它們來自可信來源。

在 Kubernetes 中，準入控制器在創建、更新和刪除操作期間強制執行對象的語義驗證。使用 OPA，我們可以在 Kubernetes 對象上實施自定義策略，而無需重新編譯或重新配置 Kubernetes API Server。

作為一種策略工具，Kube-policy-advisor 可以更輕松地從實時 K8s 環境或從包含 Pod 規范（Deployment、DaemonSet、Pod 等）的單個 .yaml 文件創建 OPA 策略。在下面的命令中，插件能夠檢查任何給定的命名空間以打印報告或 OPA 策略。

[leonli@Leon ~ % ]kubectl advise-policy inspect --namespace=

注意：如果不輸入給定的命名空間，默認情況下，它將為所有網絡命名空間生成 OPA 策略。

通過使用 Kube-policy-advisor 插件，其能夠可以幫助確保我們的 Kubernetes Cluster 安全并符合最佳實踐，從而有助于保護我們的應用程序和數據免受潛在威脅。

5、Kubectl-ssm-secret Plugin

kubectl -ssm-secret 插件允許管理員將他們的 Kubernetes Secrets 導入或導出到 AWS SSM Parameter Store 路徑或從中導出。Kubernetes Secret 是在 Kubernetes Cluster 環境中使用的敏感信息，例如，密碼或訪問密鑰。在 Kubernetes 和 AWS 云之間傳輸時，能夠安全地控制這些敏感憑證非常重要。

我們可以使用以下 Krew 命令安裝 ssm-secret 插件，具體如下所示：

[leonli@Leon ~ % ]kubectl krew install ssm-secret

當然，密鑰并不是 Kubernetes 獨有的。我們幾乎可以在所有類型的現代應用程序環境或平臺中使用 Secrets 的數據。對于 ssm-secret 插件，在給定參數存儲路徑下找到的所有參數都可以作為“StringData”導入到單個 Kubernetes Secret 中。

如果我們正在重新配置集群或命名空間并且需要一遍又一遍地配置相同的密鑰時，這將非常有用。此外，備份/恢復我們的 LetsEncryp t或其他證書可能很有用。

如果路徑 /foo/bar 的 AWS 參數包含一個密鑰值，并且參數 /foo/passwd 包含一個安全密碼，我們可以使用 kubectl ssm-secret list 子命令查看參數存儲中的鍵和值，具體如下：

[leonli@Leon ~ % ]kubectl ssm-secret list --ssm-path /foo

然后，可以使用以下導入命令導入這些輸出參數，具體如下：

[leonli@Leon ~ % ]kubectl ssm-secret import foo --ssm-path /foo

需要注意的是，我們必須為此插件指定一個參數存儲路徑才能工作。它不會在給定路徑下遞歸搜索超過一個級別。因此，該插件非常固執己見，如果用戶沒有正確跟蹤這些路徑，他們將面臨無法將密鑰導入/導出到正確路徑的風險。

6、Kubelogin Plugin

若我們的 Kubernetes Cluster 環境運行的是 Kubectl v.1.12 或更高版本，Kubelogin（也稱為“kubectl-login”）是一個非常有用的安全插件，用于通過 CLI 登錄集群。它通過像 DEX 這樣的 OpenID Connect 提供商來實現這一點。OpenID Connect 是 OAuth 2.0 協議之上的一個簡單身份層。它允許客戶端根據授權服務器執行的身份驗證來驗證最終用戶的身份，并以可互操作和類似 REST 的方式獲取有關最終用戶的基本配置文件信息。

我們可以使用以下 Krew 命令安裝 kubectl-login 插件，具體如下所示：

[leonli@Leon ~ % ]kubectl krew install kubectl-login

我們的 OpenID Connect 提供商必須具有 OpenID 配置中列出的 Kubernetes API 客戶端的默認回調端點：

[leonli@Leon ~ % ]http://localhost:33768/auth/callback

這個 Kubectl 插件從 .kube/config 獲取 OpenID Connect (OIDC) 頒發者 URL ，因此它必須放在我們的 .kube/config 中。對 kubeconfig 文件進行此更改后，我們可以繼續使用分配給 OIDC 提供商的用戶名，具體如下：

[leonli@Leon ~ % ]kubectl login nigeldouglas-oidc

在 CLI 中執行此命令后，將打開瀏覽器并重定向到 OpenID Connect 提供程序登錄頁面。在 OIDC 提供商端成功驗證后，我們的 kubeconfig 文件中的令牌將被替換。

7、Kubectl-whisper-secret Plugin

我們提到了使用 Kubectl-ssm-secret 插件保護敏感憑證（如“Secrets”）的重要性。whisper-secret 插件專注于創建具有改進隱私的秘密。該插件允許用戶通過安全輸入提示創建秘密，以防止通過終端 (bash) 歷史、shoulder surfing 攻擊等方式泄露信息。

我們可以使用以下 Krew 命令安裝 whisper-secret 插件，具體如下所示：

[leonli@Leon ~ % ]kubectl krew install whisper-secret

“kubectl create secret” 有幾個我們最常使用的子命令，它們可能會以多種方式泄露敏感信息，如上所述。例如，我們可以使用純文本密碼通過“kubectl create secret”命令連接到 Docker 注冊表以進行身份驗證。

[leonli@Leon ~ % ]kubectl create secret docker-registry my-secret --docker-password nigelDouglasP@ssw0rD

“kubectl whisper-secret” 插件允許用戶通過安全輸入提示為包含敏感信息的字段（如 --from -literal和--docker-password ）創建密鑰。

[leonli@Leon ~ % ]kubectl whisper-secret docker-registry my-secret --docker-password -- -n nigel-test --docker-username 

然后系統會提示輸入 Docker 密碼，但這不會插入命令本身。這樣，密碼就不會以純文本值的形式出現在 bash 歷史記錄中，從而提高了安全性。

因此處內容涉及面較廣，由于時間關系，本文解析到此為止，希望對大家有用。關于 Kubectl 安全插件更多需要了解的信息，將在下一篇博文中介紹，歡迎大家交流、關注！最后，給大家推薦一本云原生書籍，如下所示，對于新人或許有一定的幫助。

Adiós !