K8s准入控制Admission Controller深入介绍

 更新时间:2022年04月01日 15:21:30   作者:张晋涛  
本篇我们将聚焦于 kube-apiserver 请求处理过程中一个很重要的部分 -- 准入控制器(Admission Controller)深入讲解,有需要的朋友可以借鉴参考下,希望能够有所帮助,祝大家多多进步早日升职加薪

在我之前发布的文章 《云原生时代下的容器镜像安全》(系列)中,我提到过 Kubernetes 集群的核心组件 -- kube-apiserver,它允许来自终端用户或集群的各组件与之进行通信(例如,查询、创建、修改或删除 Kubernetes 资源)。

K8s 的准入控制器是什么

K8s 中的请求处理流程

在聊 K8s 准入控制器是什么之前,让我们先来回顾一下 Kubernetes API 的处理具体请求的过程。

图 1 ,Kubernetes API 处理请求的过程 (从 API Handler 到 etcd 持久化的过程)

如上图所示,每个 API 的请求从开始被 kube-apiserver 接收到最终持久化到 ETCD 的过程,即为 Kubernetes API 的请求处理流程。

它主要包含了以下几个部分:

API Handler -- 主要负责提供服务,接收请求。

对于其内部实现而言,请求会先到 FullHandlerChain (它是由 DefaultBuildHandlerChain 构建出来的)是一个 director 对象

type director struct {
	name               string
	goRestfulContainer *restful.Container
	nonGoRestfulMux    *mux.PathRecorderMux
}

director根据配置进行初始化,如果 goRestfulContainer的 WebServices 的 RootPath 是 /apis,或者请求前缀与 RootPath 匹配,则进入 Restful 处理链路。

Authentication -- 认证的流程。

在TLS 连接建立后,会进行认证处理,如果请求认证失败,会拒绝该请求并返回 401 错误码;如果认证成功,将进行到鉴权的部分。目前支持的客户端认证方式有很多,例如:x509 客户端证书、Bearer Token、基于用户名密码的认证、OpenID 认证等。由于这些内容不是本篇的重点我们暂且跳过,感兴趣的小伙伴可以在评论区留言讨论。

Authorization -- 鉴权的流程。

对于 Kubernetes 而言,支持多种的鉴权模式,例如,ABAC 模式,RBAC 模式和 Webhook 模式等。我们在创建集群时,可以直接为 kube-apiserver 传递参数进行配置,这里也不赘述了。

Mutating Admission -- 指执行可用于变更操作的准入控制器,下文中会详细介绍。

Object Schema Validation -- 对资源对象的 schema 校验。

Validating Admission -- 指执行可用于验证操作的准入控制器,下文中会详细介绍。

ETCD -- ETCD 实现资源的持久化存储。

上面便是一个请求的处理流程,其中 Mutating Admission 和 Validating Admission 便是我们今天的主角。我们来详细的看一看。

什么是准入控制器(Admission Controller)

准入控制器是指在请求通过认证和授权之后,可用于对其进行变更操作或验证操作的一些代码或功能。

准入控制的过程分为两个阶段:

  • 第一阶段,运行变更准入控制器(Mutating Admission)。它可以修改被它接受的对象,这就引出了它的另一个作用,将相关资源作为请求处理的一部分进行变更;
  • 第二阶段,运行验证准入控制器(Validating Admission)。它只能进行验证,不能进行任何资源数据的修改操作;

需要注意的是,某些控制器可以既是变更准入控制器又是验证准入控制器。如果任一个阶段的准入控制器拒绝了该请求,则整个请求将立即被拒绝,并向终端用户返回错误。

为什么需要准入控制器 Admission Controller

我们主要从两个角度来理解为什么我们需要准入控制器:

从安全的角度

我们需要明确在 Kubernetes 集群中部署的镜像来源是否可信,以免遭受攻击;

一般情况下,在 Pod 内尽量不使用 root 用户,或者尽量不开启特权容器等;

从治理的角度

比如通过 label 对业务/服务进行区分,那么可以通过 admission controller 校验服务是否已经有对应的 label 存在之类的;

比如添加资源配额限制 ,以免出现资源超卖之类的情况;

准入控制器

考虑到这些需求比较有用 & 确实也比较需要,所以 Kubernetes 目前已经实现了很多内置的 Admission Controller 。 可以参考官方文档来获取详细列表: kubernetes.io/docs/refere…

这些内置的 Admission Controller 都是以插件的方式与 kube-apiserver 构建到一起的,你可以对其进行启用和关停。比如用如下参数进行控制:

➜  bin ./kube-apiserver --help |grep admission-plugins    
      --admission-control strings              Admission is divided into two phases. In the first phase, only mutating admission plugins run. In the second phase, only validating admission plugins run. The names in the below list may represent a validating plugin, a mutating plugin, or both. The order of plugins in which they are passed to this flag does not matter. Comma-delimited list of: AlwaysAdmit, AlwaysDeny, AlwaysPullImages, CertificateApproval, CertificateSigning, CertificateSubjectRestriction, DefaultIngressClass, DefaultStorageClass, DefaultTolerationSeconds, DenyServiceExternalIPs, EventRateLimit, ExtendedResourceToleration, ImagePolicyWebhook, LimitPodHardAntiAffinityTopology, LimitRanger, MutatingAdmissionWebhook, NamespaceAutoProvision, NamespaceExists, NamespaceLifecycle, NodeRestriction, OwnerReferencesPermissionEnforcement, PersistentVolumeClaimResize, PersistentVolumeLabel, PodNodeSelector, PodSecurity, PodSecurityPolicy, PodTolerationRestriction, Priority, ResourceQuota, RuntimeClass, SecurityContextDeny, ServiceAccount, StorageObjectInUseProtection, TaintNodesByCondition, ValidatingAdmissionWebhook. (DEPRECATED: Use --enable-admission-plugins or --disable-admission-plugins instead. Will be removed in a future version.)
      --disable-admission-plugins strings      admission plugins that should be disabled although they are in the default enabled plugins list (NamespaceLifecycle, LimitRanger, ServiceAccount, TaintNodesByCondition, PodSecurity, Priority, DefaultTolerationSeconds, DefaultStorageClass, StorageObjectInUseProtection, PersistentVolumeClaimResize, RuntimeClass, CertificateApproval, CertificateSigning, CertificateSubjectRestriction, DefaultIngressClass, MutatingAdmissionWebhook, ValidatingAdmissionWebhook, ResourceQuota). Comma-delimited list of admission plugins: AlwaysAdmit, AlwaysDeny, AlwaysPullImages, CertificateApproval, CertificateSigning, CertificateSubjectRestriction, DefaultIngressClass, DefaultStorageClass, DefaultTolerationSeconds, DenyServiceExternalIPs, EventRateLimit, ExtendedResourceToleration, ImagePolicyWebhook, LimitPodHardAntiAffinityTopology, LimitRanger, MutatingAdmissionWebhook, NamespaceAutoProvision, NamespaceExists, NamespaceLifecycle, NodeRestriction, OwnerReferencesPermissionEnforcement, PersistentVolumeClaimResize, PersistentVolumeLabel, PodNodeSelector, PodSecurity, PodSecurityPolicy, PodTolerationRestriction, Priority, ResourceQuota, RuntimeClass, SecurityContextDeny, ServiceAccount, StorageObjectInUseProtection, TaintNodesByCondition, ValidatingAdmissionWebhook. The order of plugins in this flag does not matter.
      --enable-admission-plugins strings       admission plugins that should be enabled in addition to default enabled ones (NamespaceLifecycle, LimitRanger, ServiceAccount, TaintNodesByCondition, PodSecurity, Priority, DefaultTolerationSeconds, DefaultStorageClass, StorageObjectInUseProtection, PersistentVolumeClaimResize, RuntimeClass, CertificateApproval, CertificateSigning, CertificateSubjectRestriction, DefaultIngressClass, MutatingAdmissionWebhook, ValidatingAdmissionWebhook, ResourceQuota). Comma-delimited list of admission plugins: AlwaysAdmit, AlwaysDeny, AlwaysPullImages, CertificateApproval, CertificateSigning, CertificateSubjectRestriction, DefaultIngressClass, DefaultStorageClass, DefaultTolerationSeconds, DenyServiceExternalIPs, EventRateLimit, ExtendedResourceToleration, ImagePolicyWebhook, LimitPodHardAntiAffinityTopology, LimitRanger, MutatingAdmissionWebhook, NamespaceAutoProvision, NamespaceExists, NamespaceLifecycle, NodeRestriction, OwnerReferencesPermissionEnforcement, PersistentVolumeClaimResize, PersistentVolumeLabel, PodNodeSelector, PodSecurity, PodSecurityPolicy, PodTolerationRestriction, Priority, ResourceQuota, RuntimeClass, SecurityContextDeny, ServiceAccount, StorageObjectInUseProtection, TaintNodesByCondition, ValidatingAdmissionWebhook. The order of plugins in this flag does not matter.

这么多的准入控制器中有两个比较特别,分别是 MutatingAdmissionWebhook 和 ValidatingAdmissionWebhook。它们并没有真正执行相应的策略,而是为 kube-apiserver 提供了一种可扩展的方式, 用户可以通过配置 MutatingAdmissionWebhook 和 ValidatingAdmissionWebhook 来使用自构建的服务, 而且这种方式是无需对 kube-spiserver 执行编译或者重启,完全是动态的,非常的方便。

我们来具体看一下。

动态准入控制器

利用上文中提到的 MutatingAdmissionWebhook 和 ValidatingAdmissionWebhook 进行运行时配置的,以 Webhook 形式调用的 Admission Controller 即为动态准入控制器。

它是一种用于接收准入请求并对其进行处理的 HTTP 回调机制,就是一个 Web 服务。当前的两种类型的准入 webhook:

validating admission webhook

mutating admission webhook

mutating admission webhook 会优先被调用,这个过程中可以对资源进行修改。

如果我们需要确保对象的最终状态以执行某些操作应该考虑使用 validating admission webhook *,*因为到达这个阶段的请求不会再被修改。

使用条件

确保 Kubernetes 集群版本至少为 v1.16(以便使用 admissionregistration.k8s.io/v1 API) 或者 v1.9 (以便使用 admissionregistration.k8s.io/v1beta1 API);

确保已经启用 MutatingAdmissionWebhook 和 ValidatingAdmissionWebhook 准入控制器;

确保启用了 admissionregistration.k8s.io/v1beta1 或者 admissionregistration.k8s.io/v1 API;

Admission Webhook 是什么

它其实就是一个普通的 HTTP Server,需要处理的就是 AdmissionReview 类型的资源,我们来看个示例,比如说要对 Ingress资源进行准入校验:

func (ia *IngressAdmission) HandleAdmission(obj runtime.Object) (runtime.Object, error) {
	review, isV1 := obj.(*admissionv1.AdmissionReview)
	if !isV1 {
		return nil, fmt.Errorf("request is not of type AdmissionReview v1")
	}
	if !apiequality.Semantic.DeepEqual(review.Request.Kind, ingressResource) {
		return nil, fmt.Errorf("rejecting admission review because the request does not contain an Ingress resource but %s with name %s in namespace %s",
			review.Request.Kind.String(), review.Request.Name, review.Request.Namespace)
	}
	status := &admissionv1.AdmissionResponse{}
	status.UID = review.Request.UID
	ingress := networking.Ingress{}
	codec := json.NewSerializerWithOptions(json.DefaultMetaFactory, scheme, scheme, json.SerializerOptions{
		Pretty: true,
	})
	codec.Decode(review.Request.Object.Raw, nil, nil)
	_, _, err := codec.Decode(review.Request.Object.Raw, nil, &ingress)
	if err != nil {
		klog.ErrorS(err, "failed to decode ingress")
		status.Allowed = false
		status.Result = &metav1.Status{
			Status: metav1.StatusFailure, Code: http.StatusBadRequest, Reason: metav1.StatusReasonBadRequest,
			Message: err.Error(),
		}
		review.Response = status
		return review, nil
	}
	if err := ia.Checker.CheckIngress(&ingress); err != nil {
		klog.ErrorS(err, "invalid ingress configuration", "ingress", fmt.Sprintf("%v/%v", review.Request.Name, review.Request.Namespace))
		status.Allowed = false
		status.Result = &metav1.Status{
			Status: metav1.StatusFailure, Code: http.StatusBadRequest, Reason: metav1.StatusReasonBadRequest,
			Message: err.Error(),
		}
		review.Response = status
		return review, nil
	}
	klog.InfoS("successfully validated configuration, accepting", "ingress", fmt.Sprintf("%v/%v", review.Request.Name, review.Request.Namespace))
	status.Allowed = true
	review.Response = status
	return review, nil
}

核心处理逻辑其实就是处理请求 Webhook 时候发送的 AdmissionReview ,它会包含着我们待校验的资源对象。然后我们就按照实际的需要对资源对象进行校验或者修改了。

这里需要注意几个点:

Mutating Webhook 的处理是串行的,而 Validating Webhook 是并行处理的;

Mutating Webhook 虽然处理是串行的,但是并不保证顺序;

注意对 Mutating Webhook 的处理做到幂等性,以免结果不符合预期;

请求处理时,注意要处理资源对象的所有 API 版本;

如何部署 Admission Webhook

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
  labels:
    app.kubernetes.io/name: ingress-nginx
  name: ingress-nginx-admission
webhooks:
  - name: validate.nginx.ingress.kubernetes.io
    matchPolicy: Equivalent
    rules:
      - apiGroups:
          - networking.k8s.io
        apiVersions:
          - v1
        operations:
          - CREATE
          - UPDATE
        resources:
          - ingresses
    failurePolicy: Fail
    sideEffects: None
    admissionReviewVersions:
      - v1
    clientConfig:
      service:
        namespace: ingress-nginx
        name: ingress-nginx-controller-admission
        path: /networking/v1/ingresses

webhooks 中配置 webhook 的具体连接信息,以及触发规则。rules中可指定对哪些资源的具体行为生效。

总结

本篇主要介绍了 Kubernetes 中的 Admission Controller ,默认情况下有一些已经以插件形式与 kube-apiserver 编译到了一起,另外我们也可以通过自己编写动态准入控制器来完成相关的需求。

当然,目前在 K8s 生态中已经有很多现成的工具可以帮我们完成对应的这些事情了,很多情况下不需要再自行开发对应的服务了。后续我来为大家分享当前一些比较主流的,可用于进行 Mutating 和 Validating 准入控制的工具, 欢迎关注。

以上就是K8s准入控制Admission Controller深入介绍的详细内容,更多关于K8s准入控制Admission Controller的资料请关注脚本之家其它相关文章!

相关文章

  • 关于k8s 使用 Service 控制器对外暴露服务的问题

    关于k8s 使用 Service 控制器对外暴露服务的问题

    这篇文章主要介绍了k8s使用Service控制器对外暴露服务,包括部署deploy,部署 service及查看 service 和 pod 的关系,本文给大家介绍的非常详细,需要的朋友可以参考下
    2022-03-03
  • kubernetes(k8s)安装metrics-server实现资源使用情况监控方式详解

    kubernetes(k8s)安装metrics-server实现资源使用情况监控方式详解

    这篇文章主要介绍了kubernetes(k8s)安装metrics-server实现资源使用情况监控,包括Metrics Server下载方式, k8s集群安装部署metrics的问题,本文给大家介绍的非常详细,需要的朋友可以参考下
    2022-04-04
  • Kubernetes如何限制不同团队只能访问各自namespace实现

    Kubernetes如何限制不同团队只能访问各自namespace实现

    这篇文章主要为大家介绍了Kubernetes如何限制不同团队只能访问各自namespace实现详解,有需要的朋友可以借鉴参考下,希望能够有所帮助,祝大家多多进步,早日升职加薪
    2023-04-04
  • Kubernetes中使用PersistentVolume挂载云盘方式

    Kubernetes中使用PersistentVolume挂载云盘方式

    这篇文章主要介绍了Kubernetes中使用PersistentVolume挂载云盘方式,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教
    2024-02-02
  • 使用kubeadm部署多节点集群

    使用kubeadm部署多节点集群

    这篇文章介绍了使用kubeadm部署多节点集群的方法,对大家的学习或者工作具有一定的参考学习价值,需要的朋友们下面随着小编来一起学习学习吧
    2022-04-04
  • 详解consul的安装和配置

    详解consul的安装和配置

    这篇文章主要介绍了详解consul的安装和配置,小编觉得挺不错的,现在分享给大家,也给大家做个参考。一起跟随小编过来看看吧
    2018-06-06
  • Rainbond网络治理插件ServiceMesh官方文档说明

    Rainbond网络治理插件ServiceMesh官方文档说明

    这篇文章主要为大家介绍了Rainbond网络治理插件ServiceMesh官方文档说明,有需要的朋友可以借鉴参考下,希望能够有所帮助,祝大家多多进步,早日升职加薪
    2022-04-04
  • IoT边缘集群Kubernetes Events告警通知实现示例

    IoT边缘集群Kubernetes Events告警通知实现示例

    这篇文章主要为大家介绍了IoT边缘集群Kubernetes Events告警通知实现示例详解,有需要的朋友可以借鉴参考下,希望能够有所帮助,祝大家多多进步,早日升职加薪
    2023-02-02
  • CentOS 7.9 升级内核 kernel-ml-5.6.14版本的方法

    CentOS 7.9 升级内核 kernel-ml-5.6.14版本的方法

    这篇文章主要介绍了CentOS 7.9 升级内核 kernel-ml-5.6.14版本,默认内核版本为3.10.0,现升级到 5.6.14 版本,本文给大家介绍的非常详细,对大家的学习或工作具有一定的参考借鉴价值,需要的朋友可以参考下
    2022-10-10
  • k8s跨服务调用入门到实战示例详解

    k8s跨服务调用入门到实战示例详解

    这篇文章主要为大家介绍了k8s跨服务调用入门到实战示例详解,有需要的朋友可以借鉴参考下,希望能够有所帮助,祝大家多多进步,早日升职加薪
    2023-09-09

最新评论