Kubernetes API Server 中有一个功能,能让用户(对工作负载)进行决策,这一功能在 1.9 中已经走入成熟期。
Admission 是 Kubernetes 中最强大的工具之一,可以通过限制创建对象的方式来增强 Kubernetes 集群的安全性,这部分一直是编译在代码之中的。在 1.9 中,我们将 Admission 的 Webhook 升级成 Beta,让用户可以在 API Server 之外对 Admission 施加影响。
Admission 是什么?
Admission(注1),是在认证之后,资源持久化之前 的一个处理 API Server 请求的步骤。Admission 能获取到和认证过程一致的信息(用户、URL 等),以及绝大多数 API 请求的完整报文。
Admission 阶段由不同插件组成,每个 Admission 都会对一个侧面进行观察和操作。例如:影响调度决策的PodNodeSelector、阻止恶意容器的PodSecurityPolicy以及实现 Namespace 资源分配的ResourceQuota。
Admission 内部分为两个阶段:
- 变更(Mutation,突变?):能够修改 API 请求的报文,还可以拒绝 API 请求。
- 验证:允许进行查询,以及拒绝 API 请求。
Admission 插件可以在这两个阶段起作用,但是变更总是在验证之前。
Mutation
Admission 的变更功能可以在资源生成之前进行修改。在 Admission 链条上可以多次修改同一个字段,因此插件不是无序的。
PodNodeSelector就是一个例子,他使用 Namespace 的一个注解namespace.annotations[“scheduler.alpha.kubernetes.io/node-selector”],在其中查找标签选择器,并将其加入pod.spec.nodeselector字段。这一功能限制某个 Namespace 的 Pod,只能运行在指定节点上,同 Taint 的功能正好相反(也是 Admission 插件)。
验证
Admission 的验证阶段用来对特定 API 资源进行验证。这一阶段会在所有变更执行结束之后,API 资源不再发生变化的情况下进行。
PodNodeSelector插件同样演示了这一活动,他确保 Pod 的spec.nodeSelector字段符合该 Namespace 的限制。如果变更链上有其他 Admission 尝试在PodNodeSelector之后修改了资源的spec.nodeSelector,就会在验证阶段因为不符合限制而被拒绝创建。
Admission Webhook 是什么?
Admission webhook 允许 Kubernetes 安装者或集群管理员无需重新编译就可以加入 Admission 插件,像其他基于 k8s.io/apiserver 1.9 的扩展 API Server(例如 metrics(注 2), service-catalog(注 3) 、以及 kube-projects(注 4))一样。两种 Admission Webhook 都在各自的链条尾端运行,和编译的 Admission 插件具有同样的能力和限制。
有什么好处?
Webhook Admission 插件允许对任何 API Server 的任何资源进行变更和验证,所以可能有多种形态的应用,比较普通的用例包括:
- 修改 Pod 这样的资源。Istio 使用这一功能来把 Sidecar 注入到 Pod 之中。当然也可以编写插件强制把 Image Tag 改写为 Image SHA。
- 在多租户系统中,保留命名空间是一个常见情况。
- 复杂的 CustomResource 校验。对插件来说,整个资源都是可见的,因此可以对依赖字段甚至外部依赖资源进行复杂的校验(例如 LimitRanges)。
- 安全响应。可以编写一个插件,强制将 Image Tag 转换为 Image SHA,并阻止特定的 Image 运行。
注册
Webhook Admission 插件需要注册,所有的 API Server(Kube API server 以及所有扩展 API Server)都共享一个配置。在注册过程中插件需要提供如下信息:
- 如何连接到 Webhook Admission 服务。
- 如何验证 Webhook Admission Server。
- 把请求发送到这个服务器的哪里(URL)。
- 处理哪些资源和 HTTP 动词。
- 如果连接失败,API Server 怎么办。
apiVersion: admissionregistration.k8s.io/v1beta1 kind: ValidatingWebhookConfiguration metadata: name: namespacereservations.admission.online.openshift.io webhooks: - name: namespacereservations.admission.online.openshift.io clientConfig: service: namespace: default name: kubernetes path: /apis/admission.online.openshift.io/v1alpha1/namespacereservations caBundle: KUBE_CA_HERE rules: - operations: - CREATE apiGroups: - "" apiVersions: - "*" resources: - namespaces failurePolicy: Fail
name:Webhook 的名称。变更类的 Hook 会使用名称进行排序。 clientConfig:如何连接,证书信任,以及如何向 Webhook Admission 服务器发送数据。 rules:API Server 应该在什么时机调用 Webhook。这里只有创建 Namespace 的时候才触发。这里可以指定任何资源,例如serviceinstances.servicecatalog.k8s.io的create操作也是可以定义的。 failurePolicy:如果 Webhook Admission 服务器无法连接,如何处置?有两个选项分别是 ”Ignore“(失败就通过) 和 ”Fail“(失败就拒绝)。失败则通过的设置,可能会导致无法预测的行为。
认证和信任
因为 Webhoo Admission 插件能够获取任何发送过来的请求资源的内容,并且能进行变更,所以很有必要回答下面的问题:
- API Server 如何检验 Webhook Admission Server。
- Webhook Server 如何精确认证接入进来的 API Server。
- 接入的 API Server 是否被授权发送请求。
连接主要分为三种:
- 从 Kube API Server 以及扩展 API Server 到外部的 Admission Webhook(可能是部署在集群之外)。
- 从 Kube API Server 到自有 Admission Webhooks。
- 从扩展 API Server 到自有 Admission Webhooks。
要支持这些类别,Webhook Admission 插件可以用一个 kubeconfig 文件来得知如何连接到独立的服务器。为了和外部的 Admission Webook 进行通信,因为认证、授权都是外部服务器处理的,因此只能手工指定,别无他法。
自有服务来说,一个明智的插件会提供缺省的安全设施,提供简单、安全、可移植、零配置,并可以在各个 API Server 运行的能力。
简单、安全、可移植、零配置
如果把 Webhook Admission 服务器构建成扩展 API Server 的模式,就有可能把它聚合为一个普通的 API 服务器,会收到如下益处:
- 你的 Webhook 会和其他 API 一样,以类似 kube-apiserver kubernetes.default.svc (例如 https://kubernetes.default.svc/apis/admission.example.com/v1/mymutatingadmissionreviews)服务的面目出现。可以使用kubectl进行测试。
- 无需任何配置,你的 Webhook 自动具有了集群内置的认证和授权能力,可以使用 RBAC 规则进行访问控制。
- API Server 和 Webhook 之间可以直接使用内置认证进行通信。
- 因为通过 Kube API Server 代理通信,因此扩展 API Server 不会泄露 Service Account Token。
简单说来,这一安全拓扑可以使用 API Server 的所有安全机制,并且无需额外配置。
其他用法也是可以的,不过就需要附加的手工配置,以及大量的额外工作来完成同等目标。
如何开发 Webhook admission 服务器?
编写一个具有认证和鉴权能力的完整的服务是个令人生畏的任务。为简化这一工作,有些基于 Kubernetes 1.9 的项目提供了库支持,能把代码量缩减到两百行甚至更少。可以参考 generic-admission-apiserver(注 5)以及 kubernetes-namespace-reservation(注 6)作为创建自己的安全、可移植的 Webhook Server 的示例。
在 1.9 中有了 Admission Webhook,让 Kubernetes 更加贴近用户需求,我们希望 Red Hat 和 Google 的这一工作能让支持更多的工作负载,为整体生态贡献更多(例如 Istio),现在是时候试一试了!
如果有兴趣做出贡献或者反馈,请加入 SIG API machinery(注 7)
注:
- https://kubernetes.io/docs/admin/admission-controllers/#what-are-they
- https://github.com/kubernetes/metrics
- https://github.com/kubernetes-incubator/service-catalog
- https://github.com/openshift/kube-projects
- https://github.com/openshift/generic-admission-server
- https://github.com/openshift/kubernetes-namespace-reservation
https://github.com/kubernetes/community/tree/master/sig-api-machinery
登录后评论
立即登录 注册