Kubernetes 可扩展 Admission 进入 Beta 阶段
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),现在是时候试一试了!
本文转自kubernetes中文社区-Kubernetes 可扩展 Admission 进入 Beta 阶段
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
Kubernetes源码之旅:从kubectl到API Server
概述: Kubernetes项目目前依然延续着之前爆炸式的扩张。急需能够理解Kubernetes原理并且贡献代码的软件开发者。学习Kubernetes源码并不容易。Kubernetes是使用相对年轻的Go语言编写,并且拥有大量的源代码。在这个系列的多篇文章里,我将为大家深入分析Kubernetes的关键源码,以及介绍那些帮助我理解源码的技术。我的目标是提供一系列的文章,让对于Kubernetes还较为陌生的开发者能够快速学习Kubernetes源码。 在第一篇文章里,我会分析从运行一个简单的kubectl命令到向API Server发送REST调用的源码执行过程。在开始深入Kubernetes之前,我建议你先阅读一下Julia Evans对Kubernetes架构的高级概述分析的文章。 Kubectl命令的基本运行 Kubernetes里的命令行接口叫做kubectl。它用来控制Kubernetes集群。阅读这部分源码实现是一个好的开始。我们要追踪的命令是kubectl create -f——它会从文件创建K8s资源。我们要创建的资源是使用了Nginx基础镜像的单副本Pod。下面是它的...
- 下一篇
k8s使用calico网络
calico是一个安全的 L3 网络和网络策略提供者。 calico使用bgp的原因:why bgp not ospf 有关BGP rr的介绍 安装方式 标准托管安装(ETCD存储) 需要提前安装etcd集群 # 创建calico连接etcd的secret kubectl create secret generic calico-etcd-secrets \ --from-file=etcd-key=/etc/kubernetes/ssl/kubernetes-key.pem \ --from-file=etcd-cert=/etc/kubernetes/ssl/kubernetes.pem \ --from-file=etcd-ca=/etc/kubernetes/ssl/ca.pem # 部署 kubectl create -f https://docs.projectcalico.org/v3.0/getting-started/kubernetes/installation/hosted/calico.yaml # rbac kubectl apply -f https://d...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- CentOS关闭SELinux安全模块
- CentOS7编译安装Gcc9.2.0,解决mysql等软件编译问题
- Windows10,CentOS7,CentOS8安装MongoDB4.0.16
- Hadoop3单机部署,实现最简伪集群
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果
- CentOS6,CentOS7官方镜像安装Oracle11G
- Eclipse初始化配置,告别卡顿、闪退、编译时间过长
- SpringBoot2全家桶,快速入门学习开发网站教程
- CentOS8编译安装MySQL8.0.19
- CentOS6,7,8上安装Nginx,支持https2.0的开启