Hello folks，我是 Luga，接着上一篇博文，我们继续来解析 Kubectl 安全插件相关内容...

     8、RBAC-tool Plugin

     基于角色的访问控制 ( RBAC ) 是一种根据组织内各个用户的角色来调节对计算机或网络资源的访问的方法。RBAC 工具简化了 RBAC 策略的查询和创建。

     我们可以使用以下 Krew 命令安装 RBAC 工具，具体如下所示：

[leonli@Leon ~ % ]kubectl krew install rbac-tool

     如果我们不熟悉如何将 RBAC 角色分配给不同的 Kubernetes Cluster 组件，那么，可视化命令将会帮助我们生成所有 RBAC 决策的有见地的图表，具体如下：

[leonli@Leon ~ % ]kubectl rbac-tool viz --cluster-context nigel-douglas-cluster

     上面的命令使用 kubeconfig 上下文“ nigel-douglas-cluster ”扫描  Kubernetes Cluster。这些图表对于显示分配给服务帐户的权限前后的可视化很有帮助。

     除了 RBAC 工具插件提供的“ viz ”之外，还有多个命令可供使用，最有用的是 ' who-can ' 命令。这表明哪些主体具有 RBAC 权限，可以对对象执行由“VERB”（创建、读取、更新或删除）表示的操作。

     通常，我们若要查看某些内容，可以通过名称“ important-secret ”读取密钥资源，那么，我们可以运行以下命令进行：

[leonli@Leon ~ % ]kubectl rbac-tool who-can get secret/important-secret

     9、Cilium Plugin

     Cilium 是一个网络安全项目，由于其强大的 eBPF 数据平面而越来越受大众欢迎。由于 Kubernetes 在设计时并未考虑任何特定的 CNI（网络）插件，因此尝试通过 Kubectl 管理 Cilium 代理可能性不确定。于是，便有 Cilium 团队发布 Cilium Kubectl 插件以支撑此项功能。

     我们可以使用以下 Krew 命令安装 Cilium 插件，具体如下所示：

[leonli@Leon ~ % ]kubectl krew install cilium

     作为基本的第一步，我们可以通过以下命令对由 Cilium 网络提供支持的单个 Node     进行连接检查，具体如下：

[leonli@Leon ~ % ]kubectl cilium connectivity test --single-node <node>

     这不仅提供了操作的可见性，例如，如果 Cilium 无法与“ Hubble ”等核心组件通信，将会以特定的方式进行可观测性显示。

     Hubble 为 Kubernetes 提供网络、服务和安全可观察性。能够快速诊断连接错误，例如“连接被拒绝”，可以提高威胁的整体可见性，并提供维护法规遵从性所需的集中网络事件视图。如果想更深入地研究网络策略，请查阅“如何防止对 Kubernetes 的拒绝服务 (DoS) 攻击”等相关文章。

     10、Access-matrix Plugin

     Access-matrix，可称为“访问矩阵”（通常称为“Rakkess”）是一个 Kubectl 插件，可显示服务器资源的访问矩阵。

     我们可以使用以下 Krew 命令安装 Access-matrix 插件，具体如下所示：

[leonli@Leon ~ % ]kubectl krew install access-matrix

     通常情况下，我们只需运行以下命令即可查看“默认”网络命名空间中所有资源的创建、读取、更新和删除 (CRUD) 权限，具体如下：

[leonli@Leon ~ % ]kubectl rakkess –n default

     某些角色仅适用于具有特定名称的资源。要查看此类配置，请提供资源名称作为附加参数。例如，显示命名空间 sysdig-agent 中名为 sysdig-controller 的 ConfigMap 的访问权限，具体如下：

[leonli@Leon ~ % ]kubectl access-matrix r cm sysdig-controller -n sysdig-agent --verbs=all

     由于 Rakkess 资源需要查询 Roles、ClusterRoles 及其绑定，因此通常需要管理集群访问权限。

     11、Rolesum Plugin

     Rolesum Kubectl 插件主要用于生成 Kubernetes 集群中定义的角色和权限的摘要。它允许我们查看已在集群中定义的所有角色和权限、已被授予这些角色的用户和组以及总结指定主题（ServiceAccount、用户和组）的 RBAC 角色。

     我们可以使用以下 Krew 命令安装 Rolesum 插件，具体如下所示：

[leonli@Leon ~ % ]kubectl krew install rolesum

     使用 Rolesum kubectl 插件的一个潜在安全优势是它可以帮助我们识别和理解 Kubernetes Cluster 中定义的角色和权限。这对于确保适当的访问控制已经到位以及识别潜在的漏洞或错误配置很有用。

     我们可以汇总绑定到 “nigeldouglas” ServiceAccount 的角色。默认情况下，rolesum 查找服务帐户时，无需指定任何标识符。

[leonli@Leon ~ % ]kubectl rolesum nigeldouglas

     另一个潜在的安全优势便是 Rolesum 可以帮助我们快速识别已被授予特定角色或权限的用户和组，这对于解决问题或执行安全评估很有用。

     例如，可以汇总绑定到 “staging” 组的角色，具体如下：

[leonli@Leon ~ % ]kubectl rolesum -k Group staging

     总的来说，Rolesum Kubectl 插件可以帮助我们了解和管理集群中定义的角色和权限，从而成为提高 Kubernetes 集群安全性。

     12、Cert-Manager Plugin

     Cert-Manager 是一个 Kubectl 插件，可在集群内自动管理传输层安全 (TLS) 证书。它允许轻松地为我们的应用程序配置、管理和续订 TLS 证书，而无需手动处理证书签名过程。

     我们可以使用以下 Krew 命令安装 Cert-Manager 插件，具体如下所示：

[leonli@Leon ~ % ]kubectl krew install cert-manager

     使用 Cert-Manager 的一个潜在安全优势是它可以帮助我们确保应用程序使用有效的、最新的 TLS 证书。这对于保护应用程序与其用户之间通信的机密性和完整性非常重要。

     另一个潜在的安全优势是 Cert-Manager 可以帮助我们自动化获取和更新 TLS 证书的过程，这可以降低证书过期或管理不善的风险。

     总的来说，Cert-Manager Kubectl 插件可以帮助我们以安全和自动化的方式管理 TLS 证书，从而成为提高 Kubernetes Cluster 安全性的有用工具。Cert-Manager 插件松散地基于 Kube-lego 的工作，并借鉴了其他类似项目的一些智慧，例如 Kube-Cert-Manager。

     13、Np-viewer Plugin

     Kubectl-np-viewer 插件是一个可视化 Kubernetes 集群网络拓扑的工具。它允许我们以图形格式查看集群内 Pod、Services 和其他 Resource 之间的连接。

     我们可以使用以下 Krew 命令安装 Np-viewer 插件，具体如下所示：

[leonli@Leon ~ % ]kubectl krew install np-viewer

     与我们之前提到的 Cilium 插件不同，Kubectl-np-viewer 插件可以帮助用户理解和可视化集群内的通信模式，而不管使用的是否 CNI 插件。Cilium 插件仅帮助管理 Cilium 资源，例如 Cilium 网络策略。通过查看默认的 Kubernetes 网络策略，开始使用 Kubernetes 网络的团队可以从对潜在漏洞或错误配置的有用可见性中获益，例如与非预期资源通信或暴露在互联网上的 Pod。

     若我们想知道影响当前 Namespace 中特定 Pod 的网络策略规则，那么，可以将其打印出来，具体如下：

[leonli@Leon ~ % ]kubectl np-viewer -p pod-name

     同样，Kubectl-np-viewer 插件的潜在安全优势是它可以帮助用户解决集群内的网络问题。例如，如果我们遇到 Pod 或服务之间的连接问题，那么，可以使用该插件来可视化这些资源之间的连接，并确定所有网络命名空间中的问题根源。

     以下命令打印所有命名空间的所有网络策略规则，具体如下：

[leonli@Leon ~ % ]kubectl np-viewer --all-namespaces

     总的来说，Kubectl-np-viewer 插件可以帮助我们了解和监控集群的网络拓扑，从而成为提高 Kubernetes 集群安全性的有用工具。并非所有企业都已转向高级网络策略实施，例如 Calico 和 Cilium。当用户探索 Kubernetes 网络策略实施时，他们可以更好地了解他们的策略如何使用此安全插件控制集群中潜在的有害或恶意流量。

     14、Ksniff Plugin

     Ksniff Kubectl 插件是一个用于捕获和分析 Kubernetes Cluster 中网络流量的工具。基于此，可用于解决网络问题、监控流量模式和执行安全评估。

     我们可以使用以下 Krew 命令安装 Ksniff 插件，具体如下所示：

[leonli@Leon ~ % ]kubectl krew install ksniff

     使用 Ksniff 的一个好处是它允许我们捕获和分析流量，而无需直接访问 Kubernetes Cluster 中的 Node。这在我们无法直接访问 Node 的情况下，或者我们希望将捕获流量对集群的潜在影响降至最低的情况下很有用。

     另一个优势便是 Ksniff 可用于捕获 Pod 和服务之间的流量，这对于了解应用程序如何在集群内通信很有用。这有助于解决问题、优化性能和识别潜在的安全漏洞。

     总的来说，Ksniff Kubectl 插件可以通过帮助识别和解决与网络相关的问题和漏洞来提高 Kubernetes 集群的安全性。它通过使用现有技术（例如 TCPdump 和 WireShark）嗅探 Kubernetes Pod 来实现这一点。

     15、Inspektor-Gadget Plugin

     Inspektor-Gadget 是最有用的 Kubectl 插件之一。该插件在用户系统中执行，并在集群中部署时作为 DaemonSet 执行。其本质上是一款调试和检查 Kubernetes 资源和应用程序的工具（或小工具）的集合。

     我们可以使用以下 Krew 命令安装 Inspektor-Gadget 插件，具体如下所示：

[leonli@Leon ~ % ]kubectl krew install gadget

     通常情况下，我们可以部署一个或多个小工具，常见的小工具涉及如下：

    （1）建议（为集群生成 seccomp 配置文件和网络策略）

    （2）审计（跟踪 seccomp 配置文件发送到审计日志的系统调用）

    （3）配置文件（通过分布式延迟分析块 I/O ，通过采样堆栈跟踪分析 CPU 性能）

    （4）快照（收集有关正在运行的进程和 TCP/UDP 套接字的信息）

    （5）顶部（按文件定期报告块设备 I/O 活动、eBPF 运行时统计信息和读/写活动）

    （6）跟踪（跟踪从 DNS 查询/响应到触发进程终止的 OOM kill 的几乎所有活动）

     除此之外， Inspektor-Gadget 插件也管理 Kubernetes 集群中 eBPF 程序的打包、部署和执行，包括许多基于 BPF Compiler Collection (BCC) 工具的程序，以及一些专门为在 Inspektor Gadget 中使用而开发的程序。毕竟，借助 Inspektor-Gadget 能够自动将低级内核原语映射到高级 Kubernetes 资源，使查找相关信息变得更加容易和快捷。

     若要根据网络跟踪活动“建议” Kubernetes 网络策略，我们可以运行以下命令，具体如下：

[leonli@Leon ~ % ]kubectl gadget advise network-policy report --input ./networktrace.log > network-policy.yaml

     若要基于 Pod、Namespace、系统调用和代码“审核” seccomp 配置文件，可以运行以下命令，具体如下：

[leonli@Leon ~ % ]kubectl gadget audit seccomp -o custom-columns=namespace,pod,syscall,code

自定义 Kubectl 插件

     当然，除了上述基于 Krew 插件管理器进行封装外，我们也可以使用任何能够用于编写命令行命令的编程语言或脚本进行自定义插件开发。不需要插件安装或预加载，这使得编译这些插件相当简单。

     需要注意的是，必须在 PATH 的某处安装插件可执行文件

     插件脚本参考如下所示：

#!/bin/bash
# optional argument handling
if [[ "$1" == "version" ]]
then    
    echo "1.0.0"    
    exit 0
fi
# optional argument handling
if [[ "$1" == "config" ]]
then    
    echo "$KUBECONFIG"    
    exit 0
fi
echo "I am a plugin named kubectl-sysdig"

     有关构建 Kubectl 插件的完整指南，大家若感兴趣的话，可以查看 Kubernetes 官方文档。

Kubectl 插件的有关思考

     在撰写这篇博文时， Krew 插件管理器目前已支持 210* 个 Kubectl 插件，并且，这些插件能够应用于所有主流平台（如 MacOS、Linux 和 Windows）等，开发/维护人员都可以访问这些 Kubectl 插件并进行使用。虽然这些插件通常解决了对操作任务和安全审计的默认 Kubectl 实用程序的明显限制，但它们也为我们的 Kubernetes Cluster 打开了一系列新的安全漏洞。

     从安全的角度来讲，基于上述所述，我们讨论了最常见、有用的 Kubectl 安全插件，基于这些插件，可以让安全、维护等团队技术人员能够更好地了解 Kubernetes Cluster 中的事件响应和取证。然而，随着我们向环境中添加更多插件，我们也在暴露额外的未经审计的二进制文件，这些二进制文件可能会受到损害。毕竟，Krew 不提供审计这些二进制文件的已知漏洞或不安全配置的义务。

     在实际的业务场景中，我们使用 Kubectl 插件时，往往或多或少会存在一些安全隐患，主要涉及如下：

     1、插件漏洞：如果 Kubectl 插件存在漏洞，攻击者可能会利用它来访问我们所构建的 Kubernetes Cluster 并对其进行尝试性破坏。

     2、不安全的安装：如果插件是从不受信任的来源安装的，它可能包含可能危及集群安全的恶意代码。

     3、权限提升：Kubectl 插件以与 Kubectl 命令相同的权限运行，因此如果插件遭到破坏，它可能会被用于提升权限并获得对集群中敏感资源的访问权限。

     4、数据泄露：如果 Kubectl 插件没有得到妥善保护，它可能会泄露集群中的敏感数据，从而被不法分子利用。

     为了减轻这些风险，重要的是对所构建的插件进行安全扫描，或只安装来自可信来源的 Kubectl 插件，并定期更新和修补已安装的所有关联插件。除此之外，定期检查已安装的插件并删除不再需要的插件也是一个较好的风险规避措施。

     当然，如果我们觉得某个特定的插件不会为所构建的 Kubernetes Cluster 产生较高的价值收益，那么，以防万一，删除它也是一种可取的操作。

     最后，给大家安利一本云原生安全书籍，如下所示，对于搞这块的朋友来说或许有一定的帮助。

     Adiós !