Kubernetes安全指南介绍
Kubernetes 等编排工具为软件部署和管理带来了前所未有的弹性和多功能性。他们还把焦点放在了当前安全形势的不足上。
Kubernetes安全最佳方式：Kubernetes 的分散架构为我们提供了几个额外的层。我们可以使用它们来增强和构建现有的安全设置。如果你正确配置这些层，它们可以在任何安全威胁从其起源点爆发之前将其隔离。
本文重点介绍可以采取哪些措施来提高 Kubernetes 集群的整体安全性。
1. 启用基于角色的访问控制 (RBAC)
Kubernetes安全技巧：在多个设备上运行的系统的复杂性，以及由数百个个人和公用事业管理的许多互连微服务是后勤方面的噩梦。
严格控制授予用户的权限。Kubernetes 是基于角色的访问控制(RBAC)方法的支持者。基于角色的访问控制方法意味着没有用户拥有比有效完成任务所需的更多权限。Kubernetes 是关于自动化的，RBAC 使用 API 组通过 Kubernetes API 驱动授权决策。
注意：在这方面，自动化可能是一个问题。有权在命名空间内创建 pod的用户可以使用该角色创建 pod 以访问配置映射或机密。这种违规行为称为权限提升，即用户授予自己额外的权限。
从 Kubernetes 1.8 版开始，RBAC 模式稳定并由 rbac.authorization.k8s.io/v1 API 提供支持。通过使用以下命令启动 API 服务器来启用 RBAC：
--authorization-mode=RBACKubernetes 为人类用户和组件（例如应用程序、控制器和节点）提供了一组预定义的角色。这些预定义的角色数量众多，可为最常见的任务提供合理的默认级别的单独角色。
2. 保守你的秘密
Kubernetes安全指南：在 Kubernetes 中，Secret是一个包含敏感数据（如密码或令牌）的小对象。
即使 pod 无法访问另一个 pod 的秘密，将秘密与图像或 pod 分开也很重要。否则，任何有权访问图像的人也可以访问该机密。处理多个进程并具有公共访问权限的复杂应用程序在这方面尤其容易受到攻击。
将进程分配给不同的容器
Kubernetes安全最佳方式：Pod 中的每个容器都必须请求其卷中的秘密卷。通过将进程划分到单独的容器中来降低机密泄露的风险。使用与用户交互但无法看到私钥的前端容器。
使用可以查看私钥并响应来自前端的简单签名请求的签名者容器补充该容器。这种分区方法迫使攻击者执行一组复杂的操作，以试图破坏你的安全措施。
注意：管理员应该始终使用从 API 服务器到他们的 etcd 服务器的强凭据。通过 TLS 客户端证书的相互身份验证可以将 etcd 服务器隔离在防火墙后面，只有 API 服务器可以访问。
3. 使用 Kubernetes 网络策略限制 Pod 到 Pod 的流量
Kubernetes安全技巧：将 TLS 安全协议强加于应用程序部署管道的每个级别是Kubernetes 安全的最佳实践。但是，还必须保护构成集群的各个元素以及控制对集群访问的元素。
默认情况下，Pod 接受来自任何来源的流量。当你定义Network Policies 时，你可以设置有关 pod 如何在集群内以及与外部资源进行通信的特定规则。
网络策略不冲突，而是相加的。在命名空间中定义网络策略意味着 Pod 将拒绝该策略不允许的任何连接，从而有效地隔离 Pod。Pod 仅限于多个网络策略组合批准的内容。
注意：由于 pod 之间缺乏有保证的安全边界，你不应在同一节点上运行具有混合安全级别的 pod。
4. 增强 Pod 安全性
使用 AppArmor 或 SELinux 保护内核
Kubernetes安全最佳方式：容器共享相同的内核，因此有必要使用额外的工具来改进容器隔离。安全模块，如AppArmor和执行访问控制策略的系统，如SELinux，限制用户程序和系统服务。它们还用于拒绝访问文件和限制网络资源。
AppArmor限制了系统内容器可用的资源集。每个配置文件都可以在强制模式下运行，该模式会阻止访问被禁止的资源，或者只报告违规行为的抱怨模式。及时报告潜在问题可显着提高系统的日志记录和审计能力。
SELinux独立于通用 Linux ACM（访问控制机制）管理资源分配。它不识别超级用户（root）并且不依赖于 setuid/setgid 二进制文件。
在没有 SELinux 的情况下保护系统依赖于特权应用程序和内核本身的正确配置。这些方面的错误配置可能会危及整个系统。基于 SELinux 内核的系统的安全性取决于内核及其安全策略配置的正确性。
攻击仍然构成重大威胁。但是，在 SELinux 中，个别用户程序和系统守护进程并不一定需要危及整个系统的安全。
污点和容忍
Kubernetes安全技巧：当系统将新 pod 分配给节点时，Kubernetes 提供了创建预定义规则的选项。
作为编排工具，Kubernetes 倾向于在集群中效率最高的位置启动 Pod，即工作负载最小的位置。可以通过定义 Taints 和 Tolerations 来调整 pod 的位置。
污点允许节点根据预定义的规则“拒绝”一个 Pod 或一组 Pod。另一方面，在 pod 级别应用 Tolerations，它们使 pod 能够调度到具有匹配 Taints 的节点（键和效果相同）。
污点和容忍度应该同时使用，以确保 pod 不会被安排到不适当的节点上。
命名空间
Kubernetes安全最佳方式：Kubernetes 没有提供跨命名空间安全性的机制。限制命名空间的使用，作为一种安全功能，在受信任的域内，以及用于内部目的。当你想要拒绝 Kubernetes 集群的用户访问任何其他命名空间的资源时，不要使用命名空间。
在watch和list请求允许客户端检查是该命名空间的所有秘密的值。只有特权最高的系统级组件才有权执行这些请求。
5. Kubernetes 滚动更新
Kubernetes安全指南：追踪所有潜在的攻击媒介已经变得不可能。这一事实是不幸的，因为没有什么比意识到潜在威胁更重要的了。最好的防御是确保你运行的是最新的 Kubernetes 可用版本。
有多种技术，例如滚动更新和节点池迁移，可让你以最少的中断和停机时间完成更新。
6. 定义审计政策
Kubernetes安全技巧：审计日志记录了 Kubernetes 集群中发生的事件的时间线。通过跟踪用户和 Kubernetes API 采取的操作，管理员可以分析导致潜在问题的事件链。
Kubernetes 允许你通过定义记录事件的频率、是否应该发出警报以及终止受影响的 pod 的程序来微调审计策略。
定期使用审计日志来确保你的系统是最新的，并且威胁保持在标签下。基于容器的部署为审计过程增加了另一个维度。原始镜像与容器中运行的镜像之间的比较可以有效地用于查看任何差异是否会导致安全问题。确保你的软件版本始终包含最新的安全补丁。
注意： 自动化审计日志记录和预定义的一般审计规则是保持对集群控制的有效方法。仅包含对应用程序必不可少的文件和库的最少图像可提高审计效率。
Kubernetes安全最佳方式结论
现在你已了解 Kubernetes 安全性及其最佳实践。
遵循最小特权和纵深防御原则。如果攻击者设法破坏一个组件，他们不应获得对系统的完全访问权限。相反，请确保攻击者在能够造成重大损害或访问敏感数据之前需要穿透其他层。
