环境要求

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项目的人交流了

 

 

Logo

K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容

更多推荐