网站建设预付款如何付,apache重定向wordpress,首页优化排名,英文杭州网站建设大家好#xff0c;我是Edison。最近在公司搭建CI流水线#xff0c;涉及到容器镜像安全的话题#xff0c;形成了一个笔记#xff0c;分享与你#xff0c;也希望我们都能够提高对安全的重视。时代背景近年来应用程序逐步广泛运行在容器内#xff0c;容器的采用率也是逐年上…大家好我是Edison。最近在公司搭建CI流水线涉及到容器镜像安全的话题形成了一个笔记分享与你也希望我们都能够提高对安全的重视。时代背景近年来应用程序逐步广泛运行在容器内容器的采用率也是逐年上升。根据 Anchore 发布的《Anchore 2021年软件供应链安全报告》显示容器的采用成熟度已经非常高了65% 的受访者表示已经在重度使用容器了而其他 35% 表示也已经开始了对容器的使用因此基于软件的交付变成了基于容器镜像的交付。业界已经达成共识云原生时代已经到来如果说容器是云原生时代的核心那么镜像应该就是云原生时代的灵魂。镜像的安全对于应用程序安全、系统安全乃至供应链安全都有着深刻的影响。但是容器的安全问题却是大多数IT开发团队所忽视的根据 snyk 发布的 2020年开源安全报告 中指出在 dockerhub 上常用的热门镜像几乎都存在安全漏洞多的有上百个少的也有数十个。具体数据如下图所示不幸的是很多应用程序的镜像是以上述热门镜像作为基础镜像进而将这些漏洞带到了各自的应用程序中增加了安全风险。解决方式GitLab建议我们预防为主防治结合的方式来提高镜像的安全性。所谓防就是要在编写 Dockerfle 的时候遵循最佳实践来编写安全的Dockerfile还要采用安全的方式来构建容器镜像所谓治即要使用容器镜像扫描又要将扫描流程嵌入到 CI/CD 中如果镜像扫描出漏洞则应该立即终止CI/CD Pipeline并反馈至相关人员进行修复后重新触发 CI/CD Pipeline。防的最佳实践1以安全的方式构建容器镜像常规构建容器镜像的方式就是 docker build这种情况需要客户端要能和 docker守护进程进行通信。对于云原生时代容器镜像的构建是在 Kubernetes 集群内完成的因此容器的构建也常用 dinddocker in docker的方式来进行。众所周知dind 需要以 privilege 模式来运行容器需要将宿主机的 /var/run/docker.sock 文件挂载到容器内部才可以否则会在 CI/CD Pipeline构建时收到错误。为了解决这个问题可以使用一种更安全的方式来构建容器镜像也就是使用 kaniko。kaniko是谷歌发布的一款根据 Dockerfile 来构建容器镜像的工具。kaniko 无须依赖 docker 守护进程即可完成镜像的构建。其和GitLab CI/CD的集成也是非常方便的只需要在GitLab CI/CD 中嵌入即可下面是在我司CI Pipeline中的实践variables:EXECUTOR_IMAGE_NAME: gcr.io/kaniko-project/executor EXECUTOR_IMAGE_VERSION: debug
docker-build-job:stage: docker-build-stageimage:name: $EXECUTOR_IMAGE_NAME:$EXECUTOR_IMAGE_VERSIONentrypoint: []rules:- if: $IMAGE_SOURCE_BUILD ! $BUILD_DOCKER_IMAGE true $CI_PIPELINE_SOURCE !merge_request_eventscript:- |- KANIKO_CONFIG{\auths\:{\$CI_REGISTRY_IMAGE\:{\username\:\$CI_REGISTRY_USER\,\password\:\$CI_REGISTRY_PASSWORD\}}}echo ${KANIKO_CONFIG} /kaniko/.docker/config.json- mkdir release- cp -r Build/* release/- |/kaniko/executor \--context ${CI_PROJECT_DIR} \--dockerfile Dockerfile \--destination${CI_REGISTRY_IMAGE}:${BUILD_TAG}2选择合适且可靠的基础镜像Dockerfile 的第一句通常都是 FROM some_image也就是基于某一个基础镜像来构建自己所需的业务镜像基础镜像通常是应用程序运行所需的语言环境比如.NET、Go、Java、PHP等对于某一种语言环境一般是有多个版本的。我司主要使用的是.NET而原生微软的ASP.NET 6.0镜像mcr.microsoft.com/dotnet/aspnet:6.0有5个Critical的安全漏洞一般不建议采用。根据Global项目组的实践建议采用RedHat提供的.NET 6.0运行时镜像该镜像由RedHat维护定期在更新最新更新是一周前目前无Critical的安全漏洞。镜像地址https://catalog.redhat.com/software/containers/ubi8/dotnet-60-runtime/6182efaddd607bfc82e66343docker pull registry.access.redhat.com/ubi8/dotnet-60-runtime:6.0-223不安装非必要的安装包Dockerfile 中应该尽量避免安装不必要的软件包除非是真的要用到。比如我们习惯了直接写 apt-get update apt-get install xxxx。因为安装非必要的软件包除了会造成镜像体积的增大 也会 增加受攻击的风险程度。4以非root用户启动容器在 Linux 系统中root用户意味着超级权限能够很方便的管理很多事情但是同时带来的潜在威胁也是巨大的用 root 身份执行的破坏行动其后果是灾难性的。在容器中也是一样需要以非root 的身份运行容器通过限制用户的操作权限来保证容器以及运行在其内的应用程序的安全性。在 sysdig 发布的《Sysdig 2021年容器安全和使用报告》中显示58% 的容器在以 root 用户运行。足以看出这一点并未得到广泛的重视。因此建议在Dockerfile中添加命令来让容器以非root用户身份启动在我司的CI Pipeline中的实践......USER 0
RUN chown -R 1001:0/opt/app-root fix-permissions /opt/app-root
# No root should run
USER 1001ENV ASPNETCORE_URLShttp://:8080
EXPOSE 8080CMD dotnet ${APPLICATION_DLL}治的最佳实践在CI流水线中加入容器镜像安全扫描任务在 GitLab 中提供了容器镜像分析器Container-Scanning-Analyzer来对生成的容器镜像进行扫描建议将其加入CI Pipeline中进行高频率的检查工作。在我司的CI Pipeline中集成了container-scanning-analyzer来扫描容器镜像如果扫描结果有Critical的漏洞流水线会自动失败阻塞后续Job执行并发送Email提醒。下图给出了一个简单的示例并非我司CI流水线完整流程只有当扫描结果不包含Critical的漏洞时流水线才会被视为成功进而允许后续操作包括Merge开发分支到主干等。参考资料极狐《GitLab DevSecOps七剑下天山之容器镜像安全扫描》https://mp.weixin.qq.com/s/pnP0bjFdXlay42OGghUWNw极狐《云原生时代如何保证容器镜像安全》https://blog.csdn.net/weixin_44749269/article/details/123077566年终总结Edison的2021年终总结数字化转型我在传统企业做数字化转型C#刷题C#刷剑指Offer算法题系列文章目录.NET面试.NET开发面试知识体系.NET大会2020年中国.NET开发者大会PDF资料
