- 1、本文档共34页,可阅读全部内容。
- 2、有哪些信誉好的足球投注网站(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
- 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载。
- 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
?
?
基于开源OPA实现Kubernetes资源安全合规基线检查
?
?
【摘要】本文首先简单介绍了Kubernetes的资源治理问题以及准入控制器,然后介绍了OPA以及Rego,最后介绍如何将OPA集成到Kubernetes的准入控制器中实现Kubernetes资源的安全合规自动检测。
1Kubernetes资源治理问题
近年来越来越多的企业选择使用容器用于软件构建和发布,随着DockerSwarm的逐渐没落,毫无疑问Kubernetes已经成为事实上的容器编排工具标准。
目前使用Kubernetes已经不是什么大的难题,基本上几个命令几个yaml文件就能轻易地使应用运行在Kubernetes平台上。
而对于Kubernetes平台运维人员来说关键的挑战在于如何用好Kubernetes以及如何高效治理Kubernetes的资源。因为往往企业应用部署和平台运维是独立负责的,极力推广的DevOps理念大大提升了开发人员的自主性,但是开发人员往往只关注于应用如何部署运行,而很少关注一些跟应用没有直接关系的诸如安全、可靠性、资源配比等因素。
比如:
开发人员可能错误配置liveness以及readiness,甚至根本不配置。
开发人员可能不会想到去合理配置limits以及requests资源,或者错误随意配置limits以及requests资源,设置不合理的比例。
开发人员可能过度滥用容器的capacities权限,容器内部OS用户随意使用root,volume的fsuser、fsgroup设置的uid、gid不合理等。
未设置企业要求的一些元数据标签labels或者注解annotations。
Pod使用未受信任的镜像仓库以及大量使用latest标签的镜像。
而解决如上问题,最有效的方法就是设置准入门槛,不符合规范的请求直接拒绝,而不是先污染后治理。
Kubernetes一开始设计就支持通过准入控制器(AdmissionControllers)方案设置准入门槛,官方也提供了许多现成的准入控制器供用户选择使用。
但是不同的企业可能安全准则、应用最佳实践标准并不一样,现有的准入控制器可能无法完全满足企业的所有需求,重新自研开发控制器则涉及开发成本高,并且后期也不易于维护扩展。
因此,我认为最有效的办法是能通过统一标准的规则引擎实现合规基线检测和修正,针对不同的规范要求,只需要编写对应规则动态注入,无需大量开发控制器插件,无需重启Kubernetes平台。
本文接下来将介绍基于开源OPA实现Kubernetes资源合规基线检查方案。
2关于Kubernetes准入控制
虽然本文主要介绍如何使用OPA执行Kubernetes资源合规基线检查,但其原理离不开Kubernetes的准入控制,因此本文首先简单介绍下Kubernetes自带的准入控制机制。
众所周知,我们每次请求KubernetesAPI时都会经过APIServer的三大核心关口,层层把关:
第一个关口是认证,判定请求用户是谁以及其身份的真实性。关于认证的介绍可以参考我之前的几篇文章浅聊Kubernetes的各种认证策略以及适用场景以及Kubernetes通过Dex集成企业外部认证系统。
第二个关口是授权,判定这个用户是否具有该操作的权限。目前用的比较多的是默认的RBAC插件,即通过role、clusterrole、rolebingding以及clusterrolebingding进行权限访问控制。
第三个关口是准入控制。准入控制是对请求的进一步控制,比如检查请求的资源数量是否超出了配额(Quota)限制,请求的Pod是否符合容器安全要求等。
kubeapi_pilelines
每个关口都有可能存在多个保安插件,Kubernetes支持配置多个认证以及授权引擎从而支持多认证多授权模式。
同理,Kubernetes可以配置多个准入控制器,只有所有准入控制器都判定通过时,请求方可放行。
另外准入控制器还支持对请求的资源进行修改,比如AlwaysPullImages准入控制器会强制修改Pod的imagePullPolicy为Always。
Kubernetes的准入控制与认证授权的设计理念相同,都是通过动态扩展插件的形式实现,每个插件依次串接。官方提供了许多现成的非常实用的准入控制器,比如:
LimitRanger:对请求的CPU、Memory等资源进行范围限制,阻止请求超出设置范围的CPU数量或者内存大小。
ResourceQuota:对Namespace的CPU、内存、Pod数量等资源进行配额限制,如果请求超出Namespace配额,则拒绝服务。
PodSecurity:替换即将被废弃的PodSecurityPolicy,在v1.23中升为Beta版
文档评论(0)