一文读懂最佳 Kubectl 安全插件（上）

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 !