Docker安全性(一)——Docker容器真的安全吗?

Docker安全性(一)——Docker容器真的安全吗?

本文翻译自Daniel J Walsh的一篇开源文章:http://opensource.com/business/14/7/docker-security-selinux

这篇文章是基于一个演讲中"今年在我DockerCon上的分享":http://v.youku.com/v_show/id_XODQwNjUwNTIw.html

这将讨论Docker容器的安全性,我们目前正在做什么,和我们将朝哪里走。

这是一个系列Docker安全的一部分,阅读第二部分

容器不包含一切,包括安全

我听到和读到了很多人假定Docker的容器实际上是沙箱应用程序,这意味着他们可以在他们的系统以root身份运行的Docker随机的应用程序。他们相信Docker容器实际上保护他们的主机系统。
?我听到有人说,Docker容器同样是安全的,因为在不同的虚拟机/ KVM正在运行的进程。
?我知道人们正在下载随机Docker镜像,然后启动他们自己的主机上。
?我甚至看到的PaaS服务器(还不是OpenShift)可以让用户上传自己的照片,以在多租户系统上运行。
?我有一个同事谁说:“Docker即将运行从Internet下载的随机代码,并作为root运行它”

“你能走进我的客厅里?”蜘蛛对苍蝇说。

停止假设Docker和Linux内核保护你免受恶意软件侵害。

你关心吗?

如果你是不是在多租户系统运行Docker,你正在使用一个容器中运行的服务,良好的安全实践,你也许并不需要担心。姑且认为在容器内运行的特权进程是相同的运行在容器外部特权进程。

有些人做容器的认为比正在运行的虚拟机的更好,更快的方法的错误。从安全的角度来看,容器要弱得多,我将在本文后面掩盖。

如果你相信,我这样做, - 意思视为运行Apache你把Apache服务的系统上运行的方式相同容器中Docker的容器应被视为“容器服务”,这意味着你会做以下几点:
?尽快删除权限
?尽可能以非root运行您服务
?容器内款待root,就好像它是root容器的以外

目前,我们正在告诉人们在一般条件到一个容器内处理权限的进程具有相同条件的容器外运行的特权进程。

不要在系统上运行随机的Docker图像。在很多方面我看Docker容器革命类似于1999年左右的Linux的革命。在那个时候,当管理员听到一个新酷Linux的服务,他们会:
?在像rpmfind.net的地方或者只是随机的的网站在Internet上搜索包
?下载程序到他们的系统
?如果通过RPM安装或使安装
?与特权运行它

怎么会错呢?

两个星期后,管理员听到关于zlib的脆弱性和具有搞清楚,如果,同时希望并祈祷这不是,他们的软件是脆弱的!

这是Red Hat分发等少数可信方已加强在扭转败局。红帽企业Linux管理员提供:
?一个值得信赖的存储库,他们可以从下载软件
?安全更新修复漏洞
?一个安全响应小组发现和管理漏洞
?一个工程师团队来管理/维护包和安全增强工作
?通用标准认证检查操作系统的安全性

仅运行可信方容器。我相信你应该继续从谁你已经从过去得到它一样的人得到您的代码/包。如果代码不是来自内部或受信任的第三方,不靠容器技术来保护你的主机。

那么,问题是什么?为什么容器中不包含那些内容?

最大的问题就是一切在Linux中没有命名空间。目前,Docker使用五个命名空间来改变系统的流程视图:过程,网络,安装,主机名,共享内存。

虽然这些给用户的安全性的某种程度它绝不是全面,像KVM。在KVM环境中虚拟机进程不跟主机内核直接。他们没有任何访问内核的文件系统,如/ sys和/sys/fs, /proc/*。

设备节点用来交流内核的虚拟机不是主机。因此,为了有一个特权提升了虚拟机,该过程必须subvirt(一个基于虚拟机的后门)虚拟机的内核,发现在管理程序中的漏洞,通过SELinux的控制突破(sVirt),这是非常紧的在虚拟机上,最后攻击主机内核。

当你在一个容器中运行你已经读懂了你在哪里聊到主机内核。

主要的内核子系统都没有命名空间,如:
?SELinux的
?cgroup中
?在/ sys下的文件系统
?/proc/sys, /proc/sysrq-trigger, /proc/irq, /proc/bus

设备没有命名空间:
?/ dev/ MEM
?/ dev/ SD*文件系统设备
?内核模块

如果你能沟通或攻击的其中之一作为特权的过程中,你可以拥有自己的系统。

本文翻译自Daniel J Walsh的一篇开源文章:http://opensource.com/business/14/7/docker-security-selinux

PPT的大概内容页面:

Are Docker containers really secure?

Bringing new security features to Docker

How to grant rights to users to use Docker in Fedora

PPT的大概内容:

dockercon14 San Francisco June 9-10, 2014
 Docker and SELinux
Daniel J Walsh
Serior Principal Software Engineer
@rhatdan,danwalsh.livejournal.com,[email protected]

Containers do not contain

Do you care?

Everything in Linux is not namespaced
Not comprehensive like kvm
Kernel file systems:/sys,/sys/fs,/proc/sys
Cgroups,SELinux,/dev/mem,kernel modules

Treat container services just like regular services
Drop Privileges as quickly as possible
Run your services as non Root whenever possible
Treat root within a container as if it is root outside of the container
Don‘t run random containers on your system
Only run containers from trusted parties

Overview of security within docker containers
Read only mount points
/sys
/proc/sys
/proc/sysrq-tigger
/proc/irq
/proc/bus

Capabilityies
man capabilities

Description
For the purpose of performing permission checks, traditional UNIX implementations distinguish two categories of processes: privileged process (whose

effective user ID is 0, referred to as superuser or root), and unprivileged processes (whose effective UID is nonzero).
Privileged processes bypass all kernel permission checks, while unprivileged processes are subject to full permission checking based on the process‘s

credentials (usually: effective UID, effective GID, and supplementary group list).

Stating with kenel 2.2, Linux divedes the privileges traditionally associated with superuser into distinct units, know as capabilities, which can be

independently enabled and disabled. Capabilities are a per-thread attribute.

Capabliities removed
CAP_SETPCAP Modify process capablities
CAP_SYS_MODULE Insert/Remove kernel modules
CAP_SYS_RAWIO Modify Kernel Memory
CAP_SYS_PACCT Configure process accounting

...

SELinux gotchas
SELinux does not work with BTFS
Volume Mounts /var/lib/myapp
chcon -Rt svirt_sandbox_file_t/var/lib/myapp
Pull request for automatic labeling:
docker run -v /var/lib/myapp:/var/lib/myapp:Z ...
docker run -v /var/lib/myapp:/var/lib/myapp:z ...

Future
Ueser Name Space
libseccomp
--opt to all you to tighten security
--opt - Drop Capabilities
--opt - Alternate SELinux Types

时间: 2024-10-31 02:49:58

Docker安全性(一)——Docker容器真的安全吗?的相关文章

Docker的单主机容器网络

作者:杨冬 欢迎转载,也请保留这段声明.谢谢! 出处: https://andyyoung01.github.io/ 或 http://andyyoung01.16mb.com/ 本篇文章主要探索Docker的单机容器网络,了解一下单个Docker主机上网络的各种模式,从而为后续理解跨主机容器网络打下基础. Docker默认容器网络的建立和控制是一种结合了network namespace,iptables,Linux网桥及route table等多种技术的综合解决方案,本篇主要针对于如何使用单

docker技术剖析--docker网络(二)docker宿主机之间容器互通

http://hongge.blog.51cto.com/ 多台物理主机之间的容器互联(暴露容器到真实网络中) docker 默认的桥接网卡是 docker0 .它只会在本机桥接所有的容器网卡,举例来说容器的虚拟网卡在主机上看一般叫做 vethxxx,而 docker 只是把所有这些网卡桥接在一起,如下: 这样就可以把这个网络看成是一个私有的网络,通过 nat 连接外网,如果要让外网连接到容器中,就需要做端口映射,即 -p 参数. 如果在企业内部应用,或则做多个物理主机的集群,可能需要将多个物理

SELinux的Docker安全性

原文译自:http://opensource.com/business/14/7/docker-security-selinux 这篇文章基于我今年在DockerCon一个讲座,它将讨论我们当前听到的Docker容器的安全问题. 容器并不"包容" 我听到也读到许多假定Docker容器是应用沙盒的观点--这意味着他们可以在他们的系统上使用有根权限的Docker来运行任意的程序. 他们相信Docker容器将会保护他们的主机系统. 我听到人们说Docker容器就像在VMs/KVM执行程序一样

Docker安全性(二)——带来了新的安全功能给Docker

Docker安全性(二)--带来了新的安全功能给Docker 本篇翻译自Daniel J Walsh的一篇开源文章:http://opensource.com/business/14/9/security-for-docker 作者的演讲视频:http://v.youku.com/v_show/id_XODQwNjUwNTIw.html 在这系列的第一篇Docker的安全性,我写了"容器中不包含".在第二篇文章中,我将讨论为什么我们这样做并且我们正在对它做什么. Docker,红帽和开

Docker安全性——官方文档[译]

Docker安全性--官方文档[译] 本文译自Docker官方文档:https://docs.docker.com/articles/security/ 在审查Docker的安全时,需要考虑三个主要方面:?容器内在的安全性,由内核命名空间和cgroup中实现;?docker守护程序本身的攻击面;?加固内核安全特性,以及它们如何与容器中互动. 内核 命名空间 Kernel Namespace Docker容器中非常相似LXC容器,并且它们都具有类似的安全功能.当您以"docker run"

Docker 数据卷与容器互联(3)

title: Docker 数据卷与容器互联(3) date: 2018-12-15 14:50:42 tags: Docker categories: Docker copyright: true --- Docker是基于Go语言实现的开源容器项目,Docker让开发者可以打包他们的应用以及依赖包到一个可移植的容器中,然后发布到任何流行的 Linux 机器上,也可以实现虚拟化.容器是完全使用沙箱机制,相互之间不会有任何接口,Docker诞生于2013年年初,最初发起者是dotCloud公司.

Docker之七---Docker存储卷与容器卷详解

1.存储卷介绍 1.1 背景 (1)docker 的 AFUS 分层文件系统 docker镜像由多个只读层叠加而成,启动容器时,docker会加载只读镜像层并在镜像栈顶部加一个读写层: 如果运行中的容器修改了现有的一个已经存在的文件,那该文件将会从读写层下面的只读层复制到读写层,该文件版本仍然存在,只是已经被读写层中该文件的副本所隐藏,此即“写时复制(COW)”机制. 描述:如果一个文件在最底层是可见的,如果在layer1上标记为删除,最高的层是用户看到的Layer2的层,在layer0上的文件

Docker的镜像、容器和仓库

Docker本身的镜像是构建在其本身的文件系统之上的,Docker有很多种类的文件系统,Docker所支持的文件系统有以下几种:Aufs.devicemapper.btrfs和VFS,其中前三种是联合文件系统,可以支持分层,可以快速迭代,可以回滚.VFS 不支持.平时用的最多的是aufs 和devicemapper.Aufs(advanced multilayered unification filesystem), 直译过来就是高级分层联合文件系统,做为一种Union FS ,它支持将不同的目

Docker的镜像和容器

Docker image详细介绍 在之前的介绍中,我们知道docker images 是docker的三大组件之一. docker把下载的 images 存储到docker主机上,如果一个 image 不在主机上,docker会从一个镜像仓库下载,默认的仓库是  DOCKER HUB  公共仓库. 接下来将介绍更多关于docker images 的内容,包括: 使用和管理本地主机上的 images 创建一个基础的 images 上传 images 到docker hub (公共 images 仓