K8s 全流程安全实践
据有关报告数据显示，94％ 的受访组织一年内在其容器环境中遇到过安全问题，其中 69％ 的组织检测到错误配置；27％ 的组织运行时遇到安全问题；还有 24％ 的组织发现了严重漏洞。这些问题均与容器生命周期阶段有关，我们可以在构建、部署、运行阶段中区分这些漏洞。
基础架构安全
1.保持 Kubernetes 的更新。K8s 针对新漏洞的安全补丁仅支持最新的三个版本，因此如果我们落后了四个版本，并出现了严重漏洞，那么我们的版本将不会收到补丁。
2.安全地配置 Kubernetes API 服务器。我们要确保已禁用未经身份验证或匿名的访问，并使用 TLS 加密 kubelet 和 API 服务器之间的连接。
构建阶段
保护容器和 Kubernetes 的安全要从构建阶段开始，即保护容器镜像。扫描并保护镜像是防止任何已知漏洞的主要措施。
1.使用镜像扫描器。镜像扫描器可以识别镜像中的漏洞，并告诉我们是否可修复。
2.标记不可修复的漏洞。在某些情况下，没有已知漏洞的修复程序，或者该漏洞不是关键漏洞，因此不能保证快速修复，此时我们应该对其进行标记，这样就不会因为警报而干扰开发团队的工作流程。
3.不要包含不必要的组件。我们要确保已从生产中的容器中删除调试工具，镜像中不应包含 Curl 之类的工具。
4.实施纵深防御。当在容器镜像或正在使用该镜像的 deployment 中发现安全问题时，我们要确保有策略检查以及这些镜像的补救工作流。
部署阶段
从安全角度出发，我们首先需要了解正在部署的内容以及部署方式，这样就可以识别违反安全策略的情况。
- 正在部署的内容：包括有关所使用镜像的数据，例如组件、漏洞、Pod。
- 将要部署的位置：命名空间、集群、节点。
- 部署方式：是否是特权运行、可以与其他哪些部署协调。
- 可以访问的内容：包括卷、secret、主机或 Orchestrator API 等组件。
1.通过使用命名空间隔离敏感的工作负载。命名空间是 Kubernetes 资源的主要隔离边界，它为网络策略、访问控制限制以及其他重要的安全控制提供了参考。将工作负载分隔到命名空间后，我们可以通过授权用户来限制错误或破坏性操作的影响。
2.使用 Kubernetes 网络策略。Kubernetes 允许 Pod 与其他 Pod 联系。网络分段策略是关键的安全控制策略，可以防止攻击者闯入后跨容器移动。
运行阶段
1.将漏洞扫描扩展到正在运行的 deployment 中。不仅要扫描镜像隔离库中已存在的漏洞，我们还要检查正在运行的 deployment 中是否有新发现的漏洞。
2.监控网络流量。根据 Kubernetes 网络策略分析活动的网络流量，我们再将其与允许的流量进行比较。比较活动流量将为我们提供可能出现问题的重要数据。使用这些数据，我们可以修复网络策略，以删除多余的连接并最大程度地降低受到攻击的机会。
https://solaceinfotech.com/blog/kubernetes-security-best-practices-that-you-must-know/
配置基础架构的关键
容器在企业环境中的采用率正在不断上升，在 CNCF 2016 年的调查中，容器使用率约为 23％，但在 CNCF 2019 年的调查中，这个比例达到了 84%，这表现了容器使用率爆炸式的增长。
为了帮助大家更快地过渡到 DevOps，这里罗列了配置基础架构的关键清单，以确保大家正确配置基础结构。
基础架构规划
这是每个企业在部署容器之前应采取的第一步。云、本地和混合模型会附带哪些类型的运营、订阅和维护成本？哪种模型最适合企业，能为开发人员提供最佳的发展环境？
对应用程序进行正确的容器化
切换到容器时，企业要经历应用程序容器化的实际过程，这不是简单地将旧客户端服务器应用程序移入容器中。这可能需要更改应用程序的设计和实现，不过这也是真正推动创新的必要步骤。
存储计划
评估存储选项是环境蓬勃发展的另一个关键组成部分。旧式存储模型可能无法在容器化环境中运行，因此我们需要升级或调整存储方式。
备份和灾难恢复计划
即使我们利用云技术在云中进行部署，同时提供商也承担责任，但用户和企业也要对自己的环境负责。假使云提供商的灾难恢复工具和系统针对应用程序的自动运行工具是不安全的，那么这些事情就需要我们手动实施。
评估安全性和访问控制
在进行正确的基础结构配置之后，组织对其环境中安全性和访问控制的评估也至关重要。这意味着确保角色和权限的设置正确和跨容器化环境的一致性。
维护数据所有权
即使我们将数据托管在云中，也要确保数据的所有权，以保护数据免遭盗窃，这可以让客户和合作伙伴对我们感到放心。做到这一点的最有效方法之一是对所有数据进行加密，并将加密密钥保存在企业内部。
https://containerjournal.com/topics/container-ecosystems/the-keys-to-successful-infrastructure-configuration/
云是如何帮助团队的
十年前，迁移到云端意味着走在潮流前列，但现在不是了。据调查显示，有 74％ 的组织表示云为他们提供了竞争优势，并且有专家预测，到 2020 年底，将有 83％ 的企业工作负载会在云中。云的重要性不言而喻，我们来看一下云是如何帮助团队的。
云使我们可以及时使用最新功能、安全升级和错误修复。
当软件和计算机的电源部署在本地状态，对于企业而言，当每年的升级到来时，每次升级都会带来很多新功能，这意味着团队都会面对他们从未见过的功能，另外，引入新事物也意味着有可能引入一些新的错误。
借助云，发行版可以与单个错误修复或产品改进一样小，从而降低引入新错误的风险。这意味着如果出现问题，很容易回滚并且影响很小。另外，由于新功能会定期且小批量地推出，团队可以更轻松地跟上更改，从而保持了竞争力。
云帮助我们优先考虑创意和战略工作。
在本地托管软件和产品始终需要技术团队花费更多时间。但有了云，所有额外的工作都外包了，这意味着错误修复、问题管理和重大事件都是供应商的责任。IT 团队可以放弃繁琐的工作，例如安装新服务器或解决问题，而专注于业务必不可少的战略性和创造性工作。
云增强了非技术团队的能力。
对于本地部署，任何更改都必须通过 IT 来解决。这不仅给技术团队增添了负担，而且还降低了非技术团队的工作速度，剥夺了他们快速改进其工作流程、系统和团队动力的能力。
借助云，自动扩展和即时安全性等功能意味着团队可以变得敏捷灵活。他们可以更改流程并采用新功能和优势，从而改善工作流程，而无需经过漫长的审批或延迟处理。
云简化了远程工作和分布式团队。
远程工作已经可以从任何地方通过 Internet 连接访问云解决方案。另外，云可以轻松地为分布式团队提供支持。分布式团队和远程工作的最大好处是，它使我们可以访问更大的人才库，无论是在地理位置上，还是一些原因必须在家工作的人员。
https://dzone.com/articles/4-ways-cloud-helps-future-proof-your-teams
使用超 10 亿次的镜像
尽管疫情导致了一定的经济下滑，但 Docker 的发展势态似乎依旧强劲。据 Docker 公司报告，Docker Hub 上的存储库数量从去年的 600 万增加到 700 万，Docker Hub 用户的数量也从去年的 500 万增加到了 700 万。
自 2014 年以来，存储库中镜像已被提取了 2420 亿次。此外，这些存储库中 160 多个官方镜像占了总提取数的 20％ 以上。截止 2020 年 7 月，被提取超过 10 亿次的镜像如下：
- NGINX：负载均衡器和反向代理服务器软件，已广泛用于单片和基于微服务的应用程序。
- BusyBox：在嵌入式系统上最常使用的一套软件，可在单个可执行文件中提供多个 Unix 实用程序。
- httpd：Apache 超文本传输协议（HTTP）服务器软件的实例，旨在作为独立的守护进程运行。
- PostgreSQL：一个开放源代码关系数据库，同时支持 SQL 和 JavaScript Object Notation（JSON）查询。
- Redis：内存中的数据结构存储，通常用作数据库、缓存和消息代理。
- Memcached：在内存中运行的分布式对象缓存系统。
- Alpine：一个基于 musl libc 和 BusyBox 的轻量级 Linux 发行版。
- Traefik：反向代理和负载平衡器，可简化在边缘计算平台上部署微服务的过程。
- Ubuntu：Canonical 发行的 Linux，广泛用于云计算平台。
- MongoDB：一种开源文档数据库，因成为关系数据库的替代方法而受到关注。
Kubernetes 4 个近期漏洞
随着 Kubernetes 的发展，它吸引了更多安全人员的注意力，他们研究 Kubernetes 并寻找弱点。与任何软件一样，Kubernetes 也会存在漏洞，攻击者可以使用其中的一些漏洞渗透甚至控制集群。最近一次的 CNCF 研讨会就总结了 4 个 Kubernetes 近期漏洞。
CVE-2020-8555
通过认证鉴权的攻击者可能通过服务端请求伪造获取控制节点（Master Node）网络下未经认证鉴权保护接口返回的任意信息。
影响范围：
kube-controller-manager v1.16.0~v1.16.8
kube-controller-manager<v1.15.11
受影响的存储类型有：GlusterFS、Quobyte、 StorageFS、ScaleIO。
解决办法：
对相应的 kube-controller-manager 进行升级，以规避暴露在控制台节点网络下其他未保护服务的信息泄露危险。
CVE-2020-8559
攻击者可以通过截取某些发送至节点 kubelet 的升级请求，通过请求中原有的访问凭据转发请求至其他目标节点，从而造成节点的权限提升漏洞。
影响范围：
kube-apiserver v1.18.6
kube-apiserver v1.17.9
kube-apiserver v1.16.13
防范方法：
及时吊销可能泄露的 kubeconfig 凭证，并且遵循权限最小化原则，收敛子账号不必要的 pods/exec、pods/attach、pods/portforward 和 proxy 类型的资源模型 RBAC 权限。
CVE-2020-8557
kubelet 的驱逐管理器（eviction manager）中没有包含对 Pod 中挂载的 /etc/hosts 文件的临时存储占用量管理，因此在特定的攻击场景下，一个挂载了 /etc/hosts 的 Pod 可以通过对该文件的大量数据写入占满节点的存储空间，从而造成节点的拒绝访问（Denial of Service）。
影响范围：
kubelet v1.18.0~v1.18.5
kubelet v1.17.0~v1.17.9
kubelet<v1.16.13
解决办法：
通过使用集群 Pod 安全策略或其他 admission 准入机制强制 Pod 删除 CAP_DAC_OVERRIDE 系统权限；限制以 root 用户启动容器；设置参数 allowPrivilegeEscalation 为 false；对节点上的 /etc/hosts 文件进行有效的监控。
CVE-2020-8558
攻击者可能通过共享主机网络的容器，或在集群节点上访问同一个 LAN 或二层网络下的相邻节点上绑定监听了本地 127.0.0.1 端口的 TCP/UDP 服务，从而获取接口信息。
影响范围：
kube-proxy v1.18.0~v1.18.3
kube-proxy v1.17.0~v1.17.6
kube-proxy≤v1.16.10
解决办法：
在集群中配置 iptables 规则，用于拒绝非本地对 127.0.0.1 的访问流量；严格控制集群节点共享主机的登录权限，及时吊销可能泄露的 kubeconfig 集群访问凭证；禁止 Container 开启 CAP_NET_RAW 能力；通过 PodSecurityPolicy 策略限制部署特权或共享主机网络容器。
本周 K8s 开源项目推荐
deprek8ion
这是一种 Rego 策略，用于监视 Kubernetes API 的弃用情况。
github.com/swade1987/deprek8ion
Beetle
它可以在多集群、多命名空间的 kubernetes 环境中自动执行应用程序的部署和回滚。
github.com/Clivern/Beetle
kconmon
这是一种 Kubernetes 节点连接性监控工具。
github.com/Stono/kconmon
k8s-diagrams
它从 Kubernetes 的培训、文章和讲座中提取了一系列解释 kubernetes 的结构图。
github.com/cloudogu/k8s-diagrams
helm-docs
这是一种自动生成 helm 图表 markdown 文档的工具。
github.com/norwoodj/helm-docs
k8s-worker-pod-autoscaler
它可以根据队列长度伸缩 kubernetes 容器。
github.com/practo/k8s-worker-pod-autoscaler