K8s security risks and challenges
Overlooked issues due to mass deployment of containers
While containers are fast and portable, they also present security blind spots that increase the attack surface. Maintaining visibility into cloud infrastructure components becomes increasingly difficult as containers are deployed in large numbers. The distributed nature of containerized applications can make it difficult to quickly discover which containers are vulnerable or misconfigured.
Misuse of mirrors and mirror registries creates security issues
Organizations must have effective governance policies for mirrors and trusted mirror registries. We need to ensure that container images are built using regularly scanned, safe, approved base images and only use images from whitelisted image registries to start containers in Kubernetes environments.
Containers communicate with each other and with other endpoints
During deployment, containers and pods need to communicate with each other and with other internal and external endpoints to function properly. If a container is compromised, the scope of the environment an attacker can affect is directly related to the communication scope of that container, which means that other containers communicating with that container, as well as Pods, may be compromised. In large container environments, manual configuration is complex, and network segmentation can be difficult.
K8s has a wealth of configuration options, but the defaults are often insecure
Based on DevOps principles, Kubernetes is designed to speed application deployment and simplify management and operations, while providing a rich set of controls for effectively securing the cluster and its applications. Examples include Kubernetes network policies, which are similar to firewall rules and control how pods communicate with each other and with other endpoints. When a network policy is associated with a pod, the pod can only communicate with the targets defined in the network policy. But by default, Kubernetes does not apply network policies to Pods, which means that every Pod can communicate with other Pods in a Kubernetes environment.
Another configuration risk has to do with secret management: how sensitive data (such as credentials and keys) is stored and accessed. We need to make sure that the secret information is not passed as an environment variable, but placed in a read-only volume of the container.
Containers and Kubernetes pose compliance challenges
Cloud-native environments also present challenges in complying with security best practices, industry standards and benchmarks, and internal organizational policies. In addition to maintaining compliance, organizations must show proof of that compliance. We want to align strategies to ensure that the Kubernetes environment conforms to specifications originally written for traditional application architectures. At the same time, the distributed and dynamic nature of containerized applications means that compliance monitoring and auditing can only be done at scale when automated.
Container operations present common and new security challenges
One security advantage of containers and Kubernetes is that they can be thought of as immutable infrastructure, in that applications should not be patched or changed at runtime, but removed from a common template and recreated on update.
Additional properties of containers present unique challenges, such as their rapid creation and deletion. When we detect a potential compromise in a running container, not only do we have to stop the container and restart the uncorrupted version, we must also ensure that the fixes are applied to the new container image to safely reconfigure the application.
Other security risks include running compromised containers with malicious processes. Cryptomining is a common tactic for attackers who compromise container environments, but they can also perform other malicious processes through compromised containers, such as scanning network ports for vulnerabilities, among other things. To address the Kubernetes security challenges listed above, developers need to integrate security into every stage of the container lifecycle: build, deploy, and run. We must build secure images, deploy configurations following best security practices, and protect workloads from threats at runtime.
Finally, we also need to protect the Kubernetes infrastructure and its components, including the Kubernetes API Server, etcd, etc., which can themselves be attacked and thus increase the overall attack surface.
构建阶段
保护容器和 Kubernetes 的安全要从构建阶段开始，此时花费的时间将在将来获得回报，如果开始就没做好安全实践，后面将付出极大的修复成本。现在要做的两件事就是构建安全镜像，然后扫描这些镜像查找已知漏洞。
1）使用最小的基础镜像
避免将镜像与 OS 软件包管理器或 Shell 一起使用，因为它们可能会有未知漏洞。如果必须要使用 OS 软件包，请在后面的步骤中删除软件包管理器。
2）不要添加不必要的组件
确保从生产中的容器中删除 debug 工具。镜像中不要有对攻击者有用的通用工具（例如 Curl）。
3）使用最新镜像
确保镜像以及任何第三方工具都是最新的，并使用其最新版本的组件。
4）使用镜像扫描识别已知漏洞
镜像扫描能够识别镜像中的漏洞，并提示漏洞是否可修复。另外，它能够扫描 OS 软件包和第三方运行库中的漏洞，以查找容器化应用程序中使用的程序语言漏洞。
5）将安全性集成到 CI/CD 管道中
让镜像扫描和其他安全检查成为 CI/CD 管道的一部分，这样在扫描程序检测到严重的可修复漏洞时，可以自动执行安全保护并使 CI 构建失败同时生成警报。
6）标记无需修复的漏洞
如果没有已知漏洞的修复程序，或者该漏洞不是关键漏洞，在这种不用立即修复的情况下，将它们添加到白名单或在扫描中过滤，这样就不会被不必要的警报中断工作流程。
7）实施纵深防御
在容器镜像或使用该镜像运行的部署中发现安全问题时，确保准备好策略检查和修复工作流程来检测和更新这些镜像。
部署阶段
在部署工作负载之前，应该配置好 Kubernetes 基础设施。从安全角度来看，我们首先要了解正在部署的内容以及部署的方式，然后识别并应对违反安全策略的情况，至少应该知道：
正在部署的内容——包括使用镜像的有关信息，例如组件、漏洞以及将要部署的 Pod
将在哪里部署——哪些集群、命名空间和节点
部署方式——是否以特权方式运行，可以与其他哪些部署进行通信
可以访问的内容——包括 secret、卷和其他基础结构组件，例如主机或 orchestrator API
是否符合要求——是否符合策略和安全要求
有了这些信息，我们就可以开始针对需要修复和加固的区域，并进行适当的分段。
8）使用命名空间隔离敏感的工作负载
命名空间是 Kubernetes 资源的关键隔离方式。它们为网络策略、访问控制和其他重要的安全控制提供了参考。将工作负载分到不同的命名空间可以遏制攻击，并限制授权用户的错误或破坏性操作的影响。
9）使用 K8s 网络策略来控制 Pod 和集群之间的流量
默认情况下，Kubernetes 允许每个 Pod 与其他 Pod 通信。网络分段策略是一项安全控制措施，可以防止攻击者闯入后跨容器横向移动。
10）防止过度访问 secret 信息
确保部署时仅安装其实际需要的 secret，以防止不必要的信息泄露。
11）评估容器使用的特权
赋予容器的功能、角色绑定和权限集会极大影响安全风险。我们最好遵守最小特权原则，只提供容器执行其预期功能的最小特权和功能。Pod 安全策略是一种控制 Pod 与安全相关属性的方法，包括容器特权级别，可以使操作人员指定以下内容：
不要以超级用户身份运行应用程序进程
不允许特权升级
使用只读的根文件系统
使用默认的 masked/proc 文件系统挂载
不要使用主机网络或进程空间
删除不使用和不必要的 Linux 功能
使用 SELinux 获得更细粒度的过程控制
为每个应用程序分配自己的 Kubernetes 服务帐户
如果不需要访问 Kubernetes API，就不要在容器中保存服务帐户凭据
12）评估镜像来源
不要通过未知来源的镜像部署代码，仅使用已知或列入白名单的注册中心镜像。
13）将镜像扫描扩展到部署阶段
扩展镜像扫描到部署阶段，并根据扫描结果执行策略。有种执行方式是使用 Kubernetes 的 Validation Admission Controller 功能，当没有扫描结果、镜像有严重漏洞或者是 90 天前构建的，Kubernetes 会拒绝进行部署，因为近期未扫描的镜像可能会包含上次扫描披露的新漏洞。
14）适当使用标签和注释
使用负责应用程序团队的名称、电子邮件别名或 Slack Channel 为部署添加标签或注释，这将提醒负责团队更加注意安全性问题。
15）启用 Kubernetes 基于角色的访问控制（RBAC）
RBAC 提供了一种方法，用于控制集群中用户和服务帐户访问集群的 Kubernetes API 服务授权。
接下来是在运行时阶段保护 Kubernetes 工作负载的建议。
运行阶段
运行阶段的容器化应用程序又会面临许多新的安全挑战。我们既要获得运行环境的可见性，又要在威胁出现时对其进行安全检测和快速响应。在构建和部署阶段主动保护容器和 Kubernetes 部署可以大大减少运行时发生安全事件的可能性以及响应这些事件而进行的后续工作。首先，我们必须监视与安全性最相关的容器活动，包括：
进程活动情况
容器服务之间的网络通信
容器化服务与外部客户端和服务器之间的网络通信
由于容器和 Kubernetes 具有声明性，因此在容器中观察容器行为来检测异常通常比在虚拟机中更容易。
16）利用 Kubernetes 中的上下文信息
使用 Kubernetes 中构建和部署的时间信息来评估运行时观察到的活动与预期活动，以检测可疑活动。
17）将漏洞扫描扩展到正在运行的部署
除了扫描容器镜像中存在的漏洞之外，还需要监控正在运行的部署中是否有新发现的漏洞。
18）使用 Kubernetes 内置控件以加强安全性
配置 Pod 的安全上下文以限制其功能。这些控件可以消除依赖特权访问的整个攻击类别。例如，只读根文件系统可以防止任何依赖于安装软件或写入文件系统的攻击。
19）监视网络流量，限制不必要或不安全的通信
观察应用网络流量并将该流量与基于 Kubernetes 网络策略所允许的流量进行比较。容器化的应用程序通常会大量使用集群网络，因此观察应用网络流量是了解应用程序交互并识别意外通信的好方法。同时，将应用流量与允许的流量进行比较，可以提供一些有价值的信息。通过这些信息，我们可以进一步收紧网络策略，以消除多余的网络连接并减少攻击面。
20）利用进程白名单
进程白名单是一种用于识别意外运行进程的有效做法。首先，观察应用程序一段时间，将应用程序正常过程中执行的所有进程加入列表，然后将该列表用作针对将来应用程序行为的白名单。
21）比较和分析相同部署的 Pod 不同运行时的状态
出于高可用性、容错性或规模等原因，容器化的应用程序常被用于复制。复制的应用应该大致相同，所以与其他副本有明显差异的副本要进一步调查。
22）如果被破坏，将可疑 Pod 数量减少至零
通过 Kubernetes 控制器将可疑 Pod 数量减少至零或者杀死，然后重新启动被破坏的应用程序实例。
基础设施安全
上文专注于以构建、部署和运行工作负载时的安全实践，但是安全性还需要扩展到镜像和工作负载之外，直到整个环境，包括集群基础结构。我们同时要保证集群、节点和容器引擎的安全。
23）将 Kubernetes 更新到最新版本
Kubernetes 仅支持最近的三个版本，因此如果在 Kubernetes 中发现了一个严重漏洞，并且落后四个版本，那么我们将不会收到补丁。
24）安全地配置 Kubernetes API Server
确保已经禁用未经身份验证的匿名访问，并使用 TLS 加密对 kubelet 和 APIServer 之间的连接。
25）etcd 的安全
etcd 是 Kubernetes 用于数据访问的键值存储。etcd 被认为是 Kubernetes 的信任来源，我们可以根据需要从中读取数据或将数据写入其中，另外要确保仅通过 TLS 提供客户端连接。
26）kubelet 的安全
作为在每个节点上运行的主节点代理，kubelet 的错误配置会使攻击者可以通过 kubelet 进行后门访问。通过使用 --anonymous-auth=false 启动 kubelet，并利用 NodeRestriction 准入控制器限制 kubelet 可以访问的内容，确保已禁用对 kubelet 的匿名访问。
Kubernetes 还有很多组件，包括 kube-scheduler、kube-controller-manager、主节点和工作节点上的配置文件等，都可以帮助安全配置。
实施 K8s 的安全
容器和 Kubernetes 的出现并没有改变安全需求，我们的目标仍是使攻击者难以入侵应用程序及其基础设施，如果被入侵，就要尽快阻止，但是，这些工具和方法必须适应 DevOps 实践和云原生原则的需求。
27）将安全更早地嵌入到容器的生命周期中
我们必须尽早将安全集成到容器的整个生命周期中，并确保安全性和 DevOps 团队保持一致。这样开发人员和 DevOps 团队才能放心地构建和部署具有生产级规模、稳定性和安全性的应用程序。
28）使用 Kubernetes 原生安全控制来降低运营风险
尽可能利用 Kubernetes 内置控件来实施安全策略，这样安全控件就不会与编排工具发生冲突。例如，不要使用第三方代理或 shim 来进行网络分段，而应使用 Kubernetes 网络策略来确保安全的网络通信。
29）按优先级进行补救工作
在庞大的 Kubernetes 环境中，手动筛选安全事件非常耗时。如果具有高风险漏洞或是包含特权容器并且对互联网开放的部署，那应该上移修复优先级；如果是在测试环境，并且是支持非关键应用程序的，那就将其修复优先级下移。Original article: Kubernetes Security Risks and 29 Best Practices