优化开发人员对 K8s 安全的影响

2022-11-14
北京
本文字数：1899 字
阅读完需：约 6 分钟

Kubernetes 已经发展过了 8 年的历程。在发展的时间里，DevSecOps 的不断兴起逐渐地将安全性左移。这种演变继续增加软件工程师的工作量，当前软件开发工程师的案头已经堆满了 Kubernetes 的复杂性。虽然容器编排在事实上已经是成熟的企业级解决方案，但 Kubernetes 的安全控制仍然会阻碍开发人员管理和控制生产集群或命名空间。在 Kubernetes 的早期，开发团队通常自己操作 Kubernetes 集群。随着 Kubernetes 工作负载变得更加关键，这种做法被取代；开发人员现在通常负责工作负载的安全性，而平台工程师负责 Kubernetes 平台的安全性。

然而，安全左移在 Kubernetes 工作负载和集群之间创建了一个新的攻击面和安全类别。将工作负载部署到集群的持续交付管道和 GitOps 模型可以为攻击者提供这些中间目标。

开发人员了解依赖关系

现代应用程序依赖大量第三方开源依赖项来构建其功能。这对于开发现代应用程序非常常见，但它也使工作负载安全性复杂化。组织通常在这些开源技术方面没有深厚的内部专业知识。传递依赖会增加这种复杂性，因为主要的开源项目本身可能建立在数十或数百个开源依赖之上

为了解决这个问题，开发人员正在从制造业中汲取灵感，采用软件物料清单 (SBOM) 运动，对依赖项进行分类，并使用将依赖项与已知漏洞联系起来的工具。该策略通过使开发人员能够识别、解决问题并确定优先级来提供优势——尤其是当部署的生产应用程序中存在需要紧急修复的漏洞时。

访问控制与开发者的可见性

环境之间的一致性是 Kubernetes 的一个重要特性，它使 Kubernetes 清单能够轻松地在任何集群上创建和命令资源。然而，从安全的角度来看，开发人员可以轻松地行使他们的权力来改变 Kubernetes 环境，这导致了更大的访问限制。例如，组织经常拒绝开发人员访问 kubectl 进行生产部署，并不允许工作负载的开发者成为其部署者。

同时，Kubernetes 和微服务使得应用程序的功能由许多细粒度的部署和服务创建，所有这些都相互通信。恶意攻击活动可能隐藏在这些通信中，需要大量的网络策略以及保护容器安全的规则。随着安全性向左转移，这些策略越来越多地在 Kubernetes 清单中实施和管理，而不是通过网络或基础设施工程。让开发人员能够访问数据和指标，让他们能够了解服务部署和通信，这对于成功的应用程序安全性至关重要。组织应部署基于角色的访问控制来保护开发人员行为的工具，同时允许访问生产应用程序日志而无需更改代码或重新部署。

强化服务通信

鉴于攻击一般通过入口或出口进入，并有随着服务间通信而升级的风险，Kubernetes 应用程序安全需要适当地强化所有输入和输出。引入安全的入口和出口策略并强制执行安全最佳实践非常重要，同时还应注意不要影响开发人员的 DevSecOps 体验。

来自外部应用程序用户的响应涉及多个服务，需要精心定制的安全性。当然，处理公共流量的服务应该接受所有流量。与登录或身份验证服务通信的服务应该只与该服务直接通信，而不通过外部连接。

通过 DevSecOps 提升开发者体验

开发人员文化和组织中开发人员体验的质量会影响员工工作效率、工作满意度、进而影响到招聘和留住人才再到长期竞争力的方方面面。数字化转型从来都不是一个单一的内容，而是一个不断改进的过程。该过程的连续性取决于留住知识渊博的资深开发人员并使他们全心全意地投入工作。建立高效的 DevSecOps 环境可以帮企业吸引更多的新人才，建立积极、高效和愉快的开发体验是组织保持竞争力的基础。

Kubernetes 复杂性带来的压力，以及不优雅的 Kubernetes 安全方法很可能就会地拖累生产效率，进而很可能会影响开发人员的工作热情。开发人员的工作中不必要的负担越少，他们就会越快乐。如果需要花大量的精力在处理 K8s 环境带来的安全管理工作，不停的在不同环境切换，处理不同的配置和规则，那必然就会带来负面影响。

企业应当着手去从根本上考虑和解决这个问题，建立可以融合开发人员经验和使用诉求，同时充分覆盖 K8s 安全需要的 DevSecOps 体系，可以简化安全性，让安全和开发人员的工作贴得更近，并帮助定义一种让开发人员感到支持和满足的体验。

虽然开发人员在保护 Kubernetes 方面发挥着关键作用，但繁琐或超出开发人员工作范畴的繁琐策略和任务只会导致不满和更差的安全性。相反，将优雅的开发人员体验作为 DevSecOps 目标的一部分会带来全面的回报，使开发人员能够做他们最擅长的事情——无论是为 K8s 安全性还是应用程序开发做出贡献。