学习 Kubernetes 基础知识

概念

Kubernetes v1.16 版本的文档已不再维护。您现在看到的版本来自于一份静态的快照。如需查阅最新文档，请点击 最新版本。

Edit This Page

云原生安全概述

Kubernetes 安全性（以及总体上的安全性）是一个巨大的话题，其中包含许多高度相关的部分。 在当今时代，开源软件已集成到许多可帮助网络应用程序运行的系统中， 有一些总体概念可以帮助指导您如何全面地思考整体安全性。 本指南将围绕 Cloud Native Security 为一些一般概念定义一个思维模型。 思维模型是完全任意的，只有它在可以帮助您考虑在何处保护软件堆栈时，才应使用它。

云原生安全的 4 个 C

让我们从一个图表开始，也许它可以帮助您了解如何分层去考虑安全性。

注意： 这种分层方法增强了深度防护方法在安全性方面的 防御能力，该方法被广泛认为是保护软件系统的最佳实践。 4C 分别是云（Cloud）、集群（Cluster）、容器（Container）和代码（Code）。

云原生安全的 4C

从上图可以看到，每个 4C 都取决于它们适合的正方形的安全性。 仅通过在代码级别解决安全问题，几乎不可能防止云，容器和代码中不良的安全标准。 但是，如果适当地处理了这些方面，则为代码添加安全性将增强本已强大的基础。 现在将在下面更详细地描述这些关注的领域。

云

在许多方面，云（或者位于同一位置的服务器，或者是公司数据中心）是 Kubernetes 集群中的 可信计算基。 如果这些组件本身容易受到攻击（或者被配置成了易受攻击的方式），就没有真正的方法保证在此基础之上构建的组件是安全的。 每个云提供商都会提出大量的安全建议，向客户提供有关如何在其环境中安全地运行工作负载的安全建议。 由于每个云提供商和工作负载都不相同，因此提供有关云安全性的建议超出了本指南的范围。 这里是一些常用的云提供商提供的为了安全性的文档的链接，并提供有关保护组成 Kubernetes 集群的基础架构的一般指导。

云提供商安全性表格

IaaS 提供商 链接
Alibaba Cloud https://www.alibabacloud.com/trust-center
Amazon Web Services https://aws.amazon.com/security/
Google Cloud Platform https://cloud.google.com/security/
IBM Cloud https://www.ibm.com/cloud/security
Microsoft Azure https://docs.microsoft.com/en-us/azure/security/azure-security
VMWare VSphere https://www.vmware.com/security/hardening-guides.html

如果您是在您自己的硬件或者不同云提供商上运行，您需要查阅相关文档来获取最好的安全实践。

基础设施指导表格

Kubetnetes 基础架构关注领域 建议
通过网络访问 API 服务（Masters） 理想情况下，所有对 Kubernetes Masters 的访问不允许在 Internet 上公开，同时应由网络访问控制列表控制，该列表包含管理集群所需的 IP 地址集。
通过网络访问 Node（工作服务器） 节点应配置为 仅能 从 Masters 上通过指定端口来接受（通过网络访问控制列表）连接，以及接受 NodePort 和 LoadBalancer 类型的 Kubernetes 服务连接。如果可能的话，这些节点不应完全暴露在公共互联网上。
Kubernetes 访问云提供商的 API 每个云提供商都需要向 Kubernetes Masters 和节点授予不同的权限集，因此此建议将更为通用。为集群提供云提供商访问权限时，最好遵循对需要管理的资源的最小特权原则。可以在以下位置找到 AWS 中 Kops 的示例：https://github.com/kubernetes/kops/blob/master/docs/iam_roles.md#iam-roles
访问 etcd 对 etcd（Kubernetes 的数据存储）的访问应仅限于 Masters。根据配置情况，你也应该尝试通过 TLS 来使用 etcd。更多信息可以这查找到：https://github.com/etcd-io/etcd/tree/master/Documentation
etcd 加密 在所有可能的情况下，最好对所有驱动器进行静态数据加密，但是由于 etcd 拥有整个集群的状态（包括机密信息），因此其磁盘更应该进行静态数据加密。

集群

本部分将提供用于保护 Kubernetes 中的工作负载的链接。保护 Kubernetes 有两个方面需要注意：

  • 保护组成集群的可配置组件
  • 保护在集群中运行的组件

集群组件

If you want to protect your cluster from accidental or malicious access, and adopt good information practices, read and follow the advice about securing your cluster.

如果想要保护集群免受意外或恶意的访问，采取良好的信息管理实践，请阅读并遵循有关保护集群的建议。

集群中的组件（您的应用）

根据您的应用程序的受攻击面，您可能需要关注安全性的特定面，比如， 如果您正在运行中的一个服务（A 服务）在其他资源链中很重要，并且所运行的另一工作负载（服务 B） 容易受到资源枯竭的攻击，通过不限制资源服务 B ，您冒着损害服务 A 的风险。 下表列出了保护 Kubernetes 中运行的工作负载需要考虑的链接：

工作负载安全性关注领域 建议
RBAC 授权(访问 Kubernetes API) https://kubernetes.io/zh/docs/reference/access-authn-authz/rbac/
认证方式 https://kubernetes.io/zh/docs/reference/access-authn-authz/controlling-access/
应用程序 Secret 管理 (并在 etcd 中对其进行静态数据加密) https://kubernetes.io/zh/docs/concepts/configuration/secret/
https://kubernetes.io/zh/docs/tasks/administer-cluster/encrypt-data/
Pod 安全策略 https://kubernetes.io/zh/docs/concepts/policy/pod-security-policy/
服务质量（和集群资源管理） https://kubernetes.io/zh/docs/tasks/configure-pod-container/quality-service-pod/
网络策略 https://kubernetes.io/zh/docs/concepts/services-networking/network-policies/
Kubernetes Ingress 的 TLS 支持 https://kubernetes.io/zh/docs/concepts/services-networking/ingress/#tls

容器

为了在 Kubernetes 中运行，软件必须位于容器中。 因此，为了从 Kubernetes 的工作负载安全原语中受益，必须考虑某些安全注意事项。 容器安全性也不在本指南范围内，但这是一张有关一般建议和进一步探索该主题的链接的表格。

容器关注领域 建议
容器漏洞扫描和操作系统依赖安全性 作为镜像构建的一部分，或您应该定期使用CoreOS’s Clair之类的工具扫描您的容器里的已知漏洞。
镜像签名和执行 另外两个 CNCF 项目（TUF 和 Notary）是有用的工具，用来对容器镜像进行签名，以维护对容器内容的信任。如果使用 Docker，则它被内置在 Docker 引擎中作为Docker Content Trust。在实施方面，[IBM 的 Portieris]（https://github.com/IBM/portieris） 项目是作为Kubernetes动态准入控制器运行的工具，以确保图像在进入群集之前已通过公证人正确签名。
禁止特权用户 构建容器时，请查阅文档以了解如何在具有最低操作系统特权级别的容器内部创建用户，以实现容器的目标。

代码

最终进入应用程序代码级别，这是您最能够控制的主要攻击面之一。 这也不在 Kubernetes 的范围之内，但是这里有一些建议：

通用代码安全性指导表

代码关注领域 建议
仅通过 TLS 访问 如果您的代码需要通过 TCP 通信，理想情况下，请提前与客户端执行 TLS 握手。除少数情况外，默认的行为是加密传输中的所有内容。更进一步，甚至在我们的VPC中的“防火墙后面”，加密服务之间的网络流量仍然是一个好主意。这可以通过被称为相互 LTS 或 mTLS 的过程来完成，该过程对两个证书持有服务之间的通信执行双向验证。Kubernetes 中有许多工具可用于完成此任务，例如Linkerd和Istio。
限制通信端口范围 此建议可能有点不言自明，但是在任何可能的情况下，你都只应公开服务上对于通信或度量收集绝对必要的端口。
第三方依赖性安全 由于我们的应用程序倾向于在我们自己的代码库之外具有依赖关系，因此，最好定期扫描代码依赖项，确保它是安全的，没有针对它们的 CVE 归档。每种编程语言都有一个自动执行此检查的工具。
静态代码分析 大多数语言都提供给了一种方法，来分析代码段中是否存在潜在的不安全的编码实践。只要有可能，你都应该使用自动工具执行检查，该工具可以扫描代码库以查找常见的安全错误，一些工具可以在以下连接中找到：https://www.owasp.org/index.php/Source_Code_Analysis_Tools
动态探测攻击 您可以对服务运行一些自动化工具，来针对您的服务运行，尝试一些众所周知的服务攻击。这些攻击包括 SQL 注入、CSRF 和 XSS。OWASP Zed Attack proxy https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project 代理工具是最受欢迎的动态分析工具之一。

强大的自动化

上面提到的大多数建议实际上可以在代码交付管道中自动进行，作为一系列安全检查的一部分。 要了解一种更“连续黑客”的软件交付方法，本文 提供了更多详细信息。

接下来

反馈