gatekeeper实践

环境要求

gatekeeper是基于k8s的 admission controller webhooks实现的,需要k8s的 kube-apiserve开启相应的准入控制,也就是 validating admission webhook和mutating admissionwebhook.

  • 关于admission controller webhooks可以参考:链接
  • kube-apiserver每个参数的含义:链接
  • admission controller的介绍:链接

开启方式描述如下:

  • 针对二进制安装kube-apiserver的集群,可以直接修改kube-apiserver的启动参数,在目前的环境中(kube-apiserver是使用二进制安装在mater上的),修改方式如下
    1. 登录到k8s的master节点上
    2. 修改/etc/default/kube-apiserver文件,修改“--admission-control”的参数值 ,加上“MutatingAdmissionWebhook, ValidatingAdmissionWebhook”,注意添加顺序
    3. 重启kube-apiserver, service kube-apiserver restart

 

gatekeeper安装

gatekeeper的安装是使用了 kubectl apply -f 的命令,官方已经提供了yam文件
关于gatekeeper安装有个需要注意的地方。gatekeeper部署之后会生成一个 ConstraintTemplate的CRD对象,在 kubernetes里面,CRD对象在apply之后并不会立即生效,也就是你使用 kubectl apply命令之后相应的CRD对象还并不可用,你需要等待一段时间;你可以使用命令 kubectl get
ConstraintTemplate命令进行查看,只有当命令显示是 No resources found的时候才表示成功,可用;你必须确保在Constraint Template可用之后,才可以安装相应的模板和约束,否则是无法成功的;相同的问题也会发生在新建模板CRD之后,要基于模板CRD建立新的约束对象,这种情况下也要先确保模板CRD已经完成部署(使用 kubectl get<模板crd名称>,命令显示 No resourcesfound)

另外也可以直接使用kubectl get crd的方式,查看对于的crd的AGE是不是<Invalid>,只有当AGE不为<Invalid>而是一个数字时,才表示这个资源对象可用

相关链接:github issuce

 

gatekeeper是否支持warn级别的约束

不支持,这种不支持是因为gatekeeper是基于k8s的admission来实现的,具体可以看 github issuce

 

如何实现细粒度的约束控制

在 gatekeeper中,如果你想将某些约束应用在部分资源对象,诸如命名空间或者Pod的话,可以配置spec. match

 

如何获取约束的审计信息

假如我们部署了K8sRequiredLables 模板对象,和基于这个模板的约束对象ns-must-have-gk,我们希望查看这个约束对象的审计信息,则命令是 kubectl get K8sRequiredLables ns-must-have-gk -o yaml,通过上述的命令可以打印 ns-must-have-gk约束对象的yam格式表示,通过它
的 status对象可以获取该约束的审计信息

 

如果出现约束部署成功了,但是不起作用或者 status没有显示的情况,可能原因

  1. constraints的yam文件拼写出错,诸如 apiGroups打错
  2. 没有添加资源对象的spec.match,或者 spec.match添加错误,特别是 apiGroups

如果部署模板CRD之后,使用 kubectl get crd没有看到新建的模板

这种情况多半就是模板的rego语法出错了,可以先使用 kubectl get ConstraintTemplate取模板CRD名称,再 kubectl get ConstraintTemplate <xx> -o yam获取 status查看语法出错的位置

 

gatekeeper的Policy里面的rego语法

要写这种语法,建议就是把相关的资料都看一次,然后参考官方的来写。

学习链接有:

可以参考的例子有:

另外就是上Slack跟opa项目的人交流了

 

 

对于在 MTK 平台上移植 Gatekeeper,以下是一些基本的步骤和指导: 1. 了解 MTK 平台:首先,您需要了解 MTK 平台的体系结构和安全架构。研究 MTK 平台的文档、开发者指南和安全相关的资料,以便了解其安全功能和验证机制。 2. 确认可用性:检查 MTK 平台是否已经提供了类似 Gatekeeper 的安全功能。某些平台可能已经具备了类似的验证和授权机制,您只需了解如何使用这些功能。 3. 移植验证逻辑:如果 MTK 平台没有类似的功能,您需要根据 Gatekeeper 的逻辑和要求,在 MTK 平台上实现签名验证和应用程序来源的验证。这可能需要修改和适配 Gatekeeper 的验证逻辑,并编写适用于 MTK 平台的代码。 4. 签名验证:Gatekeeper 依赖签名来验证应用程序的来源和完整性。您需要了解 MTK 平台上的签名验证机制,并根据其要求进行相应地修改。 5. 权限管理:Gatekeeper 还负责管理用户对应用程序的访问权限。您需要确定 MTK 平台是否提供了类似的权限管理机制,并将 Gatekeeper 的权限管理功能集成到该平台中。 6. 测试和调试:在移植完成后,进行全面的测试和调试以确保 Gatekeeper 在 MTK 平台上正常工作。测试可以包括验证应用程序的签名验证、权限管理和访问控制等方面。 请注意,MTK 平台的内部结构和安全机制可能与其他平台不同,因此移植 Gatekeeper 时需要根据 MTK 平台的要求进行相应的修改和适配。确保在进行移植前详细了解 MTK 平台的文档和指南,并遵循最佳实践以确保安全性和正确性。 希望这些信息对您有所帮助!如果您有任何进一步的问题,请随时提问。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值