上篇翻译文章介绍了kubernetes，这篇文章介绍了kubernetes的安全性
https://www.tigera.io/learn/guides/kubernetes-security/
Kubernetes 安全风险
受损图像和图像注册表
为确保映像的安全性，组织应实施强有力的治理策略，以确保映像安全地构建并存储在受信任的注册表中。例如，组织应确保使用预先批准的安全基础镜像构建容器镜像，并定期扫描这些镜像以查找问题和漏洞。
组织应通过创建允许使用的图像注册表列表来标准化注册表。在用于在 Kubernetes 集群中创建容器之前，应始终扫描图像，以避免篡改。
受损容器或恶意流量
作为正常操作的一部分，容器和 Pod 需要相互通信。但是，这种通信可以被威胁参与者利用。被破坏的容器可能会影响其他容器和 pod。
为确保通信安全，组织应制定网络策略，将通信限制在工作负载正常运行所需的最低限度。这包括集群内的南北向流量（入口/出口流量）和东西向流量。网络策略应自动调整，以确保它们不会损害生产力。
缺乏能见度
可见性对于确保维护安全至关重要。但是，在复杂的分布式容器化环境中实现可见性可能具有挑战性。
- 可能有大量容器被调度、部署和终止——所有这些都需要被跟踪、监控和管理。
- 容器化工作负载的分布式和动态特性使得收集、跟踪和理解相关指标变得困难。
- Kubernetes 可以部署在多云或混合云环境中。每个云供应商都提供自己的监控和可见性工具，因此很难实现跨环境的一致可见性。
在没有可见性的情况下保护应用程序可能很困难，甚至是不可能的。如果没有可见性，就不可能在威胁者利用它们之前检测到关键漏洞或发现错误配置。可见性对于在运行时监控容器以检测攻击以及跟踪不再使用的容器以便在它们成为责任之前适当地淘汰它们也至关重要。
不安全的默认配置
Kubernetes 旨在加快应用程序的部署并简化操作和管理。虽然 Kubernetes 提供了广泛的控件来帮助组织有效地保护集群和应用程序，但它并没有提供开箱即用的安全配置。
例如，Kubernetes 网络策略的行为类似于防火墙规则，控制 pod 如何相互通信以及与其他端点通信。一旦为 Pod 分配了网络策略，它就只能与网络策略中声明的资产进行通信。但是，Kubernetes 默认情况下不会将网络策略应用于 pod。这意味着在部署后，所有 pod 都可以与 Kubernetes 环境中的所有其他 pod 通信。这使得确保所有集群资源都定义了适当的安全策略变得至关重要。
另一个问题是秘密管理。机密定义了如何访问和存储敏感信息，如密钥和凭据。在管理机密时，确保它们不被用作环境变量或在图像中硬编码是至关重要的。秘密应该在容器外部进行管理，并通过仔细的访问控制来保护秘密免受未经授权的各方的侵害。
合规挑战
对于许多组织而言，合规性是一个关键问题。在云原生环境中实现合规性是一项极具挑战性的工作。为了实现合规性，组织通常需要实施某些安全措施。这通常需要执行最佳实践、基准和行业标准，以及内部组织政策。
除了定期保持合规性外，组织还需要提供合规性证明。这需要可见性、监控和日志——执行审计所需的数据。为了确保审计人员能够访问数据或系统，组织需要强大的功能，而这些功能不一定由普通的开源 Kubernetes 提供。
云原生安全的 4C
云原生安全性跨四个关键层实施，称为 4C：
- 代码——保护代码的安全措施。例如，使用漏洞扫描程序和安全编码实践。
- 容器——容器级别的安全措施。例如，限制对网络端口的访问和加密传输中的数据。
- 集群——集群级别的安全措施。例如，定义网络安全策略和加固所有主节点。
- 云或企业数据中心——保护基础设施的安全措施。这通常由云提供商或本地 IT 人员实施。
Kubernetes 集群中的安全机制
Kubernetes 提供了多种概念和机制来帮助保护您的集群。这是官方 Kubernetes 项目文档中列出的最重要的那些。
网络政策
Kubernetes 使用平面网络模型，默认情况下允许每个 pod 与集群中的任何其他 pod 通信。这造成了重大的安全问题，因为它允许破坏一个 pod 的攻击者与集群中的所有其他资源自由通信。为了保护 pod 到 pod 的通信，Kubernetes 使用了网络策略的概念。
网络策略就像在每个 pod 中设置的虚拟防火墙。当管理员定义网络策略时，它们会在 Pod 级别自动更新，Pod 根据策略接受或拒绝网络流量。在 Kubernetes 中，定义允许或不允许通信的机制是标签选择器，而不是 IP 地址或范围。
Pod 安全策略
Kubernetes 最初使用 PodSecurityPolicy (PSP) 对象来控制与安全相关的 Pod 配置。PSP 定义了 pod 必须满足的最低条件才能在集群中运行。但是 PSP 被发现难以使用，具有重要的功能限制，并且无法默认启用，因此很快就会被弃用和替换。
替换功能的临时名称为“PSP Replacement Policy”。新策略旨在简化部署，内置准入控制器，易于使用，同时为大规模生产部署提供灵活性。重要的是，与当前的 PSP 不同，您将能够通过软部署将其改装到现有集群中。
Kubernetes Secrets
机密是敏感信息，例如身份验证令牌、SSH 密钥或密码。以明文形式存储机密作为容器映像或 pod 配置的一部分是危险的，因为这些很容易被攻击者破坏，然后攻击者可以访问通过这些凭据访问的任何系统。
内置的 Kubernetes Secrets 功能可让您将敏感信息存储在 Kubernetes 的机密对象中。您必须首先创建一个秘密，使用秘密数据填充它，更新服务帐户以引用该秘密，然后才能创建使用该秘密的 pod。pod 可以访问作为环境变量或文件的机密（这称为机密卷）。
Kubernetes RBAC
Kubernetes 使用 ClusterRoles 和 Roles 的概念，它们指定每个用户可以在集群或整个 Kubernetes 命名空间中执行的操作。您可以使用ClusterRoleBinding将角色应用于集群中的所有资源，或RoleBinding将角色应用于命名空间中的每个资源。Kubernetes 提供以下默认的面向用户的角色，还允许您创建其他自定义角色：
- Cluster-admin –可以对集群中的任何内容执行任何操作。
- Admin –允许对命名空间中的资源进行无限制的读/写访问，但不提供对命名空间本身的写访问。
- 编辑 -允许在命名空间内进行读/写访问，但不允许查看或修改角色和绑定。
- 查看 -与编辑类似，但允许在命名空间中进行只读访问。
验证
Kubernetes 集群的主要访问点是 Kubernetes API。用户和服务角色通过kubectl实用程序、直接 REST API 请求或客户端 SDK 访问它。默认情况下，API 通过端口 445 访问，并受传输层安全性 (TLS) 保护。
Kubernetes API 认证流程如下：
- 客户端尝试访问 API，提供 TLS 客户端证书，并建立 TLS 连接。
- API 服务器运行一个或多个Authenticator 模块。这些允许集群管理员定义用户和服务帐户并指定身份验证策略，包括客户端证书、令牌、JSON Web 令牌和密码。
- Authentication 模块接受客户端的整个 HTTP 请求并尝试对其进行身份验证。如果有多个认证模块，则一个一个尝试，直到一个成功。
- 如果认证失败，API 返回状态码 401。如果认证成功，客户端被认证为
username，并且可以在后续活动中使用该用户名。
- 身份验证模块可能会分配用户组成员资格。如果是这样，用户将拥有该组的额外权限。
用于 Kubernetes 入口的 TLS
Kubernetes Ingress 是一个对象，它允许从集群外部访问 Kubernetes 集群中的服务。它通过 HTTP/S 促进连接，并指定路由规则。
要保护 Ingress 对象，您需要指定一个包含两个密钥的密钥——tls.crt和tls.key——分别包含证书和私钥。TLS 加密一直有效到入口点，集群内的流量默认不加密。如果入口配置包括多个主机，则它们在同一个端口上多路复用。
服务质量
Kubernetes 自动为 Pod 分配服务质量 (QoS) 类，这有助于优化 Pod 的调度和驱逐。kubelet 使用 QoS 类来决定从节点驱逐 pod 的顺序，并在节点上调度 pod 时做出更明智的决策。如有必要，DevOps 团队可以为 pod 自定义 QoS 类。
您可以将 pod 放置在 Guaranteed QoS 类中，这意味着每个容器都可以保证从节点接收到足够的资源。这要求所有容器都有 CPU 和内存限制。Kubernetes 分配了足够多的 CPU 和内存资源来满足 pod 中容器的需求。
Kubernetes 安全最佳实践
以下是一些可以帮助您在整个软件开发生命周期中保护 Kubernetes 集群和工作负载的最佳实践。
构建时安全
- 图像扫描——通过在 CI/CD 管道的每个阶段应用自动图像扫描，确保容器图像没有漏洞。检查图像是否存在 CVE 漏洞和不安全的配置，例如硬编码的秘密。
- 主机操作系统加固——确保容器在主机上具有最小权限，并加固操作系统以限制系统调用，并确保容器之间的强隔离。
- 基础容器镜像——为了最小化攻击面，在创建容器镜像时，您应该从头开始创建它。如果您确实使用基础镜像，请选择一个仅包含容器绝对需要的库或操作系统组件的最小镜像。
部署时安全
- Kubernetes 集群强化——使用自动化工具检查集群配置以了解安全最佳实践，并修复任何不安全的配置。为传输中的数据设置 RBAC 和 TLS。
- 与 Kubernetes 集群的网络安全集成——您可以将 Kubernetes 工作负载使用的 IP 地址提供给下一代防火墙 (NGFW) 等外部工具，以使它们了解 Kubernetes 环境。此外，在云提供商上定义安全组以限制集群内部和集群之间的通信。
运行时安全
- 集群内的网络安全控制——使用声明性方法将网络安全定义构建到您的工作负载中。工作负载在任何地方运行，都必须随身携带其安全定义。您可以使用 Kubernetes 原生网络和安全策略解决方案（如 Calico）来执行此操作，该解决方案在网络级别（第 3-4 层）限制流量，并与 Envoy（代理）集成以限制应用程序级别（第 7 层）的流量。
- 建立企业安全控制——像保护任何企业工作负载一样保护 Kubernetes 集群。启用传输中的数据加密，启用审计和合规性报告，并通过自动修复执行持续合规性检查。
- 威胁防御——建立入侵检测和预防措施，并获得对可疑活动和威胁的可见性，按相似的 pod 组聚合日志数据。使用机器学习分析和威胁情报从日志中获取洞察，并更快、更有效地检测威胁。
Tigera 的 Kubernetes 安全性和可观察性
Tigera 的商业解决方案为多集群、多云和混合云部署提供 Kubernetes 安全性和可观察性。Calico Enterprise 和 Calico Cloud 都提供以下安全性和可观察性功能：
安全
- 安全策略预览、暂存和建议 –轻松对集群进行自助式安全策略更改，而不会存在覆盖现有策略的风险。Calico 可以根据现有服务之间的入口和出口流量自动生成推荐的策略，并且可以在强制执行策略规则之前以“分段”模式部署您的策略。
- 合规报告和警报——持续监控和执行合规控制，轻松创建自定义报告以供审计。
- 入侵检测和预防 (IDS/IPS) –使用机器学习和支持主动监控的基于规则的引擎检测和缓解高级持续性威胁 (APT)。
- 跨主机/虚拟机/容器的微分段——为在所有环境中工作的主机、虚拟机、容器、pod 和服务部署可扩展的统一微分段模型。
- 传输中的数据加密——通过对传输中的数据进行高性能加密来保护敏感数据并满足合规性要求。
可观察性
- 动态服务图 -获取 Kubernetes 环境的详细运行时可视化，以轻松了解微服务行为和交互。
- 应用层可观察性——在您的 Kubernetes 环境中获得服务到服务通信的可见性，而没有服务网格的操作复杂性和性能开销。
- 动态数据包捕获——在与用于数据包捕获的 pod 关联的节点上生成 pcap 文件，以调试微服务和应用程序交互。
- DNS 仪表板 –快速确认或消除 DNS 作为 Kubernetes 中微服务和应用程序连接问题的根本原因。
- 流可视化器 –获得命名空间或工作负载的 360 度视图，包括有关如何实时评估安全策略的分析以及流的体积表示。
