现在是安全从业者努力打造自己未来的时候。
译自Secure Your Future in 2024: Grab a Piece of the K8s Security Pie，作者 Brooke Motta。
去年对技术从业者来说是艰难的一年，2023年的裁员量比2022年增加了50%。安全岗位也无法避免这一趋势------最近的研究表明，到2023年年中，22%的安全从业人员曾在裁减安全人才的公司工作过。
而且，如果他们曾在进行裁员的公司工作过，研究表明留下的优秀安全从业人员对自己的工作和职责较不满意。现在是网络安全专业人员确保自己未来的关键时刻，Kubernetes 安全就是可以使你无可替代的秘密武器。
Kubernetes 安全使你的团队无可替代
使自己无可替代的意思是将你的技能与公司收入来源的关键技术相关联。像 Netflix、Domino's Pizza、Slack、Shopify 和 New York Times 这样的公司都在 Kubernetes 环境中运行他们的数字应用。
IBM增长最快的部分是OpenShift，这是 Red Hat 的托管 Kubernetes 平台。多年来，Kubernetes 迁移一直是工程组织的首要任务，这一切都是因为 Kubernetes 允许公司创新速度更快，以传统应用开发方式无法达到的速度开发应用和新功能。
通过影响力最大的同行建立信誉
你影响力最大的同行中，许多都是那些正在工程部门积极构建你的Kubernetes技术栈的人。如果你能够成功地、可信地与他们合作，作为Kubernetes安全的伙伴，那么对他们来说你将是"新一代"安全团队的化身。
为什么？因为如今这些团队不得不指导安全团队，并且牵着那些没有在这方面投资的团队的手。当在KubeCon + CloudNativeCon上询问谁负责Kubernetes安全时，超过三分之一的工程师和网站可靠性工程师(SRE)都表达了安全在Kubernetes方面落后于人的感慨:
- "安全团队在Kubernetes方面存在很大的知识差距。" ------ 一位高级工程师
- "安全技术组还没跟上进度。" ------ 一位SRE
- "安全应该与之并进，但安全对K8s一无所知。" ------ 一位开发人员
而且数据显示，如今只有28%的组织由安全团队负责Kubernetes安全，相比之下，运维、DevSecOps、开发人员和DevOps占72%。
但显然，对许多安全团队来说Kubernetes安全仍然是成功或失败的关键。一家世界500强医疗保健公司的SRE表示，他们的安全团队最终被一个能够在Kubernetes话题上使用相同语言的"更技术化"的团队所替代。
安全团队最需要的地方在哪里？
尽管工程团队正在进行Kubernetes安全，但他们自己的指标和绩效指标包括关于可用性、成本和性能的关键绩效指标(KPI)。出于必要，他们围绕基于角色的访问控制(RBAC)、Kubernetes版本、供应链、网络和常见漏洞和披露(CVE)担任广泛的积极角色。但他们需要一个同谋。
那么，安全团队在哪些方面能从他们的参与中获得最大利益？他们最需要的地方在哪里？如果我们看一下工程师通常花时间的地方(RBAC、Kubernetes版本、供应链、网络和CVE)，很明显，安全需要填补的差距是在没有设置防护栏和向左移动的情况下找到盲点，以及验证工程工作的结果所带来的安全态势。
具体而言，这可能意味着在事故发生时的检测和响应，根据书面政策审计RBAC权限的使用情况，并主动展示为什么某些CVE必须关注，在更广泛的背景下。
2023年针对Kubernetes的有目标攻击也证明了安全团队参与的必要性，据最近的一项研究，仍有17%的团队没有实施DevSecOps。 2023年，出现了大量新的Kubernetes攻击，软件供应链攻击正在寻找kubeconfig文件。 仅2023年就有不下七个新的Kubernetes CVE。
为了防止有目标攻击，发现让它们进入的盲点，安全团队需要介入。
你的工作：成为一个有效的合作者
那么，你如何能够利用这个机会，而不需要花费不切实际的时间成为一个完全的专家呢？答案就是有效而清晰的合作。
合作的第一步是了解"好"是什么样的。在理想的情况下，最一般的层面上，你的工作是理解可能导致重大问题的情况，并与工程团队合作降低重大问题的风险，同时推动业务向前发展。
在实际操作中，安全和工程需要共同努力，了解最敏感的集群，决定什么样的风险会引发对系统运行时间的中断（在最坏的情况下），或者哪些开发者角色应该具有像管理员或集群管理员这样的权限。
知道在Kubernetes安全领域无效的合作是什么样子也很重要。在下面的示例中，尽管安全团队致力于云安全和左移概念，但实际上漏洞管理程序只是在对合规性请求做出响应时才会进行，而在警报传达到工程团队之前，CVE的优先级和警报的优先级并没有确定。
或者检测和响应仍然局限于非容器化的工作负载，比如EDR或xDR解决方案，因此即使工程团队注意到CPU的使用量出现了无法通过自身行为解释的峰值（但可以通过加密挖矿的妥协来解释），也几乎没有关于检测和响应的合作。
结论
Kubernetes安全就像是一个让你发展职业并使自己成为公司前行过程中不可或缺的一部分的开放邀请。它内置了协作者，并需要只有安全团队才能提供的能力。以下是一些开始将这些能力融入你的技能库的方法的示例：
- 开始CNCF的Kubernetes安全认证之一。
- 在你的组织中进行Kubernetes OWASP十大安全漏洞审计。
- 使用像RBAC Police或Krane这样的开源RBAC工具来了解广泛的RBAC权限。
- 开始与工程团队就准入控制的可接受风险基线展开交流。
本文在云云众生（yylives.cc/）首发，欢迎大家访问。