资讯专栏INFORMATION COLUMN

Kubernetes Deployment 的安全最佳实践

oysun / 1409人阅读

摘要:今天的文章由来自的和撰写,在不同用户案例中搜集到的数据基础上,描述了的安全最佳实践。在谷歌上,我们的用来部署我们的服务。实施连续安全缺陷扫描容器可能包含过时的已知缺陷的程序包。谷歌云平台的用户能够从自动防火墙规则中受益,避免跨集群交流。

今天的文章由来自 Aqua Security 的 Amir Jerbl 和 Micheal Chemy 撰写,在不同用户案例中搜集到的数据基础上,描述了 Kubernetes Deployment 的安全最佳实践。

Kubernetes 提供了很多配置来提升应用程序的安全性。但是配置这些需要深入了解 Kubernetes 的初始知识以及一些安全的需求。我们在这里要强调的最佳实践跟容器的生命周期相匹配:创建,运送以及运行,以及为 Kubernetes 特别定制。在谷歌 GCE 上,我们的用 Kubernetes 来部署我们的 SaaS 服务 。

对于部署安全的 Kubernetes 应用程序,我们推荐以下:

确认镜像是没有缺陷

运行没有缺陷的容器会使你的环境面临轻易妥协的威胁。很多攻击都可以简单地通过确认软件组件没有缺陷来减轻。

实施连续安全缺陷扫描
容器可能包含过时的已知缺陷的程序包(CVEs)。而且每天都有缺点被暴露出来,所以这并不是一个“一次性”进程。作为一个连续评估镜像不间断的程序,这个程序对于确保所需安全状态非常重要。

你的环境需要定期申请安全更新
一旦运行中的容器被发现有缺陷,你需要做的就是更新资源镜像,重新部署容器。尝试避免直接更新到运行的容器,因为这样可能会破坏镜像跟容器之间的关系。有了 Kubernetes 的滚动升级功能,升级容器变得十分容易——这个功能可以通过升级镜像到最新版本来慢慢更新运行的应用程序。

确保你的环境中只使用授权的镜像

如果没有程序来确认只有镜像依附在组织机构的策略上,那么组织机构就容易受到有缺陷或者是恶意的容器的攻击。

从未知的资源里下载运行镜像是十分危险的。这就相当于在生产环境的服务器上运行一个未知软件提供商的产品一样。所以,不要那么做。

使用私有库来存储规定镜像——确保你只 push 规定的镜像到这些库。这已经把运行的领域缩小了,减少了可进入管道的数量。

创建集成安全评估(比如漏洞扫描)的 CI 管道,使之成为创建进程的一部分。

CI 管道要确保代码被审查过才能够用来创建镜像。镜像创建好了,就要扫描有没有安全缺陷,如果没有的话,那么镜像就会被 push 到一个私有库,在这个私有库,部署到产品就完成了。安全评估要是失败的话,管道也会相应失败,这样就避免了安全质量不好的镜像被 push 到镜像仓库。
在 Kubernetes 中还有很多需要为镜像授权插件做的工作(期望在 Kubernetes1.4中能够完成),这就避免了运送未授权的镜像。

限制直接访问 Kubernetes 节点

需要限制 SSH 访问 Kubernetes 节点,减少未授权访问主机资源的风险。同时要求用户使用“kubectl exec”,它可以直接访问容器环境,而不需要访问主机。

可以使用 Kubernetes 授权插件来远程控制用户访问资源。这也就意味着要为特定的 namespace,容器和操作来定义细粒度访问控制规则。

在资源间创建管理的边界

限制用户权限的范围能够控制错误或者恶意活动的发生。Kubernetes 的 namespace 允许把创建的资源分割成逻辑的 group。在一个 namespace 中创建的资源在其它的 namespace 中不可见。默认设置下,每个由 Kubernetes 集群用户创建的资源都运行在一个默认 namespace 中,名为 default。你可以创建额外的 namespace,并在该 namespace 中创建资源,然后使用这些资源。你也可以使用 Kubernetes 授权插件来创建策略,来隔离访问不同用户间的 namespace 资源。

比如:以下就是策略允许“alice”从 namespace“fronto”阅读 pods。

定义资源配额

运行资源未装订的容器,你的系统可能面临陷入 DoS 或者“noisy neighbor”场景的风险。为了避免,或者说是将这些风险最小化,你需要定义资源配额。默认设置下,所有在 Kubernetes 集群中的资源都是用 unbounded 的 CPU 和内存要求/限制来创建的。为了限制 Pod 允许使用的 cpu 和 memory 资源,你可以创建资源配额策略,并把这个策略应用到 Kubernetes 的 namespace 上。

以下是 namespace 资源配额定义的一个例子,它限制 namespace 中 pod 的数量不能超过4个,限制他们的 CPU 请求在1到2个之间,内存请求在1GB 到2GB 之间。

compute-resource.yaml:

分配 resource 配额到 namespace:

实施网络分割

在同一个 Kubernetes 集群上运行不同的程序会有风险,就是应用程序可能会受到损坏,然后攻击相邻的程序。容器只能够跟确认的容器进行交流,所以网络分割显得很重要。

Kubernetes 部署面临的一个挑战就是,在 pod,service 和容器间创建分割。这个挑战的原因就是容器网络身份(IPs)的动态特性,当然,容器既可以在同一个节点中交流,也可以在不同节点间交流。

谷歌云平台的用户能够从自动防火墙规则中受益,避免跨集群交流。可以使用网络防火墙或者 SDN 解决方法在内部部署相似的实施。Kubernetes 的 Network SIG(兴趣组)在这方面的做了一些工作,很大程度上提升了 pod 之间的交流的策略。新的网络策略 API 应该在 pods 周围处理创建防火墙规则,限制容器化的网络访问。

以下的例子就是,为“backend”pods 控制网络的网络策略,只允许本地网络访问“frontend”pods:

为你的 pods 和容器申请安全环境

当设计你的容器和 pods 的时候,需要确认给你的 pods,容器和数据卷配置了SecurityGroup。SecurityGroup 可以在 yaml 文件中定义。它控制分配到 pod/container/volume 的安全参数。一些重要的参数如下图所示:

下图是 pod 定义的一个例子:

如果允许有提升权限(--privilege)的容器,你应该考虑使用“DenyEscalatingExec”这个 Admission Controller。这个 Controller 拒绝在 Pod 上运行 exec 和 attach 命令,并且在提升 Pod 的权限时,只允许该 Pod 在宿主机上访问。包括那些以特权模式运行的 Pod,能够访问主机 IPC namespace 的 Pod,以及能够访问主机 PID namespace 的 Pod。

日志记录

Kubernetes 提供基于集群的日志,支持把日志推送到一个中心化的 log hub。创建完集群的时候,使用 Fluentd 代理来收集每个容器的标准输出,标准错误输出。
当集群创建成功以后,每个容器产生的日志(标准输出和标准错误输出)就可以被每个节点上的 Fluent Agent 采集,然后推送到 GoogleStackDriver Logging 或者 Elasticsearch,然后用户可以用 Kibana 来看这些日志。

结论

Kubernetes 提供很多选择来创建安全部署。但是并不存在一个对策解决所有问题这样的好事,所以需要对这些选项有一定的熟悉,同样,也要理解他们是如何提高你的程序的安全性的。
我们推荐实施本文中强调的最佳实践,并且使用 Kubernetes 中灵活的配置功能将安全加工到连续的整合管道,将整个进程用无缝安全进行自动化。

原文链接
转载请联系我们 -3-

文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。

转载请注明本文地址:https://www.ucloud.cn/yun/32493.html

相关文章

  • 京东云Kubernetes集群最佳实践

    摘要:京东云集群最佳实践容器是的基石,它们之间的关系不言而喻。因此我们今天的文章将会和大家分享关于京东云集群的部分最佳实践。京东云集群采用管理节点全托管的方式,为用户提供简单易用高可靠功能强大的容器管理服务。 京东云Kubernetes集群最佳实践 容器是Cloud Native的基石,它们之间的关系不言而喻。了解容器对于学习Cloud Native也是十分重要的。近期,京东云Cloud N...

    XGBCCC 评论0 收藏0
  • 京东云Kubernetes集群最佳实践

    摘要:京东云集群最佳实践容器是的基石,它们之间的关系不言而喻。因此我们今天的文章将会和大家分享关于京东云集群的部分最佳实践。京东云集群采用管理节点全托管的方式,为用户提供简单易用高可靠功能强大的容器管理服务。 京东云Kubernetes集群最佳实践 容器是Cloud Native的基石,它们之间的关系不言而喻。了解容器对于学习Cloud Native也是十分重要的。近期,京东云Cloud N...

    刘永祥 评论0 收藏0
  • 【容器云 UK8S】最佳实践:基于JenkinsCI/CD实践

    摘要:扩展性好当集群的资源严重不足而导致排队等待时,可以很容易的添加一个到集群中,从而实现扩展。用法,选择尽可能使用这个节点镜像,填写,这个容器镜像是我们的运行环境。更新文件,这里我们只是将中的镜像更换成最新构建出的镜像。基于Jenkins的CI/CD实践[TOC]一、概要提到K8S环境下的CI/CD,可以使用的工具有很多,比如Jenkins、Gitlab CI、新兴的drone等,考虑到大多公司...

    Tecode 评论0 收藏0
  • Kubernetes Ingress 高可靠部署最佳实践

    摘要:我们通过阿里云容器服务控制台创建一个集群,这里以创建台节点集群为例。全方位监控集群接入层的监控是必不可少的,您可以通过阿里云容器服务监控以及阿里云云监控对和进行全方位监控。 摘要: 在Kubernetes集群中,Ingress作为集群流量接入层,Ingress的高可靠性显得尤为重要,今天我们主要探讨如何部署一套高性能高可靠的Ingress接入层。 简介 在Kubernetes集群中,I...

    Dionysus_go 评论0 收藏0
  • 容器环境下持续集成最佳实践:构建基于 Drone + GitFlow + K8s 云原生语义化

    摘要:集成测试完成后,由运维同学从发起一个到分支,此时会会运行单元测试,构建镜像,并发布到预发布环境测试人员在预发布环境下再次验证功能,团队做上线前的其他准备工作运维同学合并,将为本次发布的代码及镜像自动打上版本号并书写,同时发布到生产环境。 云原生 (Cloud Native) 是伴随的容器技术发展出现的的一个词,最早出自 Pivotal 公司(即开发了 Spring 的公司)的一本技术小...

    asoren 评论0 收藏0

发表评论

0条评论

oysun

|高级讲师

TA的文章

阅读更多
最新活动
阅读需要支付1元查看
<