Kubernetes看起来很诱人，可以帮助组织解决许多问题！但是任何使用它的人都知道事情会变得多么复杂。Kubernetes的安全性也不例外。
Kubernetes不是默认安全。它有多种攻击途径，并且经常发现CVE。尽管开始使用Kubernetes时会感觉有些不知所措，但是组织可以采取一些具体策略来保护你的服务和基础架构，使组织的系统和应用不受侵害。
首先，让我们大致了解你要保护的生态系统。
- 容器：Kubernetes是一个容器编排系统。因此，任何保护Kubernetes的尝试都必须保护其部署的容器的安全，包括构建和部署容器的流水线。
- Linux和Windows ：容器包含一个操作系统（OS），因此我们必须考虑如何保护OS（无论是Linux，Windows还是两者）。
- Kubernetes：Kubernetes本身既是API服务器，又是同一网络内关于代理和etcd数据库的分布式系统，所有这些都需要得到保护。
使用托管的Kubernetes解决方案（例如云提供商所提供的解决方案）通常可以为你提供更好的默认配置，或者更易于管理的功能。但是如果没有选择正确的配置，它们也是不安全的。
例如，对Kubernetes集群进行身份验证的最安全方法是使用OAuth。但使用托管的Kubernetes解决方案，通常是使用私有客户端证书文件，或用户名和密码的身份验证。
相反，托管的Kubernetes支持配置网络策略的容器网络接口（内部服务有助于通过Kubernetes网络进行容器和Pod通信）。
接下来，让我们看看如何依次保护每个组件。
容器
组织如果需要安全地构建容器，并且必须使用信任的容器镜像在系统中部署运行。
构建
构建安全容器需要扫描它们的漏洞-包括Linux系统软件包以及编程语言（例如Python或Ruby）的应用程序软件包。应用程序开发人员可能习惯于扫描应用程序依赖关系，但是由于他们随应用程序一起交付了整个操作系统，因此在保护操作系统安全方面也必须获得支持。
为了大规模支持这项工作，请考虑使用诸如Cloud Native Buildpacks之类的工具，该工具允许组织或运维团队进行标准化的容器构建，开发人员可以使用它们将其应用程序拖放到其中-完全替换项目的Dockerfile。这些集中化的构建可以保持最新状态，以便开发人员可以专注于自己擅长的方面，而不必手动重复DevOps操作。
容器镜像扫描工具会扫描已构建镜像的各个层以查找已知漏洞，并且检查和保证你的构建和依赖关系是最新的。它们可以在开发过程中以及在CI流水线中运行，从而使开发人员可以最早发现漏洞。最佳做法是将容器降到运行应用程序所需的最低限度。
预防攻击的一个好方法是拥有一个没有shell的容器！
签名
因此，现在你已经构建了安全的容器。但是，如何确定所构建的哪一个容器，是需要部署到集群的容器呢？
Docker支持使用密钥，对镜像签名，然后可以在拉取和部署镜像时对其进行身份验证。签名容器，类似于将TLS证书添加到端点。
通过验证要拉取的容器镜像是否与你的镜推送像完全相同，它可以防止中间人(man-in-the-middle attacks )攻击。为此，你需要在拉取和推送容器镜像双方的系统上，拥有同一个密钥。
下面将介绍，我们检查准入控制器时，如何防止未签名的镜像部署到你的集群中。
Linux
你的容器可能正在运行Linux或Windows，Kubernetes还支持Linux和Windows工作节点的混合。
为了确保你的系统安全，你仍然必须执行传统的工作–以确保仅在必要时才公开服务器，确保SSH凭据安全，确保OS库是最新的以及用户和组权限被锁定。
如果攻击者可以访问你的主节点或工作节点，则他们更容易入侵Kubernetes系统的任何部分-无论是API还是kubelet代理。即使在云原生环境中，仍然需要良好的旧sysadmin工作，无论是将其委派给云提供商还是自己独立完成。
Kubernetes
完整的Kubernetes安全实践，可以出一本书了。但是对于此讨论，最关键的方面是基于角色的访问控制（RBAC），准入控制器和网络策略。
此外，云原生安全平台可以帮助弥补微小漏洞。
RBAC
谁可以在你的集群中做什么？基于角色的访问控制（RBAC）回答了这个问题。
Kubernetes提供了在整个集群中、以及给定名称空间(namespace)中为用户和服务帐户(service accounts)授予特定权限的功能。
一些示例用例，允许所有团队成员查看彼此的应用程序详情，但只能在自己专用的命名空间中进行修改，而只有少数经过审查的人可以删除那里的内容。
这些因组织而异，但是积极管理RBAC对于集群的安全至关重要。
准入控制器(Admission Controllers)
准入控制器（AC）是实现完全Kubernetes安全的唯一方法。除非容器规范满足某些条件，否则AC会阻止容器在集群中调度和运行。AC的种类很多，但其中有两种非常值得使用：PodSecurityPolicy AC和可验证签名镜像的AC。
（PSP）介于攻击者和Kubernetes系统最脆弱的方面之间。例如，Kubernetes中的容器可以要求使用“ hostPath”类型的存储卷（例如Docker套接字）在基础主机上安装任何路径。
挂载Docker套接字的容器，可以在没有特权状态的情况下以root用户身份在主机上运行任何docker命令。太恐怖了！防止这种情况的唯一方法是PSP禁止hostPath卷。PSP设置还可以阻止其他几种重要的攻击路径。如果你仅做一件事来保护集群，则应该创建PSP并启用PSP准入控制器。
之前，我们讨论了如何对你的容器镜像进行签名以建立信任链。如何完成？使用 Open Policy Agent (OPA) AC，可以在允许每个容器镜像进入集群之前检查每个容器镜像是否具备有效签名。还可以参考，结合使用Notary和OPA建立从构建到部署的完整信任链的绝佳指南。
网络策略（Network Policies）
Kubernetes网络策略就像集群的内部防火墙规则一样，应该说明其重要性。他们允许管理员为以下场景配置集群：
- 一个名称空间(namespace)只能与依赖关系所在的另一个名称空间(namespace)通信。
- 外部流量只能到达API网关容器，而不能到达其他容器。
- 除了DNS注册表(DNS registry.)之外的所有容器，禁止其他容器作为网络出口。
如果你是在管理自己的集群，而不是使用云提供商管理的解决方案，则需要研究可用的CNI，以了解NetworkPolicy支持的网络的有效方法。
云原生安全平台
安全形势一直在变化，并且它以惊人的速度发展，在云原生空间中变化甚至更快。即使采取了上述所有步骤，重要的是要对实时运行的内容进行检查以查看异常和违规迹象。诸如像Prisma Cloud这样的平台可以提醒你注意此类异常情况，并可以主动防止意外进程运行和建立网络连接。
译文链接：https://thenewstack.io/kubernetes-security-best-practices-to-keep-you-out-of-the-news/
