由于传播、利用本公众号亿人安全所提供的信息而造成的任何直接或者间接的后果及损失,均由使用者本人负责,公众号亿人安全及作者不为此承担任何责任,一旦造成后果请自行承担!如有侵权烦请告知,我们会立即删除并致歉。谢谢!
随着 Docker 的兴起,越来越多的项目采用 Docker 搭建生产环境,因为容器足够轻量化,可以快速启动并且迁移业务服务,不过在使用的过程中,我们很容易就忽略了项目的安全问题,容器虽然有隔离的作用,但是我们知道,他与虚拟机的架构差距还是比较大的。
本文是关于容器安全的文章,展示了 10 种强化 Docker 基础架构并保护容器和数据免受恶意攻击的方法。
Docker实现原理:https://zone.huoxian.cn/d/1034-docker
我们大多数熟悉 Unix 类系统的人,都习惯于通过使用 sudo 来随意提升自己的权限,成为 root 用户。我们在使用 Docker 容器的过程中知道,他提供了一个 --privileged 的参数,其实它与随意使用 sudo 有很大的不同,它可能会让你的应用程序面临不必要的风险,下面我们将向你展示这与以 root 身份运行的区别,以及特权的实际含义。
随意使用 root 和特权可能会带来不必要的风险。本文展示了特权与 root 运行方式的不同之处以及特权的实际意义。
在Docker中Privileged是一种特殊的权限模式,它允许Docker容器在启动时获取到与宿主机相同的权限级别。具体来说,Privileged权限可以让容器拥有以下能力:
本文基于我今年在DockerCon上的演讲。它将讨论 Docker 容器安全性,我们当前的位置以及未来的发展方向。
容器以及编排工具(例如Kubernetes)开创了应用开发的新时代,让微服务架构以及CI/CD的实现成为了可能。Docker是迄今为止最主要的容器运行时引擎。然而,使用Docker容器构建应用也引入了新的安全挑战和风险。
跟其他添加Docker容器的第三方工具一样(比如网络拓扑和文件系统共享),有很多类似的机制,在不改变Docker内核情况下就可以加固现有的容器.
Docker默认设置可以保护主机容器内的进程访问资源,虽然Docker容器内的初始进程运行为root,但它具有的权限是非常有限的,这主要是通过使用以下几种主要的安全机制来实现的:
应用程序的容器化涉及将应用程序代码及其依赖项(所需的库,框架和配置文件)打包在虚拟容器中。这种方法有助于可移植性,并且可以在各种计算环境和基础架构中一致地运行,而不会降低效率。
在每一个 Kubernetes 节点中,运行着 kubelet,负责为 Pod 创建销毁容器,kubelet 预定义了 API 接口,通过 GRPC 从指定的位置调用特定的 API 进行相关操作。而这些 CRI 的实现者,如 cri-o, containerd 等,通过调用 runc 创建出容器。runc 功能相对单一,即针对特定的配置,构建出容器运行指定进程,它不能直接用来构建镜像,kubernetes 依赖的如 cri-o 这类 CRI,在 runc 基础上增加了通过 API 管理镜像,容器等功能。
runc是一个遵循oci标准的用来运行容器的命令行工具。runc的使用非常灵活,可以与各种容器工具和平台集成,如Docker、Kubernetes等。
容器安全是实施和管理像Docker这样的容器技术的关键方面。它包括一组实践、工具和技术,旨在保护容器化应用程序及其运行的基础架构。在本节中,我们将讨论一些关键的容器安全考虑因素、最佳实践和建议。
Docker 采用的是 C/S 架构,使用 REST API、UNIX 套接字或网络接口进行通信。一般客户端会和 Docker 服务运行在同一台机子上,像我们平常使用的 docker build、pull、run 等命令就是发送到本地客户端上的,本地客户端再发送给 Docker 服务端。另外,客户端也可以独立部署,像 Docker Compose。
在 Kubernetes 中安全地运行工作负载是很困难的,有很多配置都可能会影响到整个 Kubernetes API 的安全性,这需要我们有大量的知识积累来正确的实施。Kubernetes 在安全方面提供了一个强大的工具 securityContext,每个 Pod 和容器清单都可以使用这个属性。在本文中我们将了解各种 securityContext 的配置,探讨它们的含义,以及我们应该如何使用它们。
Pod中的,runAsUser 能指定 Pod 中的所有容器内的进程都使用用户 ID runAsUser 来运行。而如果容器中也设置了runAsUser则以容器中设置的优先,服务启动将以runAsUser设置的用户ID运行。 runAsGroup
今天别人给我了一个 linux 主机的远程登录方式,让我上去帮他安装个 docker。这么简单的事情不是手到擒来吗。于是开始搞
当获得一个Webshell,我们的攻击点可能处于服务器的一个虚拟目录里,一台虚拟机或是一台物理机,甚至是在一个Docker容器里。
网上大多数教程使用的都是以 Ubuntu(例如:Ubuntu:16.04 )作为基础镜像,这并不是一个问题,但是我建议优先考虑 Alpine 镜像:
前言 企业中使用容器承载业务,除了考虑到容器的优势之外,容器的安全更是很多客户关心的话题。本篇文章就此进行讨论。本文在书写过程中,参考了一些文档,文后给出了链接。本文仅提供技术参考,并不能直接用于生产
0.不要使用特权容器 描述 使用--privileged标志将所有Linux内核功能赋予容器,从而覆盖--cap-add和--cap-drop标志。 确保不使用它。 --privileged标志为容器提供了所有功能,并且还解除了设备cgroup控制器强制执行的所有限制。 换句话说,容器可以完成主机可以做的几乎所有事情。 存在此标志是为了允许特殊用例,例如在Docker中运行Docker
runC社区于2024年2月1日披露了高危安全漏洞CVE-2024-21626,攻击者可以利用该漏洞越权访问宿主机文件或执行二进制程序,详细内容参见下文
当容器具有SYS_ADMIN的Capability的话,则可以进行容器逃逸。它允许大量的特权操作,包括mount文件系统,交换空间,还有对各种设备的操作以及系统调试相关的调用。
Kaniko 是 Google 造的轮子之一,用于在 Kubernetes 上无需特权模式构建 docker image。
Linux对Namespace的操作,主要是通过clone、setns和unshare这3个系统调用来完成的,clone创建新进程时,接收一个叫flags的参数,这些flag包括CLONE_NEWNS、CLONE_NEWIPC、CLONE_NEWUTS、CLONE_NEWNET(Mount namespace)、CLONE_NEWPID和CLONE_NEWUSER,用于创建新的namespace,这样clone创建出来新进程之后就属于新的namespace了,后续新进程创建的进程默认属于同一namespace。
(本文的内容主要来源于Google、百科和学过的一些专栏,目前没有实际的企业级应用容器化部署经验,写的比较浅薄见笑了)
AppArmor 主要的作用是设置某个可执行程序的访问控制权限,可以限制程序 读/写某个目录/文件,打开/读/写网络端口等等。
2.容器不是虚拟化:运行在Docker容器中的程序接口和主机的Linux内核直接打交道,可以帮助使用已经内置到操作系统中的容器技术
Docker是一项革命性的容器化技术,于2013年由Docker公司推出。在Docker出现之前,软件部署和运行环境配置是一项复杂且耗时的任务。开发人员需要在不同的系统中进行适配和配置,这导致了“在我的机器上可运行”的问题。传统的虚拟机解决了一部分问题,但它们占用了大量的系统资源,并且启动速度较慢。Docker的诞生解决了这些问题,引领了一场容器化技术的革命。
Docker、containerd和Podman是三种流行的容器技术,允许开发人员和系统管理员创建、运行和管理容器化应用程序。虽然这些技术之间有一些相似之处,但它们之间存在显着的差异。在本文中,我们将比较Docker、containerd和Podman。
DevOps概念的流行跟近些年微服务架构的兴起有很大关系,DevOps是Dev(Development)和Ops(Operations)的结合,Dev负责开发,Ops负责部署上线,Docker出现之前,公司需要搭建一个数据库环境,有了Docker之后,只需在一些开源的基础镜像上构建出公司自己的镜像即可。
随着越来越多的企业开始上“云”,开始容器化,云安全问题已经成为企业防护的重中之重。
Docker是当今使用范围最广的开源容器技术之一,具有高效易用的优点。然而如果使用Docker时采取不当安全策略,则可能导致系统面临安全威胁。
Docker 是一个开源的应用容器引擎,让开发者可以打包他们的应用以及依赖包到一个可移植的镜像中,然后发布到任何流行的 Linux或Windows操作系统的机器上,也可以实现虚拟化。容器是完全使用沙箱机制,相互之间不会有任何接口。
Docker通过namespace(命名空间)实现资源隔离。Namespace是Linux系统提供的资源隔离机制,只有在同一个namespace下的进程可以互相联系,但无法感受外部进程的存在,从而实现资源隔离。
在将业务迁移到容器云环境时,应该注意哪些事项呢?下文我们总结了6个注意事项,帮助您安全使用容器。
为了更精细地控制Pod对资源的使用方式,Kubernetes从1.4版本开始引入了PodSecurityPolicy资源对象对Pod的安全策略进行管理,并在1.1版本中升级为Beta版,到1.14版本时趋于成熟。
描述: 在企业中信息系统安全与业务是同样重要, 随着传统运维方式向着容器化运维方式的转变,当下企业里通常都会采用Docker来进行容器化部署和承载业务, 由于运维人员或者开发人员对容器安全的关注较少, 只是简单认为容器是有隔离和限制的, 就算是容器被黑客攻击了, 也单单是容器内部受到影响, 而对宿主的 Linux 系统和网络都不会产生太大影响。其实不然Docker容器安全也是重中之重, 它关乎着应用与数据安全,其中也关乎着宿主机的安全。
一、背景 云鼎实验室近期捕获到TeamTNT黑客团伙新的容器攻击活动。挖矿病毒通过扫描docker remote api未授权访问漏洞进行传播。相比之前TeamTNT黑客团伙使用的挖矿木马,新变种对原挖矿木马进行了升级,在进行感染时使用了新的策略。 入侵后会先清理其他挖矿病毒,并使用新的方法隐藏进程,入侵完毕后会清理痕迹,覆盖系统日志以逃避排查,为增加挖矿木马植入的成功率还有备用挖矿程序,增加木马的稳定性,利用nohup命令防止挖矿进程被挂断,并且使用了LKM rootkit技术隐藏进程。 样本属于最新版
近期笔者在进行相关调研时,读到一篇总结容器环境下渗透测试方法的2020年毕业论文,作者是Joren Vrancken,就读于荷兰奈梅亨大学计算机科学专业。
与其他介绍Docker的文章不同,由本文开启的系列文章将专注于Docker安全研究,一共分为6部分。
用了这么久的docker,对docker的实现原理挺感兴趣的,在对Linux下docker的实现原理了解之后,我没有用过Windows下的docker,更加好奇Windows下的docker是如何实现的(它并不开源),问了问owefsad师傅,说是可能用到了hyperV,那么可能类似Vmware吗?不知道啊。
runC是一个开源项目,由Docker公司(之前称为Docker Inc.)主导开发,并在GitHub上进行维护。它是Docker自版本1.11起采用的默认容器运行时(runtime),也是其他容器编排平台(如Kubernetes)的基础组件之一。因此在容器生态系统中,runC扮演着关键的角色。runC是一个CLI工具,用于根据Open Container Initiative(OCI)规范在Linux系统上生成和运行容器。它是一个基本的容器运行时工具,负责启动和管理容器的生命周期,包括创建、运行、暂停、恢复和销毁容器。通过使用runC,开发人员和运维人员可以更加灵活地管理容器,并且可以在不同的容器平台之间实现容器的互操作性。
概括 Docker与传统虚拟机的区别 与传统虚拟机的区别 Docker的安装 的安装 Docker daemon , client , containerd 镜像与容器操作 容器运行配置 Docker网络配置 网络配置 Alpine Docker Image 制作自己的 Docker Image Docker安全性问题 安全性问题 Docker运行原理
领取专属 10元无门槛券
手把手带您无忧上云