云计算-k8s中pod安全加固

总结了自己工作中常用k8s的pod 安全加固的配置

securityContext

在编写K8s工作负载清单时，无论是pod对象还是部署daemonset之类的更高级别的东西，清单中都有一个名为securityContext的部分，允许您指定应该应用于工作负载的安全参数。

runAsUser, runAsGroup

默认情况下，Docker容器以root用户的身份运行，从安全角度看这并不理想。虽然对容器内部的访问权限仍有限制，但在过去一年中，出现了多个容器loudong，只有在容器以root用户身份运行时才能利用这些loudong，确保所有容器以非root用户身份运行是一个很好的加固步骤。

在基本层面上，在pod清单中配置这个是相当简单的。最好的方法是将security Context中的runAsUser和runAsGroup字段设置为非0值。

在执行此操作时，重要的是要确保容器在以非root用户身份运行时能够正常工作。如果原始容器镜像被设计为以root身份运行，并且有限制性的文件权限，可能会导致应用程序的运行出现问题。

最好的办法是确保在容器的Dockerfile中设置相同的UID/GID组合，以便在整个开发和测试过程中使用该组合运行。可以通过在Dockerfile中设置USER指令来做到这一点。按照上面的示例，此行将设置相同的 UID和GID组合：

Privileged

Docker和类似的容器运行时提供Privileged标志，作为从容器中移除安全隔离的便捷方法。这不应该在应用工作负载中使用，而应该只在完全必要的情况下使用。

一般来说，Linux容器有相当灵活的安全模型，因此如果容器的运行需要特定的权限，则可以添加该权限，而无需使用总括Privileged设置。

在设计容器清单时，关键是在每个清单的 securityContext 中默认将 privileged 设置为 false，这样就可以清楚地看到它应该在没有这些权限的情况下运行。

Capabilities

Linux能力是用于为进程提供传统上为root用户保留的一个或多个方面的权限。默认情况下，Docker和其他容器运行时将为容器提供可用能力的子集。

一个好的加固步骤是仅允许应用程序特别需要的能力。如果你的应用程序设计为以非root用户身份运行，那么它根本不需要任何能力。

一般来说，对能力的处理方法应该是首先删除所有的能力，如果你的应用需要这些能力，再把特定的能力加回来。举个例子，如果你需要CHOWN能力，你会有这样的securityContext

Read Only Root File system

可以使用这个设置来利用容器的短暂性。通常，运行中的容器不应该在容器文件系统中存储有关应用程序的任何状态。这是因为它们可能随时被降速并在集群的其他地方创建新版本。

在这种情况下，你可以在工作负载清单中设置readOnlyRootFilesystem标志，这将使容器的根文件系统成为只读。

与此设置有关的一个常见问题是如何处理应用程序进程运行时需要的临时文件。处理这些的最佳方法是在容器中挂载一个 emptyDir 卷，允许文件被写入某个位置，然后在容器被销毁时自动删除。

设置 readOnlyRootFilesystem 是 securityContext 中一个简单的布尔值。

AllowPrivilegeEscalation

Linux内核公开的另一个安全设置，这通常是一个很好的、低影响的加固选项。此标志控制子进程是否可以获得比其父进程更多的权限，对于在容器中运行的应用进程来说，它们的运行很少需要这样做。

Seccomp

Seccomp配置文件可以阻止访问可能导致安全风险的特定Linux系统调用。默认情况下，Docker等容器运行时提供了一个系统调用过滤器，可以阻止对一些特定调用的访问。但是，在K8s下运行时，该过滤器在默认情况下是禁用的。

因此，确保重新启用过滤器是对工作负载清单的重要补充。你可以使用运行时的默认配置文件，或者（如AppArmor和SELinux）提供一个自定义的配置文件。

seccomp过滤器可以在两个地方重新启用，这取决于你所使用的K8s版本。在1.18及以下版本中，与AppArmor一样，通过清单元数据部分的注释来完成。示例注释如下：

Resource limits

由于K8s工作负载共享底层节点，因此确保单个容器不能使用节点上的所有资源非常重要，这可能会导致集群中运行的其他容器出现性能问题。在容器层面，可以设置资源限制，指定容器所需的资源数量以及允许的资源数量限制。

一个容器资源请求的示例如下。这不是在 securityContext 中设置的，而是在通用容器规范中设置的。

容器安全策略

容器组安全策略可以限制容器组中的容器使用哪些特权或功能，以及规定容器组中的容器如何运行，平台基于 PSA（Pod Security Admission）实现了更加细粒度的容器组安全策略。它定义了三种安全安全模式和安全标准：

详细介绍，参考官网

https://kubernetes.io/zh-cn/docs/concepts/security/pod-security-standards/

安全模式

安全模式：Kubernetes 中的安全模式（Security Mode）是一种控制安全策略的机制，用于定义 Kubernetes 如何处理违反安全策略的容器组,分为以下三种

• Enforce 模式：当容器组违反了安全策略时，Kubernetes 将拒绝该容器组的创建或修改，并返回错误信息，适合对安全要求较高的生产环境使用。
• Audit 模式：当容器组违反了安全策略时，Kubernetes 将记录该事件，并将记录存储在审计日志中。这种模式通常用于了解集群中的安全事件，以便进行后续的调查和分析。
• Warn 模式：当容器组违反了安全策略时，Kubernetes 将允许该容器组的创建或修改，并返回警告信息。这种模式通常用于测试或过渡期，以便管理员可以逐步调整安全策略而不会对应用程序造成影响。

安全标准

od 安全性标准定义了三种不同的策略（Policy），以广泛覆盖安全应用场景

• Privileged 标准：容器组中的容器拥有特权访问，允许所有操作，没有任何限制。
• Baseline 标准：限制容器组中的容器使用宿主机的命名空间、网络、文件系统、进程等。这是一种默认的安全标准，通常适用于大多数场景。
• Restricted 标准：进一步限制容器组中的容器使用宿主机的资源，包括限制容器使用文件系统、网络等。这是一种高度安全的标准，适用于对安全性要求非常高的场景。 这些安全标准可以通过 Kubernetes 中的 Admission Controller 对容器组进行验证，以确保容器组中的容器不会破坏 Kubernetes 集群的安全性。

针对不同级别的容器应用，选择对应的模式和标准即可