最新资讯
bloomberg.com Nvidia 加强东南亚芯片追踪以打击走私 thestack.technology 模型路由需求升温,Agent Router 推出开源替代方案 unite.ai Cashfree 为 AI Agent 的托管结账加入 WebMCP 工具 dev.to 我们在 DolphinBench 上测试记忆检索:纯关键词搜索暴露了自身回归 dev.to 别再把 Agent 写成 while 循环,把它建模为状态机 analyticsindiamag.com 小语言模型可能重塑企业 AI 部署方式 bloomberg.com Rightmove 与 Scout24 借 AI 产品应对低迷房市并上调展望 stackoverflow.blog 欢迎来到芯片时代:半导体制造、AI 数据中心与芯片设计的未来 www.youtube.com AI Agent 总犯同样的错:CentralAgent AI 将记忆重构为经验系统 pub.towardsai.net Netflix 科学家建议重采样 LLM 评判:5 次仅将误差棒缩小 13% pub.towardsai.net Jev 作为 LLM 前的静默层:构建提示感知的模型路由器 reddit.com OpenAI 称 Astra 仅满足 10% 安全任务标准
多元动态
登录 注册
智能体 dev.to · @James Joyner

Copilot 生成的 Kubernetes 清单通过 schema 校验,却含 21 项安全问题

原文 我的收藏

作者让 Copilot 生成 Deployment 清单,YAML 通过 kubeconform 严格 schema 校验,但策略扫描发现21项问题:文件结构正确,部署本身却存在风险。文章强调结构校验器只检查格式,不判断配置是否安全,建议 schema 检查放入 pre-commit、策略扫描放入 CI,并指出生成清单几乎总会遗漏 readiness/liveness/startup 探针与资源请求。

AI推荐理由 作者以 Copilot 生成的 Deployment 清单通过 kubeconform 严格 schema 校验、却在策略扫描中暴露21项安全问题为例,说明结构校验与安全审查是不同问题,并指出生成清单常缺探针与资源请求;属个人经验分享,但结论对 AI 生成基础设施代码的评审流程有可操作价值。

66

正文

I asked Copilot for a Deployment manifest. It produced valid YAML. kubeconform passed it against the strict schema without a complaint. Then I ran a policy scanner over the same file and got twenty-one findings. Nothing was wrong with the YAML. Everything was wrong with the Deployment. Schema validation and safety are different questions This is the part worth internalising, because it generalises past Kubernetes: a structural validator checks that your file is shaped correctly. It has no opinion about whether the thing you described is a good idea. kubeconform asks "is spec.template.spec.containers[0].image a string?" It does not ask "does this container run as root?" Both tools were doing their jobs. Only one of them was doing the review. Run both. The schema check is fast enough to be a pre-commit hook; the policy scan belongs in CI. The three things generated manifests omit, essentially every time Probes. No readinessProbe, no livenessProbe, no startupProbe. Resource requests and limits. A pod with no requests is scheduled anywhere and evicted first. securityContext. No runAsNonRoot, no allowPrivilegeEscalation: false, no readOnlyRootFilesystem, no dropped capabilities. Those three are the review. If you check nothing else on a generated manifest, check those — and note that a namespace with Pod Security Admission set to restricted will reject the pod at admission rather than at review, which is a much better place to find out. The probe mistake that turns a slow dependency into an outage This one deserves its own section because it is subtle, common, and it fails at exactly the wrong moment. Generated manifests frequently point livenessProbe and readinessProbe at the same endpoint. They look equivalent. They are not — they answer different questions: startupProbe — has it finished booting? readinessProbe — should it receive traffic right now? livenessProbe — is it wedged, and worth killing? If your /health endpoint checks the database, and the database gets slow, then a shared probe means every pod simultaneously fails liveness. Kubernetes responds by restarting your entire deployment during an incident instead of taking the pods out of rotation and letting them recover. Readiness failing is "stop sending me traffic". Liveness failing is "I am beyond saving, kill me". Wiring them to the same check tells the cluster to do the second when you meant the first. --dry-run=client is not offline A very common and wrong assumption, and worth stating plainly because it breaks CI in a confusing way: kubectl apply --dry-run=client -f manifests/ Enter fullscreen mode Exit fullscreen mode This downloads the OpenAPI schema from the API server. With no cluster reachable, it fails outright. It is not a local syntax check, and it is not what you want in a pipeline that has no cluster credentials. Use kubeconform for that. And check your context before every command kubectl config current-context Enter fullscreen mode Exit fullscreen mode Ambient context is how a command meant for staging reaches production. This has nothing to do with AI and everything to do with the fact that generated commands are easy to paste quickly. Where Copilot genuinely helps here Not in producing the manifest — in explaining one. Pointing it at an inherited chart and asking what a particular block does, or why a probe is configured a certain way, is the use case that has consistently earned its keep for me. Reading unfamiliar YAML is slow and there is no glory in it. It is also good at the mechanical transformations: converting a Deployment to a StatefulSet, adding an init container, expanding a Kustomize overlay. The pattern is the same one everywhere: it is strong where the answer is determined by the input, and weak where the answer requires knowing what your cluster is actually like. The fix that outlasts the prompt Put the rules in .github/copilot-instructions.md rather than re-typing them: - Every container sets resources.requests and resources.limits. - securityContext on every pod and container: runAsNonRoot, allowPrivilegeEscalation: false, readOnlyRootFilesystem, drop ALL. - Images pinned by digest, not tag. :latest is not deployable here. - Three probes, and they point at different endpoints. Enter fullscreen mode Exit fullscreen mode That changes what comes back on every request, which re-prompting does not. It supplies information the model did not have rather than asking it to try harder. The longer version — including the full findings list, the NetworkPolicy and PodDisruptionBudget defaults, and the conftest policies — is at GitHub Copilot for Kubernetes Manifests. There is a companion repository with the manifests and the policy tests if you want something to run.

来源报道 · 1 篇 · 以下链接均前往原始媒体

← 返回精选动态 原文

更多内容