摘要：云原生计算基金会(CNCF)"发布的一篇博客文章"指出，企业在Kubernetes"上部署大语言模型(LLM)时存在一个关键的安全缺口，那就是尽管Kubernetes擅长编排和隔离工作负载，但它本身无法理解或控制AI系统的行为，由此形成了一类完全不同且更为复杂的威胁模型。博客指出，当前正在出现对“AI感知型平台工程”的需求，即把安全同时嵌入基础设施层和应用层。CNCF的分析对那些正在Kubernetes上快速采用AI的组织发出了警示：运行健康不等于安全。
云原生计算基金会(CNCF)"发布的一篇博客文章"指出，企业在Kubernetes"上部署大语言模型(LLM)时存在一个关键的安全缺口，那就是尽管Kubernetes擅长编排和隔离工作负载，但它本身无法理解或控制AI系统的行为，由此形成了一类完全不同且更为复杂的威胁模型。
文章认为，LLM引入了一类新的风险，因为它们处理的是不受信任的输入，并且能够动态决定行动方式，这与传统应用不同。在典型部署中，例如，通过API或聊天界面暴露一个LLM，Kubernetes可以保证Pod运行正常、资源状态稳定，但它无法感知提示词是否是恶意的、敏感数据是否泄露，或模型是否以不安全方式与内部系统交互。这会导致一种糟糕的局面，那就是，基础设施表面健康，而底层风险却未被发现。
CNCF强调，基于LLM的系统必须被视为可编程、可决策的实体，而不仅仅是计算工作负载。当组织把LLM置于内部工具、日志、API或凭据之前时，实际上是引入了一个可被提示词输入影响的新抽象层。这会打开一系列风险入口，例如，提示词注入、意外数据暴露以及对已连接工具的滥用，而这些威胁并非传统Kubernetes安全控制最初所要解决的问题。
这种转变反映了云原生系统更广泛的演进：Kubernetes正越来越多地被用于运行AI和生成式工作负载。随着采用规模的增长，这个平台正在从最初管理无状态微服务的定位，被扩展到编排数据密集型、智能体驱动和推理密集型系统。然而，安全模型尚未完全跟上这些新场景。
虽然Kubernetes为调度、隔离和资源管理提供了强有力的基础能力，但它缺乏对AI系统施加应用层或语义层控制的内置机制。比如，它无法判断一个提示词是否应被执行、一个响应是否泄露敏感信息，或某个LLM是否应访问特定工具或API。
这种局限凸显了在基础设施之外增加额外控制层的必要性。传统Kubernetes安全实践，如RBAC"、网络策略和容器隔离，依然是必要的，但单独使用它们还不够。组织还必须引入AI特定的控制，包括提示词校验、输出过滤、工具访问限制以及应用层策略执行。
博客指出，当前正在出现对“AI感知型平台工程”的需求，即把安全同时嵌入基础设施层和应用层。这包括引入诸如OWASP Top 10 for LLMs"之类框架、落实策略即代码（policy-as-code），并建立约束模型与数据和外部系统交互方式的护栏机制。
行业讨论正越来越多地将其定义为：从传统威胁模型转变为行为与上下文感知的安全模型。关注点不再只是保护基础设施本身，而是控制智能系统在其中的行为。随着LLM演进为可执行动作的自治或Agentic系统，这些问题会变得更加重要。
CNCF的分析对那些正在Kubernetes上快速采用AI的组织发出了警示：运行健康不等于安全。一个系统即便完全符合Kubernetes的最佳实践，也仍可能通过其AI层暴露出明显的风险。
主要技术与安全厂商正在收敛到相似的原则。行业指南"越来越多地建议采用多层安全模型，结合运行时监控、human-in-the-loop控制，以及围绕AI系统可执行动作的严格策略约束。一个一致观点是，LLM绝不能被当作权威决策者，而必须在有边界的上下文中运行，并具备明确的护栏、持续验证和可审计性。
随着LLM采用加速，行业正被迫重新思考关于信任边界、工作负载隔离和应用行为的长期假设。由此形成的结果是一个新的安全范式：Kubernetes仍是基础层，但必须叠加AI特定的治理、可观测性与控制机制，才能确保智能系统的安全可靠部署。
原文链接：
CNCF Warns Kubernetes Alone Is Not Enough to Secure LLM Workloads"
暂无回复，快来抢沙发吧！
本次需消耗银元：
100
当前账户余额: 0 银元
云原生计算基金会(CNCF)"发布的一篇博客文章"指出，企业在Kubernetes"上部署大语言模型(LLM)时存在一个关键的安全缺口，那就是尽管Kubernetes擅长编排和隔离工作负载，但它本身无法理解或控制AI系统的行为，由此形成了一类完全不同且更为复杂的威胁模型。
文章认为，LLM引入了一类新的风险，因为它们处理的是不受信任的输入，并且能够动态决定行动方式，这与传统应用不同。在典型部署中，例如，通过API或聊天界面暴露一个LLM，Kubernetes可以保证Pod运行正常、资源状态稳定，但它无法感知提示词是否是恶意的、敏感数据是否泄露，或模型是否以不安全方式与内部系统交互。这会导致一种糟糕的局面，那就是，基础设施表面健康，而底层风险却未被发现。
CNCF强调，基于LLM的系统必须被视为可编程、可决策的实体，而不仅仅是计算工作负载。当组织把LLM置于内部工具、日志、API或凭据之前时，实际上是引入了一个可被提示词输入影响的新抽象层。这会打开一系列风险入口，例如，提示词注入、意外数据暴露以及对已连接工具的滥用，而这些威胁并非传统Kubernetes安全控制最初所要解决的问题。
这种转变反映了云原生系统更广泛的演进：Kubernetes正越来越多地被用于运行AI和生成式工作负载。随着采用规模的增长，这个平台正在从最初管理无状态微服务的定位，被扩展到编排数据密集型、智能体驱动和推理密集型系统。然而，安全模型尚未完全跟上这些新场景。
虽然Kubernetes为调度、隔离和资源管理提供了强有力的基础能力，但它缺乏对AI系统施加应用层或语义层控制的内置机制。比如，它无法判断一个提示词是否应被执行、一个响应是否泄露敏感信息，或某个LLM是否应访问特定工具或API。
这种局限凸显了在基础设施之外增加额外控制层的必要性。传统Kubernetes安全实践，如RBAC"、网络策略和容器隔离，依然是必要的，但单独使用它们还不够。组织还必须引入AI特定的控制，包括提示词校验、输出过滤、工具访问限制以及应用层策略执行。
博客指出，当前正在出现对“AI感知型平台工程”的需求，即把安全同时嵌入基础设施层和应用层。这包括引入诸如OWASP Top 10 for LLMs"之类框架、落实策略即代码（policy-as-code），并建立约束模型与数据和外部系统交互方式的护栏机制。
行业讨论正越来越多地将其定义为：从传统威胁模型转变为行为与上下文感知的安全模型。关注点不再只是保护基础设施本身，而是控制智能系统在其中的行为。随着LLM演进为可执行动作的自治或Agentic系统，这些问题会变得更加重要。
CNCF的分析对那些正在Kubernetes上快速采用AI的组织发出了警示：运行健康不等于安全。一个系统即便完全符合Kubernetes的最佳实践，也仍可能通过其AI层暴露出明显的风险。
主要技术与安全厂商正在收敛到相似的原则。行业指南"越来越多地建议采用多层安全模型，结合运行时监控、human-in-the-loop控制，以及围绕AI系统可执行动作的严格策略约束。一个一致观点是，LLM绝不能被当作权威决策者，而必须在有边界的上下文中运行，并具备明确的护栏、持续验证和可审计性。
随着LLM采用加速，行业正被迫重新思考关于信任边界、工作负载隔离和应用行为的长期假设。由此形成的结果是一个新的安全范式：Kubernetes仍是基础层，但必须叠加AI特定的治理、可观测性与控制机制，才能确保智能系统的安全可靠部署。
原文链接：
CNCF Warns Kubernetes Alone Is Not Enough to Secure LLM Workloads"