精华内容
下载资源
问答
  • 玩转容器安全二 - 容器安全概述

    千次阅读 2020-11-29 16:43:10
    容器安全概述 根据我自己的理解,将容器安全划分成了6个方向,各个方面还存在二级分支方向,本文就这6个方向及其二级分支展开我对容器安全的理解。话不多说,开篇一幅图,后面全靠编。 承载容器或容器集群的宿主机...

    容器安全概述

    根据我自己的理解,将容器安全划分成了6个方向,各个方面还存在二级分支方向,本文就这6个方向及其二级分支展开我对容器安全的理解。话不多说,开篇一幅图,后面全靠编。

    容器安全概述

    承载容器或容器集群的宿主机的安全性

    首先就是容器宿主机的安全,在一个企业内部,如果划分了基础运维团队与容器团队(CaaS, Container as a Service 容器即服务),那么容器宿主机的安全性由基础运维团队负责,通常与传统基础设施安全保持一致。这块就是一些老生常谈的话题,如:

    • 主机身份鉴别与访问控制:主要是操作系统的特权账号与普通账号管理、账号权限管理、密码策略、登录策略等;
    • 补丁更新:补丁定期更新策略、高危漏洞补丁及时更新策略等。这一块,基础运维团队除了应该关注会对宿主机自身造成中高风险的漏洞,还应关注与Docker相关的漏洞,如:利用DirtyCow漏洞实现Docker逃逸
    • 安全防护能力:主要是部署入侵检测与防护产品、防病毒产品,定期更新安全产品的软件版本与防护策略等;
    • 运行容器的用户权限:这里需要理解一下Docker容器中的uidgid相关概念,就能发现如果使用特权用户启动容器会出现哪些风险,但是根据目前我片面的了解来看,大部分都没有配置特定用户权限来启动容器;
    • 审计和配置容器守护程序目录或文件:/var/lib/docker, /etc/docker, docker.service, docker.socket, /etc/default/docker/, /etc/docker/daemon.json, /usr/bin/docker-containerd, /usr/bin/docker-runc需要对这些文件执行审计,并配置合理的权限,关于审计内容与权限设置的要求,请参见附录Docker容器最佳安全实践白皮书V1.0

    容器软件自身的安全性

    其次就是容器软件Docker自身的安全性,这里我引用了以下链接的部分内容:

    技术干货 | Docker 容器逃逸案例汇集 https://www.cnblogs.com/xiaozi/p/13423853.html

    • docker remote api未授权访问漏洞;

    • docker.sock挂载到容器内部:此场景容易出现在Jenkins CI/CD流程中;

    • docker高危启动参数:

      • --privileged:特权模式,此场景也容易出现在Jenkins CI/CD流程中;
      • -v:挂载敏感目录;
      • --cap-add=SYS_ADMIN:允许执行mount操作;
      • --net=host:绕过Network Namespace;
      • --pid=host:绕过PID Namespace;
      • --ipc=host:绕过IPC Namespace。
    • Shocker攻击

    • CVE-2014-5277:Docker和docker-py代码注入漏洞

    • CVE-2014-6408:Docker权限许可和访问控制漏洞

    • CVE-2014-9357:Docker权限许可和访问控制漏洞

    • CVE-2014-9358:Docker目录遍历漏洞

    • CVE-2015-3627:Docker Libcontainer和Engine权限许可和访问控制漏洞

    • CVE-2015-3630:Docker Libcontainer与Engine安全绕过漏洞

    • CVE-2019-14271:docker cp命令导致容器逃逸

    • CVE-2019-5736:docker runc容器逃逸

    • 更多docker漏洞信息:https://www.cvedetails.com/vulnerability-list/vendor_id-13534/product_id-28125/Docker-Docker.html

    对于容器软件自身的安全性来说,定期更新docker版本或在docker出现高危漏洞时及时更新版本就能解决此类型问题。但由于docker本身是作为底层资源,版本升级可能会要求重启服务这就会影响业务的正常运行。所以我们在解决版本升级这类型的问题时,按以下步骤来解决:

    • 补偿性的控制措施:通过第一节内容保护宿主机安全,加强容器的访问控制,加固运行在容器中的应用程序等实现降级处理;
    • 临时解决方案:通过一些安全产品或官方提供的临时解决方案来保护容器安全,很多时候临时解决方案可以一定层度上规避风险,但不应该将临时解决方案作为最终解决方案;
    • 分阶段进行版本更新:容器在企业内部的使用大都应用了负载均衡技术,我们可以划分阶段来进行版本更新动作,但是如果容器环境管理比较混乱,此方案可行性较低;
    • 新环境中解决此类型的问题:对于后期构建的容器环境必须使用包含补丁的版本。

    整体来说,docker版本升级是高危操作,但依旧需要根据漏洞风险和企业实际情况来制定更新计划,如2018年的docker runc容器逃逸漏洞修复方案:https://developer.aliyun.com/article/690053。

    容器的安全基线与合规性要求

    主流的容器安全基线有两个大的板块:Docker与Kubernetes,CIS分别对其作出了要求,这里我们简单对比一下CIS_Docker_1.13.0_Benchmark_v1.0.0CIS_Kubernetes_Benchmark_v1.5.1

    CIS_Docker_1.13.0_Benchmark_v1.0.0 CIS_Kubernetes_Benchmark_v1.5.1
    Host Configuration Control Plane Components
    Docker daemon configuration etcd
    Docker daemon configuration files Control Plane Configuration
    Container Images and Build File Worker Nodes
    Container Runtime Policies
    Docker Security Operations

    对比两者我们可以发现,Docker基线章节也就是本文的第一章的内容,而Kubernetes基线更多关心的是集群管理的问题,同时Kubernetes安全是基于在Docker安全的拔高要求,在本章的第6节我会简单列举Docker集群的安全性,后期我会通过一篇专门的文章来梳理一下Kubernetes集群的安全性。

    PS:在上述提到的附录Docker容器最佳安全实践白皮书V1.0其实就是翻译了Docker Benchmark内容,推荐大家去看CIS的官方文档,中文翻译有一些描述上的偏差。我将两个文档共享在:https://share.weiyun.com/A3G1wWMo

    容器镜像的安全性

    接下来就是容器安全中尤为重要的一个版块,我将其分为:

    基础镜像的安全性

    镜像是一层一层构建而来,很多操作系统、应用程序的基础镜像构建都是对应的官方与Docker Hub构建的。我们在使用这部分镜像需要注意的是基础镜像包含安全漏洞,如CentOS 5.11与CentOS 6.6的基础镜像中就包含CVE-2014-6277漏洞;其次就是我们使用存在供应链攻击的基础镜像或非官方基础镜像(Bad Image, 恶意镜像),这些镜像中可能包含恶意程序、后门等。

    对于基础镜像的安全性,首先是尽可能不要使用非官方的基础镜像,其次就是需要对使用的基础镜像执行漏洞扫描并修复扫描发现的漏洞。

    镜像构建的安全性

    镜像构建的方式有两种,第一种是拉取基础镜像,然后通过基础镜像创建容器,在容器中执行相应的操作,最后将容器打包成镜像并上传到镜像仓库以备后期;第二种是通过Dockerfile来构建镜像。那么这两种构建过程中可能的安全风险如下:

    • 最小权限原则:软件安装、端口暴露;
    • Dockerfile文件包含敏感信息。

    镜像仓库的安全性

    在企业内部,随着容器化的不断发展,团队会构建私有镜像仓库来存储基础镜像、业务镜像等。其安全性尤为重要,在私有镜像仓库这块,通过我的实践主要是以下几个方面的问题:

    • 镜像仓库是否使用HTTPS:这一点上如果私有仓库不会通过互联网,只通过局域网对镜像仓库即可进行操作则可不予理会;
    • 镜像仓库对镜像的校验能力:目前开源的私有镜像仓库都具备这个能力,但是部分需要手工配置;
    • 镜像仓库的身份鉴别与访问控制:这一点是私有镜像仓库最重要的一点,首先是访问私有镜像仓库需要身份鉴别与认证;其次就是镜像仓库内不同业务的镜像需要具有访问控制的能力;
    • 镜像仓库的审计能力:镜像仓库应该具备对镜像操作的审计能力;

    容器运行时的监控、入侵检测与安全防护

    对于容器资源监控与使用方面,目前已有一些开源或成熟的商业系统可以支持,如Grafana、Prometheus。但是对于容器的安全监控商业产品我了解相对较少,所以我在本文中我只会列出一些容器运行状态下的安全问题:

    • Docker Security Capability:
      • AppArmor: AppArmor(应用程序防护)是一种Linux安全模块,可保护操作系统及其应用程序免受安全威胁;
      • SELinux: SELinux是一个应用程序安全系统,它提供了一个访问控制系统,大大增强了自由访问控制模型;
      • Seccomp: Seccomp是一种Linux内核功能,可用于限制容器中可用的操作;
    • 不使用--privileged参数启动容器;
    • 端口开放必须遵循最小权限原则,不暴露未使用的端口;
      不在容器中启用SSH服务;
    • 不共享主机的网络命名空间(Namespace),也就是不要使用--net=host参数启动容器;
    • 设置故障容器自动重启策略,也就是使用--restart参数;
    • 容器根文件系统设置为只读;
    • 对容器的出口流量进行安全分析,接入NIDS进行分析;

    等等

    容器集群的安全性

    对于容器集群Kubernete安全较重要的如下:

    • 控制对Kubernetes API的访问:TLS APII、API认证与授权;
    • 控制对Kubernetes Kubelet的访问;
    • 在运行时控制工作负载或用户的功能:
      • 限制集群中的资源使用;
      • 控制容器的运行权限;
      • 防止容器加载不必要的内核模块;
      • 限制网络访问;
      • 限制云元数据API访问;
      • 控制Pod可以访问哪些节点。
    • 保护集群组件:
      • 限制访问etcd;
      • 启用审计日志
      • 限制访问alpha或beta功能;
      • 定期轮换基础架构的凭据;
      • 集成第三方组件之前必须执行审计;
      • 加密静止的密钥;
      • 接收安全更新警报并报告漏洞。

    如同上面所说,集群安全已经算是容器安全的另一个主题,所以本文对集群的安全不过多描述(主要是我还没有吃透)。

    容器的安全工具

    容器在前几年发展迅速,安全问题也得到了相应的重视,业内出现了很多针对容器安全的工具。当然工具不是本篇文章的重点,后续我会更新关于容器安全工具的安装、使用与对比。这部分主要来源于:https://sysdig.com/blog/33-kubernetes-security-tools/

    容器安全工具

    未完待更新。

    Appendix

    Docker容器最佳安全实践白皮书V1.0

    https://share.weiyun.com/e01eklAr

    Aliyun Docker and K8s ATT&CK Matrix

    Aliyun Docker and K8s ATTCK Matrix

    Azure K8s ATT&CK Matrix

    微软云 K8s Attck Matrix

    Reference

    • 10个确保微服务与容器安全的最佳实践:http://dockone.io/article/8207
    • 20种终极工具,为你的Docker搭建安全防火墙:https://mp.weixin.qq.com/s/3IFodzE6K7vr1mHEZdZskA
    • 29 Docker security tools compared:https://sysdig.com/blog/20-docker-security-tools/
    • 33个Kubernetes安全工具:https://blog.fleeto.us/post/33-kubernetes-security-tools/
    • 76%都存在漏洞?!Docker镜像安全扫描应该这样做:https://dbaplus.cn/news-160-2275-1.html
    • 2018 绿盟科技容器安全技术报告:http://www.nsfocus.com.cn/upload/contents/2018/11/20181109100414_79051.pdf
    • 2019年度容器安全现状分析:https://mp.weixin.qq.com/s/jtDlMe5SprpZfIfXryAjzg
    • DOCKER SECURITY BEST PRACTICES PART 4 – RUNTIME SECURITY:https://anchore.com/blog/docker-security-best-practices-part-4-runtime-security/
    • Docker Security Guideline:https://docs.docker.com/engine/security/
    • Docker安全入门与实战(一):https://zhuanlan.zhihu.com/p/43586159
    • Docker安全入门与实战(二):https://zhuanlan.zhihu.com/p/43671129
    • Docker安全入门与实战(三):https://zhuanlan.zhihu.com/p/43671511
    • Docker安全入门与实战(四):https://zhuanlan.zhihu.com/p/43673419
    • Docker安全自动化扫描工具对比测试:https://blog.csdn.net/wutianxu123/article/details/83216219
    • Docker容器安全实践:https://www.secrss.com/articles/7016
    • Docker 容器逃逸案例汇集:https://www.cnblogs.com/xiaozi/p/13423853.html
    • Securing a Cluster:https://kubernetes.io/docs/tasks/administer-cluster/securing-a-cluster/
    • 国内首个云上容器ATT&CK攻防矩阵发布,阿里云助力企业容器化安全落地:https://developer.aliyun.com/article/765449?spm=a2c6h.13148508.0.0.29cb4f0ejECYcC
    • 全面易用的镜像漏洞检测工具Trivy:https://blog.fleeto.us/post/introducing-trivy/
    • 容器安全风险解决方案(下篇):https://mp.weixin.qq.com/s/NgIT1tX2uTBt3xJ3Jq9ZdA
    • 容器安全学习课程:https://www.katacoda.com/
    • 容器安全在证券行业的最佳实践:https://mp.weixin.qq.com/s/TFlWF7WcC1lT1X244o4VBw
    • 容器静态安全漏洞扫描工具Clair介绍:https://zhuanlan.zhihu.com/p/43547242
    • 探索容器安全性(概述):http://dockone.io/article/5515
    • 如何打造安全的容器云平台:https://blog.qiniu.com/archives/7743
    • 五个Docker监控工具的对比:http://dockone.io/article/397
    • 云原生之容器安全实践:https://tech.meituan.com/2020/03/12/cloud-native-security.html
    • 针对容器的渗透测试方法:https://mp.weixin.qq.com/s/o5fGivwgBMR-w60SXQbSYA
    展开全文
  • 容器安全指南.pdf

    2020-09-02 22:39:28
    NIST-800-190 应用容器安全指南(中文版)。独自翻译了英文版,欢迎大家提出建议。应用容器技术,也称为容器,是操作系统虚拟化与应用程序软件打包结合的一种形式。容器提供了一种打包,运行应用程序的便携式,可...
  • 文章目录容器安全 - 不要以root用户在容器内运行不要以root用户在容器内运行查看容器内运行的用户指定容器内运行的用户为什么不要以root用户在容器内运行安全原则安全假设安全风险参考文档 容器安全 - 不要以root...

    容器安全 - 不要以root用户在容器内运行

    不要以root用户在容器内运行

    As a best practice, run your containers as a non-root user (UID not 0).

    By default, containers run with root privileges as the root user inside the container.

    容器安全最佳实践中的一条是,不要以root用户在容器内运行。

    而Docker容器内默认以root用户运行。

    当然这一点也不能怪Docker,我们在云供应商租赁一台虚拟机(ECS)时,默认也是以root用户运行。

    查看容器内运行的用户

    以Spring Boot应用的一个简单的Dockerfile为例:

    FROM openjdk:8-jdk-alpine
    ARG JAR_FILE=target/*.jar
    COPY ${JAR_FILE} app.jar
    ENTRYPOINT ["java","-jar","/app.jar"]
    

    构建jar包:

    mvn clean install
    

    构建镜像:

    docker build -t william/springboot-docker .
    

    运行容器:

    docker run --name springboot-docker --rm -p 8080:8080 william/springboot-docker
    

    查看容器内运行的用户:

    docker exec -it springboot-docker whoami
    

    结果为root,也就是说Docker容器内默认以root用户运行。

    指定容器内运行的用户

    在Dockerfile中创建用户和用户组,并指定以该用户和用户组运行。

    FROM openjdk:8-jdk-alpine
    RUN addgroup -S spring && adduser -S spring -G spring
    USER spring:spring
    ARG JAR_FILE=target/*.jar
    COPY ${JAR_FILE} app.jar
    ENTRYPOINT ["java","-jar","/app.jar"]
    

    重新构建镜像和运行容器。

    查看容器内运行的用户:

    docker exec -it springboot-docker whoami
    

    结果为spring, 说明容器内当前运行的用户为spring

    为什么不要以root用户在容器内运行

    安全原则

    最小权限原则:如果不是必须以root用户运行,就不要以root用户运行。

    安全假设

    我们很容器错误地假设容器是“完全”隔离的,在一个容器中做的事情,不会影响到其他容器,也不会影响到宿主机。就像我们在云供应商上租用一个虚拟机(ECS)不会担心会被其他人的虚拟机影响到。

    但是相比虚拟机的隔离,容器的隔离是比较弱的。这就意味着,在一个容器内做的危险操作,可能会影响到其他容器,甚至影响到宿主机。这种突破容器的隔离性的行为也叫容器逃逸(container escape)。

    如果容器内以root用户运行,就会使得恶意攻击变得更加容易。

    安全风险

    如果以root用户在容器内运行会有什么问题?

    • 可能被利用来在容器内安装恶意软件或攻击工具。
    • 增加容器逃逸(container escape)的风险。
    • 增加利用容器基础镜像的操作系统内核漏洞攻击的风险。

    参考文档

    展开全文
  • 容器安全加固方案

    2019-05-20 09:16:59
    Gartner将容器安全列为其本年度十大安全顾虑之一,或许是时候进一步审视并找出切实的容器安全实现方案了。 保护Docker和容器基础设施安全需要打组合拳,综合运用策略、工具和审慎的应用检查。 Gartner将容器...
    导读 Gartner将容器安全列为其本年度十大安全顾虑之一,或许是时候进一步审视并找出切实的容器安全实现方案了。

    保护Docker和容器基础设施安全需要打组合拳,综合运用策略、工具和审慎的应用检查。
    容器安全加固方案容器安全加固方案
    Gartner将容器安全列为其本年度十大安全顾虑之一,或许是时候进一步审视并找出切实的容器安全实现方案了。虽然容器已面世十年,但其轻量且可重用的代码、灵活的功能和更低的开发成本,令容器的流行程度有增无减。但没有什么工具是万能的。我们不妨再仔细考察一下保护开发环境所需的各种工具、容器自身所用工具和出于监视/审计/合规目的的工具吧。
    从以下几个基本步骤开始:

    1. 熟悉云提供商交付的工具

    第一步就是熟悉云提供商的内置安全措施,比如 Azure Security Center、谷歌Kubernetes Engine、谷歌 Cloud Security Command Center和亚马逊Inspector。其中有些是通用安全工具而非容器专用,比如 Azure Security Center。

    2. 熟悉原生Docker相关安全功能

    包括运用策略防止资源滥用、设置访问控制组和确保清除不必要的root权限。

    3. 考虑GitHub开源项目

    某些情况下,Bench Security之类检查代码中最佳安全实践的项目,以及类似seccomp的其他Linux原生工具,是节省开支的不错选择。
    总有很多软件有待学习和理解,但应重点查看几个常用功能,包括为用户及最终生成的应用所设的身份及身份验证措施,以及控制这些访问权限的机制。另外,还需要能够检查并审计日志文件,要能浏览并过滤日志文件以提供有益安全态势的可操作信息。最后,还要有用于保护API密钥和SSL凭证之类秘密的底层基础设施。这些秘密必须以加密形式存储。
    是不是有点头晕目眩了?这还才刚刚开始呢。想要保护公司环境中的容器,下面三个领域是你不得不仔细考虑的。

    4. 保护开发环境

    由于容器对开发人员而言非常有用,所以推进到DevSecOps非常有必要,但要记得在创建容器时即添加安全措施,而不是在项目匆忙上马留下诸多漏洞之后。保证应用安全从来都是最佳实践。在选择正确的安全工具之前,你需要回答以下几个重要问题:
    (1) 能够自动化哪些工作流以保持应用安全?
    有些工具有助于实现该操作,尤其是在编排方面。然而,很多编排工具专注于容器管理和扩展问题,未必考虑到安全细节。找到功能和防护之间的恰当平衡或许没那么容易。
    (2) 应用和用户访问控制的粒度该设成多细?
    这里有必要了解这些控制的实现机制及其局限。比如说,哪些代码段和容器具备root/内核访问权限,是否需要这么高的权限来完成任务。
    (3) 应该使用运行时应用自防护(RASP)技术吗?
    必须的。就像专注应用的RASP常规工具,有些工具专注于容器运行时应用保护,要么有静态扫描,要么利用开发环境持续集成。因为容器代码不停在变,持续集成的形式相当有用;而且拥有持续代码审计也可以在不得不修复或更新时节省大量时间。一款好RASP容器工具应能标记异常行为,缓解潜在威胁,并能够隔离特定事件以供后续进一步取证分析。

    5. 防护托管着容器的底层主机

    大多数情况下,这意味着运行精简版LInux,只留下必要的服务以减小潜在攻击界面。有些工具就是设计来强化主机自身的。另一个办法是采用上面提到过的Docker控制组,以及隔离名字空间以反映你的安全策略和防止容器间相互感染。有些商店使用来自云提供商的虚拟专用连接来实现该隔离操作。该过程包含应用访问级别和其他机制来隔离工作负载,以及限制每台主机上运行的容器数量。出于这个原因,有些商店甚至一台主机只运行一个容器。

    6. 保护容器内容安全

    这里讨论的是镜像的软件供应链。这是构建容器的基石,所以一项重要的基本功能就是要能够保证镜像源完整性防护,也就是当员工或提供原始容器镜像的开源项目对镜像做了修改时,你得清楚到底改动了哪些东西。
    鉴于很多容器都在互联网上共享的事实,能够扫描容器镜像以确保不受感染是一项很有用的功能。那么,你的扫描频率如何,能不能自动化扫描呢?能从可信源获取镜像固然很好,但每个人都会犯错,意外引入安全问题是不可避免的。
    不过,对有些商店,你却不用担心容器里有哪些漏洞。这听起来令人惊讶,但确实有意义——只除了一点:除非你能保证容器边界足够安全,或者你应用程序的实际代码不触及容器代码有漏洞的部分。你对自家安全工具的自信程度,可能是决定漏洞容忍度的最终因素。

    本文地址:https://www.linuxprobe.com/?p=144207

    展开全文
  • 容器技术通过共享主机操作系统内核,实现轻量的资源虚拟化和隔离,近年来在DevOps、微服务等...北京神州绿盟信息安全科技股份有限公司携手硅谷知名容器安全公司NeuVector,联合发布《2018绿盟科技容器安全技术报告》。
  • docker容器安全

    2016-10-25 16:10:00
    title: docker容器安全 tags: Docker,容器,安全策略 grammar_cjkRuby: true --- Docker容器的安全性 1.安全策略-Cgroup 1.限制Cpu docker run --rm -ti -c 2000 ubuntu bash 2.限制内存 docker run --rm -ti -m ...

    title: docker容器安全
    tags: Docker,容器,安全策略
    grammar_cjkRuby: true
    ---

    Docker容器的安全性

    1.安全策略-Cgroup

    1.限制Cpu

    docker run --rm -ti -c 2000 ubuntu bash

    2.限制内存

    docker run --rm -ti -m 200M ubuntu bash

    3.限制快设备io

         docker run --rm -ti --name container1 ubuntu bash
         dd if=/dev/zero of=testfile0 bs=8k mount=5000 oflag=direct
    修改 Cgroup文件
    # 查找容器挂载的文件系统“/dev/mapper”的位置
    $ mount|grep ContainerID
    # 查看容器挂载的文件系统中的文件(Path为上条命令取得的返回结果)
    # 返回结果“->”标记后会有一个新的路径,我们先称其为DeviceFilePath
    $ ls -l Path
    # 查询容器挂载的设备号
    $ ls DeviceFilePath -l
    # 返回结果中“root disk”后面会有一串用“,”隔开的数字,假设是128和256
    # 限制容器的写速度
    $ sudo echo '128:256 10240000' >/sys/fs/cgroup/blkio/system.slice/docker-DockerID.scope/blkio.throttle.write_bps_device
    # 10240000是每秒可写入的最多的字节数。

    2.ulimit

    在Docker1.6之后,可以设置全局默认的ulimit,如设置CPU时间

    sudo docker daemon --default-ulimit cpu=1200
    或者在启动容器时,单独对其ulimit进行设置

    docker run --rm -ti --ulimit cpu=1200 ubuntu bash
    进入容器后可以查看

    ulimit -t
    返回结果:1200

    3. 容器组网

    在接入容器隔离不足的情况下,将受信任的和不受信任的容器组网在不同的网络中,可以降低风险。

    4. 容器 + 全虚拟化

    如果将容器运行在全虚拟化环境中(如在虚拟机中运行容器),这样就算容器被攻破,虚拟机还具有保护作用。目前一些安全需求很高的应用场景采用的就是这种方式,如公有云场景。

    5. 镜像签名

    Docker可信镜像及升级框架(The Update Framework,TUF)是Docker 1.8所提供的一个新功能,可以校验镜像的发布者。当发布者将镜像push到远程仓库时,Docker会对镜像用私钥进行签名,之后其他人pull该镜像的时候,Docker就会用发布者的公钥来校验该镜像是否和发布者所发布的镜像一致,是否被篡改过,是否是最新版。

    6. 日志审核

    docker run --rm -ti --log-driver="syslog" ubuntu bash
    通过docker inspect ContainerID可以看到容器使用了哪种日志驱动。另外,只有json-file支持docker logs命令,docker logs ContainerID。

    7. 监控

    容器的资源使用情况主要指容器对内存、网络I/O、CPU、磁盘I/O的使用情况等,命令:docker stats ContainerID。
    查看容器的运行状态,命令:docker ps -a。

    8. 文件系统级防护

    可读写挂载:
    $ docker run --rm -ti ubuntu bash
    # echo "hello" >/home/test.txt
    # cat /home/test.txt
    
    只读挂载:
    $ docker run --rm -ti --read-only ubuntu bash
    # echo "hello" >/home/test.txt
    # 返回结果:bash:/home/test.txt:Read-only file system

    9. capability

    Capabilities 链接 https://wiki.archlinux.org/index.php/Capabilities_(%E7%AE%80%E4%BD%93%E4%B8%AD%E6%96%87)

    从2.2版开始,Linux有了capability的概念,它打破了Linux操作系统中超级用户/普通用户的概念,让普通用户也可以做只有超级用户才能完成的工作。capability可以作用在进程上,也可以作用在程序文件上。它与sudo不同,sudo可以配置某个用户可以执行某个命令或更改某个文件,而capability则是让程序拥有某种能力。

    每个进程有三个和能力有关的位图:Inheritable(I)\Permitted(P)\Effective(E),我们可以通过/proc//status来查看进程的capability。

    命令:cat /proc/$$/status | grep Cap
    结果:
    # 能够被当前进程执行的程序继承的capability。
    CapInh: 0000000000000000
    # 进程能够使用的能力,可以包含CapEff中没有的能力,这些能力是被进程自己临时放弃的,因此可以把CapEff看作是CapPrm的一个子集。
    CapPrm: ffffffffffffffff
    # 当一个进程要进行某个特权操作时,操作系统会检查CapEff的对应位是否有效,而不再是检查进程的有效UID是否为0。
    CapEff: ffffffffffffffff
    

    Docker启动容器的时候,会通过白名单的方式来设置传递给容器的capability,默认情况下,这个白名单只包含CAP_CHOWN等少数的能力。用户可以通过 -–cap-add 和 -–cap-drop 这两个参数来修改这个白名单。

    $ docker run --rm -ti --cap-drop=chown ubuntu bash
    # chown 2.2/etc/hosts
    # 返回结果:chown:changing ownership of '/etc/hosts': Operation not permitted
    发现禁掉CAP_CHOWN能力后,在容器里就无法改变容器的所有者了。如果不禁掉则正常。如下
    
    $ docker run --rm -ti ubuntu bash
    # chown 2.2/etc/hosts
    容器应遵循最小权限原则,尽量不要用–privileged参数,不需要的能力全部去掉,甚至禁掉所有的能力。
    
    $ docker run --rm -ti --cap-drop=all ubuntu bash

    10. SElinux

    SElinux 介绍链接 http://www.cnblogs.com/xiaoluo501395377/archive/2013/05/26/3100444.html

    SELinux定义了系统中每个用户、进程、应用和文件访问及转变的权限,然后使用一个安全策略来控制这些实体(即用户、进程、应用和文件)之间的交互,安全策略指定了如何严格或宽松的进行检查。另外,SELinux比较复杂。

    11. AppArmor

    文档配置链接 http://manpages.ubuntu.com/manpages/xenial/en/man5/apparmor.d.5.html

    AppArmor也是一种MAC控制机制,其主要作用是设置摸个可执行程序的访问控制权限,可以限制程序读/写某个目录/文件,打开/读/写网络端口等。AppArmor是一个高效和易于使用的Linux系统安全特性,它对操作系统和应用程序进行了从内到外的保护,即使是0day漏洞和未知的应用程序漏洞所导致的攻击也可被识破。AppArmor安全策略可以完全定义个别应用程序所能访问的系统资源与各自的特权,它包含了大量的默认策略,并将先进的静态分析和基于学习的工具结合了起来,可以在很短的时间内,为非常复杂的应用制定AppArmor规则。

    12. Seccomp

    Seccomp(secure computing mode)是一种Linux内核提供的安全特性,它可以实现应用程序的沙盒机制,以白名单或黑名单的方式限制进程进行系统调用。

    Seccomp首次于内核2.6.12版合入Linux主线。早期的Seccomp只支持过滤少数几个系统调用。较新版本的内核支持动态Seccomp策略,也就是seccomp-bpf,因为支持用BPF生成过滤规则,从而使Seccomp可以限制任意的系统调用,并且可以限制系统调用传入的参数。

    Seccomp的使用

    生成BPF形式的过滤规则;
    调用prctl系统调用将规则传入内核。
    在Docker容器启动的过程中,会对Seccomp设置一个默认的配置,但目前还不支持命令行参数做配置。

    13. grsecurity

    grsecurity提供了一个系统的内核patch,使Linux内核的安全性大大增强,并且它提供了一些工具让用户配置、使用这些安全特性。grsecurity可以用来控制资源访问权限。下面是一张关于grsecurity、SELinux和AppArmor的对比图。
    对比图

    相关安全项目

    与Docker安全相关的项目

    1. Notary

    Docker对安全模块进行了重构,剥离出了名为Notary的独立项目。Notary的目标是保证server和client之间的交互使用可信任的连接,用于解决互联网的内容发布的安全性。该项目并未局限于容器应用,在容器场景下可以对镜像源认证、镜像完整性等安全需求提供更好的支持。

    2. docker-bench-security

    docker-bench-security提供一个脚本,它可以检测用户的生产环境是否符合Docker的安全实践。

    Docker安全遗留问题

    在Docker的安全问题上Docker社区做了很多的工作,但Docker依然有不少跟安全相关的问题尚未解决。

    1. User Namespace

    User Namespace可以将host中的一个普通用户映射成容器里的root用户,不过虽然允许进程在容器里执行特权操作,但这些特权只局限于该容器内。这对容器的安全是一个非常大的提升,恶意程序通过容器入侵host或者其他容器的风险大大降低,但这并不意味着容器就足够安全了。另外,由于内核层面隔离性不足,如果用户在容器的一个特权操作会影响到容器外,那么这个特权操作一般也是不被User Namespace所允许的。

    2. 非root运行Docker daemon

    目前Docker daemon需要由root用户启动,而Docker daemon创建的容器以及容器里运行的应用实际上也是以root用户运行的。实现由普通用户启动Docker daemon和运行容器,有益于Docker的安全。但这个问题很难解决,因为创建容器需要执行很多特权,包括挂载文件系统、配置网络等。目前社区还没有一个好的方案。

    3. Docker热升级

    Docker管理容器的方式是中心式管理,容器由主机上的Docker daemon进程统一管理。中心式管理方式对于第三方的任务编排工具并不友好,因为什么功能都需要跟Docker关联起来。更大的问题是,如果Docker daemon挂掉了,重启daemon后,它无法接管容器,容器也不能运行了。在实际应用中,很多业务都是不能中断的,而停止容器就往往相当于停止业务,但如果因为安全漏洞的原因需要升级Docker,用于就将处于两难的境地。点击了解该问题的进展。

    3. 磁盘限额

    默认情况下,Docker镜像、容器rootfs、数据卷都存放在/var/lib/docker目录里,也就是说跟host是共享同一个文件系统的。如果不对Docker容器做磁盘大小的配额限制,容器就可能用完磁盘的可用空间,导致host和其他容器无法正常工作。
    但是目前Docker几乎没有提供任何接口用于限制容器的磁盘大小。但graphdriver为devicemapper时,容器会被默认分配一个100GB的空间。这个空间大小可以在启动Docker daemon时设置为另一个默认值,但无法对每个容器单独设置一个不同的值。

    $ sudo docker daemon --storage-opt dm.basesize=5G

    除此之外,用户只能通过其他手段自行做一些隔离措施,例如为/var/lib/docker单独分配一个磁盘或分区。

    4. 网络I/O

    目前同一台机器上的Docker容器会共享宽带,但这可能出现某个容器占用大部分带宽资源,从而影响其他需要网络资源的容器正常工作的情况。Docker需要一个好的网络方案,除了要解决容器跨主机通信的问题,还要解决网络I/O限制的问题。

    转载于:https://www.cnblogs.com/yunpiao111/p/5997096.html

    展开全文
  • 容器安全对您业务的重要意义.pdf 容器安全对您业务的重要意义.pdf 容器安全对您业务的重要意义.pdf
  • DoSec安全团队参考CIS标准,并根据实践经验,整理了国内第一份的docker容器安全最佳实践白皮书,涉及了需要关注docker安全的105个控制点。
  • 在Docker容器技术兴起的初期,对于许多企业而言,容器安全问题一直是他们在生产环境中采用Docker的一大障碍。然而,在过去的一年中,许多开源项目、初创公司、云供应商甚至是Docker公司自己,已经开始打造用于强化...
  • Docker容器安全性分析

    2020-08-16 10:28:50
    本文对Docker容器在应用中可能面临的安全问题和风险进行了研究,并将Docker容器应用环境中的安全机制与相关解决方案分为容器虚拟化安全、容器安全管理、容器网络安全三部分进行分析。 一、从虚拟化安全到容器安全 1...
  • 固定式压力容器安全监察规程固定式压力容器安全监察规程固定式压力容器安全监察规程固定式压力容器安全监察规程固定式压力容器安全监察规程
  • Docker与容器安全

    千次阅读 2016-09-01 16:22:05
    Docker与容器安全 Docker能否大规模用于生产环境,尤其是公有云环境,就在于Docker是否能提供安全的环境。本文将总结《Docker容器与容器云》一书3.9节『Docker与容器安全』的主要内容,包括Docker现有安全机制、...
  • 10家专注容器安全的厂商星期一, 四月 24, 20170时至今日,几乎每个技术相关行业都把安全当成了重中之重,云计算中重要的容器技术也不例外。容器的早期承诺之一,是利用从Linux继承来的多个原生安全功能,提供更敏捷...
  • linux 容器 容器提供了一种打包应用程序并将其从开发到测试再到生产的无缝... 企业需要强大的安全性,任何在容器中运行基本服务的人都会问:“容器安全吗?” 和“我们可以信任容器与我们的应用程序吗?” 保护容...
  • redhat提供的基于容器安全,在namespace、Cgroup等技术层面,简述容器安全性的策略。
  • 容器安全产品能力与架构分析 市场容器安全产品能力比较 市场上容器运行安全的产品和工具主要分为商业产品和开源工具,商业类的产品根据防护的侧重点不同分为通用的容器防护和容器网络的安全产品,但有些产品功能有...
  • 辅助专家系统在电站压力容器安全评定中的应用,郭伟杰,荆洪阳,针对电厂典型压力容器,结合数据库和专家系统知识,利用Visual Basic开发了含缺陷压力容器安全评定专家系统。该系统可以对几种主要压
  • 本文讲的是Joyent公司CTO谈容器安全:安全性是容器部署面临的首要问题【编者的话】随着容器技术的发展,越来越多的IT企业开始关注容器技术。面对视安全如生命的企业级项目,如何才能帮助他们快速扫清拥抱容器技术的...
  • 8月6日,腾讯安全和青藤云安全共同举办容器安全平台新品战略合作发布会,基于腾讯安全提供的高效稳定的云服务为基础,以青藤的最新容器安全平台为依托,打造青藤蜂巢·容器安全平台,助力企业客户有效解决安全上云...
  • 探索容器安全性:概述

    千次阅读 2018-05-24 11:42:09
    【编者的话】本文是Google云平台(GCP)上的容器安全性系列博客文章中的第一篇,介绍了容器安全的以下几个方面:基础设施安全、软件供应链和运行时安全,并澄清了容器不是强大的安全边界,可能要依靠Google云平台...
  • 压力容器安全技术监察规程,主要涉及压力容器方面安全技术
  • 为了更好地了解并实现Web容器的安全管理,笔者以两篇博客的篇幅来介绍,即:《Web容器安全管理(上)——Java EE的安全概念》 和 《Web容器安全管理(下)——容器基本身份验证》。上篇博客已经介绍了Java EE安全的...
  • 容器安全01:docker漏洞扫描

    千次阅读 2020-06-19 19:21:47
    镜像是容器的最基础的载体,docker作为最流行的容器runtime,其最大的贡献就是把镜像作为容器应用的标准交付方式,镜像包含了容器运行的所有基础文件,可以说镜像的安全就决定了容器安全。 但现实不乐观,在...
  • 容器安全保护容器的完整性。这包括从其保管的应用到其所依赖的基础架构等全部内容。容器安全需要完整且持续。通常而言,企业拥有持续的容器安全包含以下方面: 保护容器管道和应用 保护容器部署环境和基础架构 整合...
  • 容器因其轻量且可重用的代码,功能更灵活...容器安全面临很多挑战:容器使用共享操作系统(OS)模型,对主机操作系统中的漏洞的攻击可能导致所有容器被攻击,且容器本身可能并不安全。基于此,金山云安全的vampire师傅...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 15,487
精华内容 6,194
关键字:

容器安全