CNCF Adyen 开源 kubectl-rexec 解决什么审计问题

Adyen 的 kubectl-rexec 主要补充进入容器以后，运维人员在 exec 会话中输入了什么这一审计视角。它结合客户端插件、服务端代理和准入控制，将容器访问纳入可记录的路径。它不能凭一份输入日志证明所有程序执行结果，也不会自动让集群满足某项合规要求。

CNCF 在 2026 年 11 月 11 日宣布 Adyen 成为白金终端用户成员时，介绍了这个开源工具及其受审计容器访问定位。公告没有证明它当日才首次开源，也不表示项目已经成为 CNCF 毕业项目。对开发团队更实际的问题是：已有 API 审计之后，它还能补什么材料？

项目官方地址：https://github.com/Adyen/kubectl-rexec

先分清进入容器和容器内操作这两种记录

设想一次测试环境故障调查：记录显示工程师打开了容器 shell，随后应用配置发生变化。仅知道一次 exec 请求被发起，仍不足以还原交互会话中输入过哪些内容。这里是用于说明问题的假设场景，本文没有执行集群实验。

可以先把问题拆开：谁申请访问哪个容器，是访问入口问题；会话里输入了什么，是会话审计问题；输入内容是否真正执行成功、造成什么变化，则还要结合退出状态、应用日志和资源变化判断。kubectl-rexec 重点处理其中的会话访问与输入记录，不能把这三类结论合并。

官方新闻将它描述为支持可审计 kubectl exec 访问的工具，没有公布“安装后自动合规”的结论。新闻入口：https://www.cncf.io/announcements/2026/11/11/cncf-welcomes-adyen-as-platinum-end-user-member-to-advance-open-source-financial-infrastructure/。

代理与准入控制怎样补上访问链路

项目设计文档给出了两个服务端职责。ValidatingWebhookConfiguration 对 Pod exec 请求实施准入限制，允许配置的例外用户及经过 rexec 路径的请求。rexec APIService 接收插件请求，把它转换为普通 exec 请求，在记录的同时代理回 Kubernetes API Server。

设计还说明，原始用户凭据在 API Server 转发时已经移除，代理使用 impersonation 传递用户身份。由此可见，它不是仅靠工程师自愿安装客户端来补日志；准入控制与服务端代理共同构成受控入口。具体身份转发权限必须按所选版本的部署清单配置。

这也解释了一个常见判断偏差：只分发插件、却没有建立相应的服务端限制，不能证明其他 exec 入口也被覆盖。反过来，只限制入口、没有保存代理日志，也无法支撑后续调查。设计文档：https://github.com/Adyen/kubectl-rexec/blob/main/DESIGN.md。

交互输入记录为什么不能当作全部执行事实

项目配置说明区分 TTY 输入的记录方式：启用 --audit-trace 时，TTY 会话记录按键；未启用时，异步审计器按换行等条件合并输入。调节输入缓存相关参数，也会影响记录刷出的方式。因此，运维团队应先确定自己需要原始输入还是便于阅读的合并记录。

但输入内容仍不等于业务效果。别名、脚本、全屏程序以及远端应用行为都会使“看到一行输入”和“知道它造成的全部变化”存在距离。审计时应将输入资料与目标容器、身份、时间、会话标识关联，再结合相关系统记录作判断；不要将日志包装成完整文件变更追踪或系统调用追踪。

配置说明入口：https://github.com/Adyen/kubectl-rexec/blob/main/GUIDE.md。

在测试集群观察一条可关联的审计记录

首次评估应使用一次性测试集群和无敏感数据的容器。官方快速入门会安装代理，并加入禁用普通 kubectl exec 的 webhook，因此不要把快速演示清单直接应用到正在值班的生产集群。项目建议正式安装使用带标签的镜像与适合自身环境的清单。

在按官方说明部署后，可先查看插件帮助，再向自己创建的测试 Pod 执行无副作用命令。下面使用虚构的命名空间和 Pod 名称，替换成实际测试对象；不是本文运行记录。

# 查看插件支持的参数，不向业务容器执行命令
kubectl rexec exec --help

# 仅在自有测试命名空间打印固定文字，观察一次非交互调用
kubectl rexec exec -n audit-lab demo-pod -- printf 'audit-demo\n'

# 查看代理审计事件，测试结束后用 Ctrl+C 停止日志跟随
kubectl -n kube-system logs -l app=rexec -f

观察目标是日志中能否找到这次固定输入，以及对应用户、时间和会话信息，而非仅看到命令输出就宣布审计成功。随后可以在相同测试对象中评估 TTY 输入合并、正常退出、拒绝访问和日志采集情况。每项结果应注明所用客户端、服务端与集群版本。

仓库 README 明确指出该方案处理 WebSocket，不支持 SPDY，并列出 Kubernetes 1.29 的特性开关要求及 1.30 的相关默认行为。部署在更新版本时，仍应按实际客户端、代理与 API Server 组合确认，不把一个最低版本说明当成所有未来版本的兼容承诺。快速入门：https://github.com/Adyen/kubectl-rexec/blob/main/STARTED.md。

采用之前明确可用性与日志保管责任

引入准入限制后，代理和 webhook 成为运维访问路径的依赖。试用记录应覆盖代理不可用时的处理、例外身份的管理、证书与配置更新，以及应急恢复负责人。例外访问要有明确用途和单独记录，避免把它扩大为长期通用入口。

同时，日志可能包含人工输入的敏感内容。建议明确采集范围、查看权限、保留期限与删除责任，并要求工程师避免在交互命令中粘贴秘密。官方快速入门建议配置适合自己的日志转运方案；容器标准输出可以作为采集起点，但不能单独代表长期、安全、不可篡改的审计存储。

这些是本文建议的采用判断项。工具价值在于把会话访问和输入记录做得更可追溯；是否满足组织要求，要由实际覆盖范围、日志管理和运维流程共同决定。

常见问题

有 Kubernetes API 审计还需要 rexec 吗？

取决于调查目标。API 请求记录与交互会话输入资料关注点不同，需要知道容器内输入时，才需要评估这类补充能力。

记录了输入就能确认命令执行成功吗？

不能。还要结合执行状态、应用日志和资源变化，输入记录只提供其中一部分资料。

只安装客户端插件是否足够？

不足以证明访问路径受到约束。项目方案还包含服务端代理与准入控制，并需要日志采集配合。

Adyen 加入 CNCF 代表该工具已通过合规认证吗？

不代表。会员身份、项目开源和组织自身的合规判断是不同事项。