mirror of
https://github.com/LCTT/TranslateProject.git
synced 2024-12-23 21:20:42 +08:00
130 lines
13 KiB
Markdown
130 lines
13 KiB
Markdown
Linux 容器安全的 10 个层面
|
||
======
|
||
|
||
> 应用这些策略来保护容器解决方案的各个层面和容器生命周期的各个阶段的安全。
|
||
|
||
|
||
|
||
容器提供了打包应用程序的一种简单方法，它实现了从开发到测试到投入生产系统的无缝传递。它也有助于确保跨不同环境的连贯性，包括物理服务器、虚拟机、以及公有云或私有云。这些好处使得一些组织为了更方便地部署和管理为他们提升业务价值的应用程序，而快速地采用了容器技术。
|
||
|
||
|
||
|
||
企业需要高度安全，在容器中运行核心服务的任何人都会问，“容器安全吗？”以及“我们能信任运行在容器中的应用程序吗？”
|
||
|
||
对容器进行安全保护就像是对运行中的进程进行安全保护一样。在你部署和运行你的容器之前，你需要去考虑整个解决方案各个层面的安全。你也需要去考虑贯穿了应用程序和容器整个生命周期的安全。
|
||
|
||
请尝试从这十个关键的因素去确保容器解决方案栈不同层面、以及容器生命周期的不同阶段的安全。
|
||
|
||
### 1. 容器宿主机操作系统和多租户环境
|
||
|
||
由于容器将应用程序和它的依赖作为一个单元来处理，使得开发者构建和升级应用程序变得更加容易，并且，容器可以启用多租户技术将许多应用程序和服务部署到一台共享主机上。在一台单独的主机上以容器方式部署多个应用程序、按需启动和关闭单个容器都是很容易的。为完全实现这种打包和部署技术的优势，运营团队需要运行容器的合适环境。运营者需要一个安全的操作系统，它能够在边界上保护容器安全、从容器中保护主机内核，以及保护容器彼此之间的安全。
|
||
|
||
容器是隔离而资源受限的 Linux 进程，允许你在一个共享的宿主机内核上运行沙盒化的应用程序。保护容器的方法与保护你的 Linux 中运行的任何进程的方法是一样的。降低权限是非常重要的，也是保护容器安全的最佳实践。最好使用尽可能小的权限去创建容器。容器应该以一个普通用户的权限来运行，而不是 root 权限的用户。在 Linux 中可以使用多个层面的安全加固手段，Linux 命名空间、安全强化 Linux（[SELinux][1]）、[cgroups][2] 、capabilities（LCTT 译注：Linux 内核的一个安全特性，它打破了传统的普通用户与 root 用户的概念，在进程级提供更好的安全控制）、以及安全计算模式（ [seccomp][3] ），这五种 Linux 的安全特性可以用于保护容器的安全。
|
||
|
||
### 2. 容器内容（使用可信来源）
|
||
|
||
在谈到安全时，首先要考虑你的容器里面有什么？例如 ，有些时候，应用程序和基础设施是由很多可用组件所构成的。它们中的一些是开源的软件包，比如，Linux 操作系统、Apache Web 服务器、Red Hat JBoss 企业应用平台、PostgreSQL，以及 Node.js。这些软件包的容器化版本已经可以使用了，因此，你没有必要自己去构建它们。但是，对于你从一些外部来源下载的任何代码，你需要知道这些软件包的原始来源，是谁构建的它，以及这些包里面是否包含恶意代码。
|
||
|
||
### 3. 容器注册（安全访问容器镜像）
|
||
|
||
你的团队的容器构建于下载的公共容器镜像，因此，访问和升级这些下载的容器镜像以及内部构建镜像，与管理和下载其它类型的二进制文件的方式是相同的，这一点至关重要。许多私有的注册库支持容器镜像的存储。选择一个私有的注册库，可以帮你将存储在它的注册中的容器镜像实现策略自动化。
|
||
|
||
### 4. 安全性与构建过程
|
||
|
||
在一个容器化环境中，软件构建过程是软件生命周期的一个阶段，它将所需的运行时库和应用程序代码集成到一起。管理这个构建过程对于保护软件栈安全来说是很关键的。遵守“一次构建，到处部署”的原则，可以确保构建过程的结果正是生产系统中需要的。保持容器的恒定不变也很重要 — 换句话说就是，不要对正在运行的容器打补丁，而是，重新构建和部署它们。
|
||
|
||
不论是因为你处于一个高强度监管的行业中，还是只希望简单地优化你的团队的成果，设计你的容器镜像管理以及构建过程，可以使用容器层的优势来实现控制分离，因此，你应该去这么做：
|
||
|
||
* 运营团队管理基础镜像
|
||
* 架构师管理中间件、运行时、数据库，以及其它解决方案
|
||
* 开发者专注于应用程序层面，并且只写代码
|
||
|
||
|
||
|
||
最后，标记好你的定制构建容器，这样可以确保在构建和部署时不会搞混乱。
|
||
|
||
### 5. 控制好在同一个集群内部署应用
|
||
|
||
如果是在构建过程中出现的任何问题，或者在镜像被部署之后发现的任何漏洞，那么，请在基于策略的、自动化工具上添加另外的安全层。
|
||
|
||
我们来看一下，一个应用程序的构建使用了三个容器镜像层：内核、中间件，以及应用程序。如果在内核镜像中发现了问题，那么只能重新构建镜像。一旦构建完成，镜像就会被发布到容器平台注册库中。这个平台可以自动检测到发生变化的镜像。对于基于这个镜像的其它构建将被触发一个预定义的动作，平台将自己重新构建应用镜像，合并该修复的库。
|
||
|
||
一旦构建完成，镜像将被发布到容器平台的内部注册库中。在它的内部注册库中，会立即检测到镜像发生变化，应用程序在这里将会被触发一个预定义的动作，自动部署更新镜像，确保运行在生产系统中的代码总是使用更新后的最新的镜像。所有的这些功能协同工作，将安全功能集成到你的持续集成和持续部署（CI/CD）过程和管道中。
|
||
|
||
### 6. 容器编配：保护容器平台安全
|
||
|
||
当然了，应用程序很少会以单一容器分发。甚至，简单的应用程序一般情况下都会有一个前端、一个后端、以及一个数据库。而在容器中以微服务模式部署的应用程序，意味着应用程序将部署在多个容器中，有时它们在同一台宿主机上，有时它们是分布在多个宿主机或者节点上，如下面的图所示：
|
||
|
||
|
||
|
||
在大规模的容器部署时，你应该考虑：
|
||
|
||
* 哪个容器应该被部署在哪个宿主机上？
|
||
* 那个宿主机应该有什么样的性能？
|
||
* 哪个容器需要访问其它容器？它们之间如何发现彼此？
|
||
* 你如何控制和管理对共享资源的访问，像网络和存储？
|
||
* 如何监视容器健康状况？
|
||
* 如何去自动扩展性能以满足应用程序的需要？
|
||
* 如何在满足安全需求的同时启用开发者的自助服务？
|
||
|
||
考虑到开发者和运营者的能力，提供基于角色的访问控制是容器平台的关键要素。例如，编配管理服务器是中心访问点，应该接受最高级别的安全检查。API 是规模化的自动容器平台管理的关键，可以用于为 pod、服务，以及复制控制器验证和配置数据；在入站请求上执行项目验证；以及调用其它主要系统组件上的触发器。
|
||
|
||
### 7. 网络隔离
|
||
|
||
在容器中部署现代微服务应用，经常意味着跨多个节点在多个容器上部署。考虑到网络防御，你需要一种在一个集群中的应用之间的相互隔离的方法。一个典型的公有云容器服务，像 Google 容器引擎（GKE）、Azure 容器服务，或者 Amazon Web 服务（AWS）容器服务，是单租户服务。他们让你在你初始化建立的虚拟机集群上运行你的容器。对于多租户容器的安全，你需要容器平台为你启用一个单一集群，并且分割流量以隔离不同的用户、团队、应用、以及在这个集群中的环境。
|
||
|
||
使用网络命名空间，容器内的每个集合（即大家熟知的 “pod”）都会得到它自己的 IP 和绑定的端口范围，以此来从一个节点上隔离每个 pod 网络。除使用下面所述的方式之外，默认情况下，来自不同命名空间（项目）的 pod 并不能发送或者接收其它 pod 上的包和不同项目的服务。你可以使用这些特性在同一个集群内隔离开发者环境、测试环境，以及生产环境。但是，这样会导致 IP 地址和端口数量的激增，使得网络管理更加复杂。另外，容器是被设计为反复使用的，你应该在处理这种复杂性的工具上进行投入。在容器平台上比较受欢迎的工具是使用 [软件定义网络][4] (SDN) 提供一个定义的网络集群，它允许跨不同集群的容器进行通讯。
|
||
|
||
### 8. 存储
|
||
|
||
容器即可被用于无状态应用，也可被用于有状态应用。保护外加的存储是保护有状态服务的一个关键要素。容器平台对多种受欢迎的存储提供了插件，包括网络文件系统（NFS）、AWS 弹性块存储（EBS）、GCE 持久磁盘、GlusterFS、iSCSI、 RADOS（Ceph）、Cinder 等等。
|
||
|
||
一个持久卷（PV）可以通过资源提供者支持的任何方式装载到一个主机上。提供者有不同的性能，而每个 PV 的访问模式被设置为特定的卷支持的特定模式。例如，NFS 能够支持多路客户端同时读/写，但是，一个特定的 NFS 的 PV 可以在服务器上被发布为只读模式。每个 PV 有它自己的一组反应特定 PV 性能的访问模式的描述，比如，ReadWriteOnce、ReadOnlyMany、以及 ReadWriteMany。
|
||
|
||
### 9. API 管理、终端安全、以及单点登录（SSO）
|
||
|
||
保护你的应用安全，包括管理应用、以及 API 的认证和授权。
|
||
|
||
Web SSO 能力是现代应用程序的一个关键部分。在构建它们的应用时，容器平台带来了开发者可以使用的多种容器化服务。
|
||
|
||
API 是微服务构成的应用程序的关键所在。这些应用程序有多个独立的 API 服务，这导致了终端服务数量的激增，它就需要额外的管理工具。推荐使用 API 管理工具。所有的 API 平台应该提供多种 API 认证和安全所需要的标准选项，这些选项既可以单独使用，也可以组合使用，以用于发布证书或者控制访问。
|
||
|
||
这些选项包括标准的 API key、应用 ID 和密钥对，以及 OAuth 2.0。
|
||
|
||
### 10. 在一个联合集群中的角色和访问管理
|
||
|
||
在 2016 年 7 月份，Kubernetes 1.3 引入了 [Kubernetes 联合集群][5]。这是一个令人兴奋的新特性之一，它是在 Kubernetes 上游、当前的 Kubernetes 1.6 beta 中引用的。联合是用于部署和访问跨多集群运行在公有云或企业数据中心的应用程序服务的。多个集群能够用于去实现应用程序的高可用性，应用程序可以跨多个可用区域，或者去启用部署公共管理，或者跨不同的供应商进行迁移，比如，AWS、Google Cloud、以及 Azure。
|
||
|
||
当管理联合集群时，你必须确保你的编配工具能够提供你所需要的跨不同部署平台的实例的安全性。一般来说，认证和授权是很关键的 —— 不论你的应用程序运行在什么地方，将数据安全可靠地传递给它们，以及管理跨集群的多租户应用程序。Kubernetes 扩展了联合集群，包括对联合的秘密数据、联合的命名空间、以及 Ingress objects 的支持。
|
||
|
||
### 选择一个容器平台
|
||
|
||
当然，它并不仅关乎安全。你需要提供一个你的开发者团队和运营团队有相关经验的容器平台。他们需要一个安全的、企业级的基于容器的应用平台，它能够同时满足开发者和运营者的需要，而且还能够提高操作效率和基础设施利用率。
|
||
|
||
想从 Daniel 在 [欧盟开源峰会][7] 上的 [容器安全的十个层面][6] 的演讲中学习更多知识吗？这个峰会已于 10 月 23 - 26 日在 Prague 举行。
|
||
|
||
### 关于作者
|
||
|
||
Daniel Oh；Microservives；Agile；Devops；Java Ee；Container；Openshift；Jboss；Evangelism
|
||
|
||
|
||
|
||
--------------------------------------------------------------------------------
|
||
|
||
via: https://opensource.com/article/17/10/10-layers-container-security
|
||
|
||
作者：[Daniel Oh][a]
|
||
译者：[qhwdw](https://github.com/qhwdw)
|
||
校对：[wxy](https://github.com/wxy)
|
||
|
||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||
|
||
[a]:https://opensource.com/users/daniel-oh
|
||
[1]:https://en.wikipedia.org/wiki/Security-Enhanced_Linux
|
||
[2]:https://en.wikipedia.org/wiki/Cgroups
|
||
[3]:https://en.wikipedia.org/wiki/Seccomp
|
||
[4]:https://en.wikipedia.org/wiki/Software-defined_networking
|
||
[5]:https://kubernetes.io/docs/concepts/cluster-administration/federation/
|
||
[6]:https://osseu17.sched.com/mobile/#session:f2deeabfc1640d002c1d55101ce81223
|
||
[7]:http://events.linuxfoundation.org/events/open-source-summit-europe
|