当前，从各个方面来看，Kubernetes都在容器编排市场中占据主导地位。我们最新的Kubernetes和容器安全状态报告（https://www.stackrox.com/kubernetes-adoption-and-security-trends-and-market-share-for-containers/）发现，87％的组织正在使用Kubernetes来管理容器。
另一项调查显示，在过去的12个月中，有94％的组织在其容器环境中遇到了严重的安全问题，其中69％的组织检测到错误配置，27％的组织遇到运行时安全事件，还有24％的组织发现了严重的安全漏洞。
粗略地说，这些安全问题中的每一个都对应于容器生命周期阶段。您应该在构建阶段纠正已知的漏洞，在构建/部署阶段纠正错误的配置，并在运行时对威胁进行响应。
在本文中，我们将探讨使用Kubernetes时可能遇到的一些安全风险和挑战，尤其是在大规模生产中。我们还将提供最佳实践和实用建议的列表，以帮助您保护本地云基础架构和应用程序。（kubernetes-security-best-practices-build-phase——https://www.stackrox.com/post/2020/05/kubernetes-security-101/#kubernetes-security-best-practices-build-phase）
Kubernetes安全风险和挑战
容器无处不在
尽管容器具有快速，可移植性以及微服务体系结构的特点，但是它们也是容易创建安全盲点并增加攻击面。随着大量容器的部署，保持对云基础架构组件的足够可见性变得更加困难。
容器化应用程序的分布式特性使得难以快速发现哪些容器可能存在漏洞，错误配置从而对您的应用造成最大风险。
镜像和镜像注册如果被滥用，可能会带来安全问题
对于如何在可信的镜像注册中心中构建和存储镜像，需要强有力的治理策略。您必须确保使用定期扫描的安全且已允许的基础镜像来构建容器镜像，并确保仅使用白名单镜像注册中心的镜像在Kubernetes环境中启动容器。
容器彼此之间以及与其他端点之间的通信
容器和pod需要在部署中相互通信，也需要与其他内部和外部端点通信才能正常工作。如果容器被破坏，恶意人员在环境中横向移动的能力直接关系到容器与其他容器和pod通信的范围。 在一个庞大的容器环境中，考虑到手动配置此类策略的复杂性，实现网络分段可能非常困难。
Kubernetes提供了丰富的配置选项，但是默认值通常是最不安全的
根据DevOps原则，Kubernetes旨在加快应用程序部署并简化管理和操作。Kubernetes提供了一组丰富的控件，可用于有效地保护集群及其应用程序的安全。
例如，Kubernetes网络策略类似于防火墙规则，它控制pod之间以及其他端点之间的通信方式。当网络策略与pod关联时，该pod只允许与该网络策略中定义的目标通信。默认情况下，Kubernetes不会对pod应用网络策略，这意味着在Kubernetes环境中，每个pod都可以与其他pod进行通信。
另一个配置的安全风险是与secret管理有关：如何存储和访问敏感数据（例如凭据和secret）。您必须确保不会将secret等安全信息作为环境变量传递，而是将其放入容器的只读卷中。
容器和Kubernetes构成合规性挑战
云原生环境还带来了遵守安全最佳实践、行业标准和基准以及内部安全策略方面的挑战。
除了保持合规性之外，用户还必须显示该合规性的证明。他们必须调整策略以确保其Kubernetes环境符合最初为传统应用程序体系架构编写的规范。
此外，容器化应用程序的分布式和动态特性意味着必须完全自动化合规性监控和审核，才能成功大规模的运行。
容器运行带来了常见的以及新的安全性挑战
容器和Kubernetes的一个安全优势是它们可以被视为不可变的基础设施——运行的应用永远不应该被修补或更改，而是在需要新更新时从通用模板删除然后重新创建并运行它们。
容器的其他属性带来了独特的挑战，包括它们的非持久性以及快速创建与删除。
当在正在运行的容器中检测到潜在威胁时，例如活动漏洞或新漏洞，您不仅必须能够终止该容器并重新启动新的未被破坏的版本，而且还必须确保，修复的信息能够在所有的现有或新的容器镜像中得到应用，从而可以安全的重新配置应用。
其他的安全风险包括运行有恶意进程的受损容器。尽管对于那些破坏容器环境的攻击者而言，Crypto-mining挖矿行为已成为一个常用的手段，但也可以从受到破坏的容器中执行其他恶意进程，例如通过网络端口扫描以查找漏洞，然后利用潜在的漏洞进行破坏性操作。
要成功解决上面列出的这些Kubernetes安全挑战（还有许多未列出），需要将安全集成到容器生命周期的每个阶段：构建，部署和运行。
您必须构建没有严重漏洞的安全镜像，按照最佳安全实践配置部署，并在运行时保护workload免受威胁。
最后，您必须保护自己的Kubernetes基础架构及其组件，包括Kubernetes API，etcd等，这些组件自身具有特殊的受攻击方式，从而增加了总体攻击面。
Kubernetes最佳安全实践：镜像构建阶段
保护容器和Kubernetes的安全要从构建阶段开始，即保护容器镜像。您在这里花费的时间将为以后带来回报，因为此时任何错过的最佳安全实践都将大大增加修复的成本，因此“shift left”意味着在构建镜像的早期阶段实现安全性。
此处要做的两件事是构建安全镜像并扫描这些镜像以查找任何已知漏洞。
推荐建议
1）使用最小的基础镜像
避免将镜像与OS软件包管理器或Shell一起使用，因为它们可能包含未知漏洞。如果必须包含操作系统包，请在以后的步骤中删除包管理器。考虑使用最小的镜像。
2）不要添加不必要的组件
确保从生产中的容器中删除debug工具。镜像中不应包含易于被攻击者利用的通用工具（例如Curl）。
3）仅使用最新镜像
确保您的镜像（以及包括的任何第三方工具）是最新的，并使用最新版本组件。
4）使用镜像 scanner识别已知漏洞
您的镜像 scanner应该能够识别镜像中的漏洞（包括分层），并告诉您它们是否可修复。它必须能够扫描OS软件包和第三方运行库中的漏洞，以查找容器化应用程序中使用的程序语言漏洞。
5）将安全性集成到您的CI/CD pipeline
使镜像扫描和其他安全检查成为CI/CD pipeline的一部分，以在扫描程序检测到高级别可修复漏洞时自动执行安全保护并使CI构建失败同时生成告警。
6）标记无需修复的漏洞
有时如果应用程序没有已知漏洞，或者该漏洞不是关键漏洞，因此不需要立即修复。在这种情况下，请将它们添加到白名单或从scanner中过滤，这样您就不会因不可操作的告警而导致工作中断。
7）纵深防御
在容器镜像或使用该镜像的正在运行的deployment发现安全问题时，请确保已进行策略检查并准备好修复工作流来检测和更新这些镜像。
Kubernetes最佳安全实践：部署阶段
在部署workload之前，应该安全地配置Kubernetes基础设施。从安全的角度来看，您首先需要了解正在部署的内容以及如何部署。然后，您可以识别并响应违反安全策略的行为。至少，你需要知道：
正在部署的内容 ——包括有关正在使用的镜像的信息，例如组件或漏洞以及将要部署的Pod
它将在哪里部署 ——包含cluster，namespace和node
部署方式 ——它是否运行特权，它可以与那些deployment进行通信，同时使用的pod安全上下文（如果有的话）
它可以访问的内容 ——包括secrets，卷和其他基础结构组件，例如主机或orchestrator API
是否符合要求 ——是否符合您的策略和安全要求
有了这些信息，您就可以开始针对需要修复和加固的区域，并实现适当的分段。
推荐建议
8）使用namespace隔离敏感的workload
使用namespace是Kubernetes资源的主要的隔离方式。namespace为网络策略、访问控制和其他重要的安全控制提供了参考。将workload分到不同的namespace有助于遏制攻击，并限制用户的错误或破坏性操作的影响。
9）使用Kubernetes网络策略来控制Pod和集群之间的流量
默认情况下，Kubernetes允许每个Pod与其他Pod通信。网络分段策略是一项关键的安全控制措施，可以防止在攻击者入侵的情况下跨容器横向移动。以下的文章中介绍了如何设置Kubernetes网络策略。
构建Kubernetes网络策略以控制入口流量（https://www.stackrox.com/post/2019/04/setting-up-kubernetes-network-policies-a-detailed-guide/）
构建Kubernetes网络策略以控制出口流量（https://www.stackrox.com/post/2020/01/kubernetes-egress-network-policies/）
10）防止过度访问secret信息
第一步，请确保deployment仅使用其实际需要的secret，以防止不必要的信息泄露。
11）评估容器使用的特权
赋予容器的功能，角色绑定和权限集会极大地影响您的安全风险。此处的目标是遵守最小权限原则，并提供容器执行其预期功能的最小权限和功能。
Pod安全策略是一种控制Pod与安全相关的属性的方法，包括容器特权级别。这些可以使操作人员指定以下内容：
不要以超级用户身份运行应用程序进程。
不允许权限升级。
使用只读的根文件系统。
使用默认的（masked/proc文件系统挂载）
不要使用主机网络或进程空间。
删除未使用和不必要的Linux功能。
使用SELinux选项获得更细粒度的过程控制。
为每个应用程序分配自己的Kubernetes服务帐户。
如果不需要访问Kubernetes API，请不要在容器中保存服务帐户凭据。
12）评估镜像来源，包括注册
根据经验，请勿从未知来源镜像来部署代码。对于Kubernetes，这意味着仅使用来自已知或列入白名单的注册的镜像。
13）将镜像扫描扩展到部署阶段
作为镜像扫描的扩展，请在部署阶段根据扫描结果设置策略。一种设置方式是使用Validation Admission Controller，当Kubernetes指定没有扫描结果或严重漏洞的镜像时，或者如果镜像已建立超过90天，Kubernetes将拒绝使用该镜像进行应用部署。
最近未扫描的镜像可能包含自上次扫描以来新发现的漏洞。
14）适当使用标签和注释
例如，考虑使用名称，电子邮件别名或负责应用程序团队的Slack Channel为deployments标记或者添加注释。这样可以更容易地提醒相应团队注意安全问题。
15）启用Kubernetes基于角色的访问控制（RBAC）
RBAC提供了一种方法，用于控制对集群中的用户和服务帐户访问集群的Kubernetes API服务的授权。Kubernetes RBAC是高度可配置的，因此请确保您没有犯这5个Kubernetes RBAC错误中的任何一个错误（https://www.stackrox.com/post/2019/09/5-kubernetes-rbac-mistakes-you-must-avoid/）。
还有更多构建和部署时安全性最佳实践，它们超出本文的范围。从这里开始，通过探索本文结尾处列出的其他点来提高安全性。
接下来，我们将提供有关在运行阶段保护您的Kubernetes workload的建议。
Kubernetes最佳安全实践：运行阶段
运行阶段使容器化的应用程序面临许多新的安全挑战。您的目标既是获得对运行环境的可见性，也是在威胁出现时对其进行安全检测和快速响应。
在构建和部署阶段主动保护您的容器和Kubernetes deployment可以大大降低运行时发生安全事件的可能性以及为响应这些事件而进行的后续工作量。
首先，您必须监控与安全性最相关的容器活动，包括：
进程活动情况
容器服务之间的网络通信
容器化服务与外部客户端和服务器之间的网络通信
由于容器和Kubernetes具有声明性，因此在容器中观察容器行为来检测异常通常比在虚拟机中更容易。这些属性使您可以更容易地对所部署的内容及其预期活动进行自省。
推荐建议
16）利用Kubernetes中的上下文信息
使用Kubernetes中的构建和部署时间信息来评估运行时观察到的活动与预期活动，以检测可疑活动。
17）将漏洞扫描扩展到正在运行的deployment
除了扫描容器镜像中存在的漏洞之外，同时还要观察正在运行的deployments中是否有新发现的漏洞。
18）使用Kubernetes内置控件以加强安全性
配置Pod的安全上下文以限制其功能。这些控件可以消除依赖特权访问的整个攻击类别。例如，只读根文件系统可以防止任何依赖于安装软件或写入文件系统的攻击。
19）监控网络流量以限制不必要或不安全的通信
观察您的应用网络流量并将该流量与基于Kubernetes网络策略所允许的流量进行比较。容器化的应用程序通常会大量使用集群网络，观察应用网络流量是了解应用程序如何相互交互并识别意外通信的好方法。
同时，将应用流量与允许的流量进行比较，可以为您提供关于未发生但被允许的有价值的信息。有了这些信息，您就可以进一步收紧允许的网络策略，以消除多余的连接并减少攻击面。
像https://github.com/kinvolk/inspektor-gadget之类的开源项目可能对此有所帮助，而商业安全解决方案则提供了不同程度的容器网络流量分析。
20）利用进程白名单
进程白名单是一种用于识别意外运行进程的经过尝试的真实做法。首先，观察应用程序一段时间，以识别在应用程序行为的正常过程中执行的所有进程，然后将经常加入到列表。该列表将用作针对应用程序行为的白名单。
在进程级别对运行程序分析具有挑战性；可以寻求在容器和Kubernetes方面有经验的商业安全供应商的支持。
21）比较和分析相同deploymens的Pod中的不同运行时的状态
由于高可用性、容错性或规模等原因，容器化的应用经常被复制。复制的应用的行为应该几乎相同；与其他复制的应用有重大偏差的应用需要进一步检测。将Kubernetes安全工具与其他外部系统（电子邮件、PagerDuty、Slack、Google Cloud Security Command Center、SIEMs[安全信息和事件管理]等）集成，并利用deployment标签或注释在检测到潜在威胁时提醒给负责应用的团队。商业Kubernetes安全供应商应该支持与外部工具的广泛集成。
22）如果被攻破，将可疑的pod数量缩为零
使用Kubernetes控制器自动将可疑的pod缩放为零或杀死，然后重新启动被破坏的应用程序实例。
基础设施安全
到目前为止，我们专注于安全最佳实践，以构建，部署和运行由Kubernetes精心组织的workload。但是，安全性必须扩展到镜像和workload之外，并保护整个环境，包括集群基础结构。您必须保护群集，节点和容器引擎。
推荐建议
23）尽可能将Kubernetes更新到最新版本
请记住，仅支持Kubernetes的最后三个版本，其中包括针对新发现的漏洞的安全补丁。因此，如果在Kubernetes中发现了一个高严重性安全漏洞，并且您落后四个版本，则您的版本将不会收到补丁。
24）安全地配置Kubernetes API服务
确保您禁用未经身份验证的匿名访问，并使用TLS加密kubelet和API服务之间的连接。（https://www.stackrox.com/post/2019/09/12-kubernetes-configuration-best-practices/#6-securely-configure-the-kubernetes-api-server)
25）etcd的安全
etcd是Kubernetes用于数据访问的键值存储（CNCF项目）。etcd被认为是Kubernetes的信任来源，您可以根据需要从中读取数据或将数据写入其中。确保仅通过TLS提供客户端连接。
26）kubelet的安全
作为在每个节点上运行的主节点代理，对kubelet的错误配置会使您通过kubelet进行后门访问。通过使用--anonymous-auth=false标志启动kubelet 并利用NodeRestriction准入控制器限制kubelet可以访问的内容，确保已禁用对kubelet的匿名访问。
Kubernetes包含更多组件，包括kube-scheduler，kube-controller-manager，主节点和工作节点上的配置文件等。您可以通过以下方法了解有关如何安全配置这些Kubernetes组件并满足合规性要求的更多信息。（https://www.stackrox.com/post/2019/09/12-kubernetes-configuration-best-practices/）
最后的想法：部署实施Kubernetes的安全
容器和Kubernetes的出现并没有改变安全需求。您的目的仍然是使非法人员很难侵入您的应用程序及其基础设施，如果被入侵成功，则要尽快捕获并阻止它们。但是，这些工具和方法必须适应DevOps实践和云原生原则的需求。
推荐建议
27）将安全更早地嵌入到容器的生命周期中
您必须尽早将安全集成到容器生命周期中，并确保安全需要和DevOps团队之间保持一致并实现共同的目标。安全可以（并且应该）是一个使能者，使您的开发人员和DevOps团队可以放心地构建和部署具有规模，稳定和安全的生产级别应用。
28）使用Kubernetes-native安全控制来降低运营风险
尽可能利用Kubernetes中内置的控件来强制执行安全策略，这样您的安全控件就不会与编排工具发生冲突。例如，不要使用第三方代理或shim来强制网络分段，而是使用Kubernetes网络策略来确保安全的网络通信。
29）利用Kubernetes提供的上下文来优先进行补救工作
在庞大的Kubernetes环境中，手动筛选安全事件和策略冲突是非常耗时的。例如，针对严重级别为7或有更高风险漏洞的deployment，如果该deployment包含特权容器并且已开放了Internet，则应上移修复优先级，但如果它位于测试环境中并且支持非关键应用程序，则修复优先级下移。
原文： https://www.stackrox.com/post/2020/05/kubernetes-security-101/
了解新钛云服
新钛云服正式获批工信部ISP/IDC(含互联网资源协作)牌照
TiOps，支持多云环境安全远程运维，疫情期间免费对外开放，助力远程安全办公！
新钛云服，打造最专业的Cloud MSP+，做企业业务和云之间的桥梁
新钛云服出品的部分精品技术干货
刚刚，OpenStack 第 19 个版本来了，附28项特性详细解读！
OpenStack与ZStack深度对比：架构、部署、计算存储与网络、运维监控等
1703
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
