​近一段时间来，“云原生”已成为企业应用开发和 IT 运维畛域妥妥的“网红级”概念。借助灵便的微服务架构和容器化运维形式，以及继续的自动化构建与公布能力、申明式 API 还有服务网格等技术的加持，云原生利用曾经在很多方面彻底改变了企业设计、开发、公布和运维应用程序的形式，让上云的企业在灵活性、弹性、老本等诸多方面取得了显著收益。
其实“云原生”这个概念仍然还比拟新，并且随着技术和需要的演变，其相干定义仍然在一直迭代更新。之前咱们曾对微服务进行过简略的介绍，错过的童鞋能够返回 https://mp.weixin.qq.com/s/-N… 回看。本文，咱们会一起看看容器的平安与爱护问题，并通过分享平安设计实际，通知大家如何加固容器自身的安全性，为云原生利用打造一个松软、牢靠的根底。

文末有互动好礼！

容器 | 应用和平安现状

首先来看看早前的一次统计后果：

彼时，Docker 还占据次要份额。但不容忽视的是，容器化的 Containerd 份额在过后曾经呈现了大幅减少。目前，Kubernetes 社区版本曾经在 1.20 版之后，将对 Docker 的反对改成了“Deprecated”，并将从 1.23 版之后彻底移除对 Docker 的反对。

不过 Azure Kubernetes Service 的动作更快。早在 1.19 版本就开始应用 Containerd 取代 Docker 了。对用户来说，咱们不可避免须要经验迁徙过程，包含用 criCtl 工具替换 Docker，以及日志地位和模式的变动等。

总结来说：RKT、LXC、Mesos 等容器运行时曾经很少见，Docker 和 Containerd 根本成为容器运行时的支流实现 。

另外，在编排工具方面，毫无悬念 Kubernetes 已占据榜首。如下图所示，可见加上 OpenShift 以及 Rancher，其占有比例高达 89%，Swarm 则从 2018 年的 11% 降落到了 5%。

从上述统计数据能够看出，容器和容器编排等主导技术栈的发展趋势曾经很显著了，但容器平安方面并没有那么乐观。有一些十分惊心动魄的数据值得咱们每个人警醒：

1. 60% 的受访者所在组织在过来一年内碰到过安全事件
   
2. 93% 的受访者不是十分分明问题的情况
   
3. 82% 的受访者认为，因为采纳了容器，须要从新思考平安职责问题
   

那么对于容器技术来说，到底为咱们造成了哪些平安挑战？咱们该采取怎么的应答措施？

容器带来的平安挑战和应答策略

容器还是虚拟机，这是个问题：

容器是一种“软件包”，其中蕴含了能在任何环境中运行利用所需的全副元素。容器能够通过虚拟化操作系统在任何中央（公有数据中心、私有云、开发者的集体计算机）。然而它的虚拟化水平与虚拟机还有很大区别。

通过下图的比照能够看出： 传统虚构机会占用大量磁盘空间，除了虚拟机托管的应用程序外，还蕴含残缺的操作系统和相干工具；容器则绝对较轻，仅蕴含运行容器化应用程序所需的库和工具，因而比虚拟机更紧凑，并且启动速度更快 。

容器的次要技术实现：

以 Docker 容器为例，次要应用这三大个性来实现虚拟化与隔离：cgroup + namespace + docker image：

cgroup (资源限度):

驱动 ：

• cgroupfs:

要限度内存, CPU 等资源限度写入 pid 对应的一个 cgroup 文件

• systemd :

提供一个 cgroup 治理形式，所有的写 cgroup 操作都必须通过 systemd 的接口来实现，不能手动更改 cgroup 的文件。

罕用显示我的项目:

• CPU: 计算
• Memory: 内存
• Device: 设施
• Freezer: 批工作解冻 (为了平安)
• Blkio: 磁盘拜访
• Pid: 创立过程数量

namespace (隔离):

• mount : 文件系统的视图，是容器镜像提供的一个文件系统。
• uts : 隔离 hostname 和 domain。
• pid namespace : 保障容器的 init 过程是以 1 号过程来启动。
• network namespace : 除 host 网络这种模式，其余所有的网络模式都有一个 networknamespace 的文件。
• user namespace : 管制用户 UID 和 GID 在容器外部和宿主机上的一个映射。
• IPC namespace : 管制了过程兼通信的一些货色，比方说信号量。

docker image

• 基于联结文件系统
• 不同层能够被其余镜像复用
• 容器读写层作为最新的镜像最新一层

容器化所采纳的次要平安技术：

容器在带来轻量与便当的同时，也带来一些平安问题。次要起因包含：

• 多个容器间应用的还是同一宿主机的操作系统内核；
• Linux 内核中很多资源和对象不能被 Namespace 化；
• 零碎调用甄别变得复杂（尽管能够通过 Seccomp 等技术过滤和甄别容器外部发动的所有零碎调用来进行平安加固，但多了一层对系统调用的过滤，会连累容器性能。此外，默认状况下咱们也很难晓得到底该开启哪些零碎调用，禁止哪些零碎调用）。

随着大家对平安越来越器重，容器平安技术自身也在一直的增强和演进。具备代表性的技术包含：

• 默认利用 Capability 限度容器 Root 用户的能力。Docker 默认容器的 Capability 包含（Docker 的默认 Secomp 可参阅 https://github.com/moby/moby/…）：

• Seccomp 零碎调用过滤：
  

• 联合 seLinux 或 Apparmor 实现 MAC 访问控制：

打造平安的容器：

容器平安问题的实质是共享内核。为了解决该问题，逐步倒退出“平安容器”这一概念，其次要代表技术有 Kata Containers 和 Gvisor。

Kata Containers 的实质是一个轻量化虚拟机。当咱们启动一个 Kata Containers 后，会看到一个失常的虚拟机在运行。这也就意味着：规范的虚拟机管理程序（Virtual Machine Manager, VMM）是运行 Kata Containers 的必备组件。

2018 年，Google 公布了 gVisor 我的项目。gVisor 我的项目给容器过程配置了一个用 Go 语言实现，运行在用户态的极小“独立内核”。这个内核对容器过程裸露 Linux 内核，表演“Guest Kernel”的角色，从而达到了将容器与宿主机隔离的目标。两者大抵架构比照如下：

容器 docker-bench-security：

在具体的生产运行环境中，咱们可执行脚本失去最佳实际校验后果。运维人员可联合这些倡议作出批改和备注。具体地址如下：https://github.com/docker/doc…

下图是执行后果，从中能够看到各个级别的条目：

镜像平安扫描：

容器的执行程序和文件系统是镜像，要保障容器平安，镜像的平安扫描也十分重要。开源的镜像扫描产品可抉择 Clair。

在 Azure 上，容器注册的 Azure Defender 蕴含一个破绽扫描程序，可扫描基于 Azure 资源管理器的 Azure Container Registry 注册表中的镜像。该技术由业界当先的破绽扫描供应商 Qualys 提供反对。

Kubernetes 的平安问题

Kubernetes 的平安问题可从几个不同层面开展。

首先，Kubernetes 自身是一个资源对象治理平台，通过把不同对象进行形象，造成平台可能辨认的资源对象，例如 Pod、Namespace、ReplicaSet 等。拜访这些对象须要对立的 API，在 API 层面次要有三种平安机制：认证、受权，以及准入管制。

Kubernetes API 访问控制：

其中准入管制又分成两种 Hook：

1. Mutating admission webhook：对资源的定义申明作出相应批改；
2. Validating admission webhook：判断资源是否能够创立或更新。

在 API 认证方面，应用最广泛的是 X509 和 ServiceAccount 形式。

X509 是通过指定相应 Name 和 Group 属性实现的：

Pod 的 ServiceAccount 认证形式如下图所示：

在受权方面，则次要采取了基于角色的访问控制机制。Kubernetes 中的角色可依据是否须要跨名称空间拜访而分成 Role 和 ClusterRole，同时绑定关系也可分成 RoleBinding 和 ClusterRoleBinding，它们之间的关系如下图所示：

此外还要留神 Kubernetes 的平安上下文问题。因为 Kubernetes 底层还是通过调用容器运行时来对容器进行生命周期治理和平安限度，所以上述无关 Docker 的平安思路也实用于 Kubernetes，借此可实现对运行时的管制。具体内容可参阅下图：

除了通过上述 securityContext 对运行时加以控制外，Kubernetes 还引入了资源平安规定对象 PodSecurityPolicy，借此实现对名称空间内 Pod 的对立安全控制。次要管制内容如下：

其工作流程如下图所示：

在流量访问控制方面，Kubernetes 中进出站流量可通过 NetworkPolicy 加以定义。具体来说，咱们能够定义如下的内容：

ServiceMesh：

如果须要多租户或企业级别的流量和平安管控，仅应用 NetworkPolicy 是不够的。此时须要引入 ServiceMesh。各个 ServiceMesh 在 Kubernetes 这个基座之上都能很好地运行。

以后风行的 ServiceMesh 次要有 Istio 和 Linkerd。下图展现了以 Istio 为代表地 ServiceMesh 整体架构图和组件形成。因为它自身也有肯定的配置和治理复杂性，对性能损耗也不能疏忽，因而对于技术团队不残缺的公司，很多还处于张望状态。

OpenAgentPolicy

因为 PodSecurityPolicy 自身只能定义 Pod 的规定，而在云原生利用中，包含在各个私有云或公有云中，还会引入更多资源类型，如 Service、Node 等。

开源社区也逐渐开始废除 PodSecurityPolicy，转为举荐通过 OpenAgentPolicy 框架实现对各种资源的束缚。因为须要束缚各种资源，因此有必要提供更大灵活性，进而引入了一种新的，表达能力更丰盛的规定语言：Rego。实例请参照下图：

具体到 Kubernetes 平台，咱们须要应用 GateKeeper 这个组件。

在 Azure 云平台中，则是通过 Azure Policy 来实现和代替这个性能的：

存储平安

Kubernetes 可将密钥等机密信息存储在 Secret 资源之中，但查看 etcd 中的内容会发现所有都以明文形式实现，这就会导致一些平安问题，例如：

在 Azure 上提供专门爱护加密密钥、证书（以及与证书关联的私钥）和秘密（例如连贯字符串和明码）等存储敏感数据和要害业务数据的服务 –Azure Key Vault。它能够与 Azure Kubernetes Service 无缝集成，最大限度进步这些敏感信息的拜访和存储安全性。

Azure Kubernetes Service 平安

AKS 中次要蕴含下图所示的 Kubernetes 功能模块，大抵可分为管制立体和数据立体两局部：

Azure Kubernetes Service 是基于 Azure 云平台的托管 Kubernetes 服务。它把管制立体变成了一种托管的平台服务，客户无需治理 API Servers、Etcd 等组件，只须要为本人的 Agent node 付费。同时在平安方面，Azure 平台提供了 Application Gateway、Azure Firewall、Azure Key Vault 等服务来保障系统安全。

下图是一个比拟常见的，以 Azure Kubernetes Service 为根底的整体架构图：

整个架构分为四大局部：

1. 容器和镜像平安：

• 通过 AAD 认证保障容器认证平安
• 通过 ACR 镜像扫描保障镜像平安

2. 节点和集群平安：

• 节点主动补丁更新
• 节点能够公布到公有网络中

3.Pod 平安：

• 通过 Azure Policy 提供丰盛的平安定义

4. 流量平安：

• 通过存储加密
• 通过 Key Vault 保障秘钥等平安
• 通过 Azure Application Gateway 等保障拜访平安

对于 AKS 的详细信息请参阅相干文档。同时这方面还有一些入手试验，详情可参阅 https://github.com/sme-csu/ak…。

容器的安全性是一个很宏大的话题，限于篇幅，本文不可能一一进行具体介绍。心愿上述内容能起到抛砖引玉的作用，帮忙大家更好地理解相干技术，设计出更平安的容器环境。

如果心愿进一步理解本文涵盖的相干话题，可返回 https://github.com/sme-csu/Ap… 查看相干演示文档和视频教程。

如果有任何意见或倡议，也欢送通过留言进行交换。

有奖问答

绝对于一般容器，特权容器具体减少了哪些权限？咱们如果避免容器晋升为特权容器或者应用特权容器呢？

评论区分享您的观点，咱们将抽取一位侥幸用户，送出 Azure 定制礼品。快来留下您的观点吧!