近一段时间来，“云原生”已成为企业应用开发和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 定制礼品。快来留下您的观点吧!