kubernetes高级之动态准入控制

系列目录

动态准入控制器文档介绍了如何使用标准的,插件式的准入控制器.但是,但是由于以下原因,插件式的准入控制器在一些场景下并不灵活:

  • 它们需要编译到kube-apiserver里
  • 它们仅在apiserver启动的时候可以配置

准入钩子(Admission Webhooks 从1.9版本开始)解决了这些问题,它允许准入控制器独立于核心代码编译并且可以在运行时配置.

什么是准入钩子

准入钩子是一种http回调,它接收准入请求然后做一些处理.你可以定义两种类型的准入钩子:验证钩子变换钩子.对于验证钩子,你可以拒绝请求以使自定义准入策略生效.对于变换钩子,你可以改变请求来使自定义的默认配置生效.

体验准入钩子

准入控制钩子是集群管制面板不可缺少的一部分.你在编写部署它们时必须要警惕.如果你想要编写/布置生产级别的准入控制器,请阅读以下用户指南.下面我们将介绍如何快速体验准入钩子.

准备工作:

  • 确保你的kubernetes集群版本至少是1.9版本.
  • 确保变换钩子(MutatingAdmissionWebhook) 和验证钩子(ValidatingAdmissionWebhook)已经启用.这里是推荐开启的一组准入控制器.

编写一个准入钩子服务器(admission webhook server)

请参阅已经被kubernetes e2e测试验证通过的准入服务器钩子( admission webhook server)的实现.这个web钩子处理apiserver发出的admissionReview请求,然后把结果封装成一个admissionResponse返回给请求者.

admissionReview请求可能有多个版本( v1beta1 或者 未来的v1),web钩子可以通过admissionReviewVersions字段来定义它们接受的版本.apiserver会尝试使用列表中出现的,支持的第一个版本.如果列表中的版本没有一个是被支持的,验证将失败.如果webhook配置已经持久化,对web钩子的请求将会失败并被失败策略控制.

示例钩子服务器(admission webhook server)把ClientAuth字段留空,默认为NoClientCert.这意味着钩子服务器不验证客户端身份.如果你需要使用mutual TLS或者其它方法来验证客户端请求,请参考如何认证apiserver

部署准入控制服务

e2e测试的钩子服务器通过部署api(https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.14/#deployment-v1beta1-apps)被部署到kubernetes集群中.测试项目也为钩子服务器创建了一个前端服务,代码

你也可以把你的钩子服务部署到集群外,你需要相应地更新web钩子客户端配置

运行时配置准入web钩子

你可以通过ValidatingWebhookConfigurationMutatingWebhookConfiguration动态地配置哪些资源被哪些web钩子控制.

以下是一个validatingWebhookConfiguration配置的示例,变换钩子的配置也类似

apiVersion: admissionregistration.k8s.io/v1beta1
kind: ValidatingWebhookConfiguration
metadata:
  name: <name of this configuration object>
webhooks:
- name: <webhook name, e.g., pod-policy.example.io>
  rules:
  - apiGroups:
    - ""
    apiVersions:
    - v1
    operations:
    - CREATE
    resources:
    - pods
    scope: "Namespaced"
  clientConfig:
    service:
      namespace: <namespace of the front-end service>
      name: <name of the front-end service>
    caBundle: <pem encoded ca cert that signs the server cert used by the webhook>
  admissionReviewVersions:
  - v1beta1
  timeoutSeconds: 1

scope字段指定了集群级别的资源("Cluster")或者名称空间级别的资源("Namespaced")需要匹配这些规则."*"表示没有任何范围限制.

注意,如果使用clientConfig.service,服务端证书必须对<svc_name>.<svc_namespace>.svc有效.

web钩子请求默认超时时间为30秒,但是从1.14版本开始,你可以自由设置超时时间但是建议设置较小的时间.如果web钩子请求超时,请求将被web钩子的失败策略处理.

当apiserver接收到一个匹配规则的请求,apiserver将会发送一个admissionReview请求到clientConfig配置的web钩子里.

创建web钩子配置以后,系统将会经过一段时间使新配置生效.

认证apiserver

如果你的准入web钩子需要认证,你可以配置apiserver使用基本认证(basic auth), bearer token 或者证书认证.需要三个步骤来完成认证配置.

  • 当启动apiserver时,通过--admission-control-config-file选项来指定准入控制配置文件的位置.
  • 在准入控制配置文件里,指定变换控制器(MutatingAdmissionWebhook)和验证控制器(ValidatingAdmissionWebhook)从哪里读取证书.证书存储在kubeConfig文件里(和kubectl使用的相同),字段名为kubeConfigFile.下面是准入控制配置文件示例
apiVersion: apiserver.k8s.io/v1alpha1
kind: AdmissionConfiguration
plugins:
- name: ValidatingAdmissionWebhook
  configuration:
    apiVersion: apiserver.config.k8s.io/v1alpha1
    kind: WebhookAdmission
    kubeConfigFile: <path-to-kubeconfig-file>
- name: MutatingAdmissionWebhook
  configuration:
    apiVersion: apiserver.config.k8s.io/v1alpha1
    kind: WebhookAdmission
    kubeConfigFile: <path-to-kubeconfig-file>

这里是admissionConfigurationschema定义

  • 在kubeConfig文件里,提供证书
apiVersion: v1
kind: Config
users:
# DNS name of webhook service, i.e., <service name>.<namespace>.svc, or the URL
# of the webhook server.
- name: 'webhook1.ns1.svc'
  user:
    client-certificate-data: <pem encoded certificate>
    client-key-data: <pem encoded key>
# The `name` supports using * to wildmatch prefixing segments.
- name: '*.webhook-company.org'
  user:
    password: <password>
    username: <name>
# '*' is the default match.
- name: '*'
  user:
    token: <token>

当然,你需要设置web钩子服务器来处理这些认证.

原文地址:https://www.cnblogs.com/tylerzhou/p/11080653.html

时间: 2024-08-29 06:43:49

kubernetes高级之动态准入控制的相关文章

Kubernetes之(十五)身份认证,授权,准入控制

目录 Kubernetes之(十五)身份认证,授权,准入控制 ServiceAccount 创建serviceaccount 自定义serviceaccount 自建证书和账号进行访问apiserver RBAC简介 Kubernetes RBAC演示 RBAC的三种授权访问 Kubernetes之(十五)身份认证,授权,准入控制 API Server作为Kubernetes网关,是访问和管理资源对象的唯一入口,其各种集群组件访问资源都需要经过网关才能进行正常访问和管理.每一次的访问请求都需要进

kubernetes认证、授权、准入控制

1 总述 1 概述 kubernetes 中的资源访问类型有两种,一种是由POD提供的服务资源,其可通过service或 ingress提供接口以供外部访问,这种访问不需要经过API server的认证,而另一种对集群内部资源的操作则需要经过一定的认证授权操作才能完成. 2 认证,授权,准入控制概述 1 概述 任何客户端在操作相关资源对象时必须经过三个步骤:认证: 身份鉴别,正确的账号,能够通过认证,其只能证明其是合法的账户.授权: 权限检查,对资源进行相应的操作.其可操作某些资源,其某些资源需

kubernetes集群的认证、授权、准入控制

一.kubernetes集群安全架构 用户使用kubectl.客户机或通过REST请求访问API.可以授权用户和Kubernetes服务帐户进行API访问.当一个请求到达API时,它会经历几个阶段,如下图所示: 1.访问K8S集群的资源需要过三关:认证.鉴权.准入控制: 2.普通用户若要安全访问集群API Server,往往需要证书.Token或者用户名+密码: 3.Pod访问,需要ServiceAccountK8S安全控制框架主要由下面3个阶段进行控制,每一个阶段都支持插件方式,通过API S

认证、授权与准入控制

一.访问控制概述 API server作为访问kubernetes集群的网关,也是唯一入口 所有客户端访问集群都必须进行合法性检验:1)用户身份鉴别2)操作权限验证3)是否符合全局约束4)所有验证均通过才能访问或存入数据到etcd中 客户端认证操作:由 API Server 配置的一到多个认证插件完成.收到请求后, API Server 依次调用为其配置的认证插件来认证客户端身份,直到其中一个插件可以识别出请求者的身 份为止 授权操作由一到多个授权插件进行,它负责确定那些通过认证的用户是否有权限

通过无线AP轻松突破内网准入控制

以定级为等保二级或更高安全等级的网络为例,针对违规内联,会专门部署终端桌面管理系统,并对网络接入实行准入控制,准入控制手段主要有: (1)基于802.1X进行准入控制: (2)基于交换机端口绑定实行准入控制: (3)基于认证网关进行准入控制: (4)其他如DHCP等准入控制. 上述技术手段的组合,会对边界完整性保护发挥重要作用,但仍无法完全杜绝违规内联问题. 原因解析: 第一:无线AP通过NAT结合DMZ,可轻松突破802.1X的准入控制.事实上,基于802.1X的准入控制,推广和普及力度最大的

从零开始入门 K8s | Kubernetes 网络概念及策略控制

作者 |?阿里巴巴高级技术专家? 叶磊 一.Kubernetes 基本网络模型 本文来介绍一下 Kubernetes 对网络模型的一些想法.大家知道 Kubernetes 对于网络具体实现方案,没有什么限制,也没有给出特别好的参考案例.Kubernetes 对一个容器网络是否合格做出了限制,也就是 Kubernetes 的容器网络模型.可以把它归结为约法三章和四大目标. 约法三章的意思是:在评价一个容器网络或者设计容器网络的时候,它的准入条件.它需要满足哪三条? 才能认为它是一个合格的网络方案.

Kubernetes 学习21 kubernetes高级调度方式

一.概述 1.上集讲了Scheduler在实现调度时分三步实现调度过程.首先是预选,即从所有节点中选择基本符合选择条件的节点.而后在基本符合条件的节点中使用优选函数计算他们各自的得分并加以比较.并从最高得分的节点中随机选择出一个运行pod的节点,这就是我们的控制平面中scheduler所实现负责的主要功用.同时如果在某些调度场景中我们期望能够通过自己的预设去影响他的一些调度方式,比如就是把我们的pod运行在某些特定的节点之上的时候可以通过自己的预设操作去影响他的预选和优选过程从而使得调度操作能符

Kubernetes高级进阶之pod的自动扩容/缩容

目录:实践1:基于autoscaling cpu指标的扩容与缩容实践2:基于prometheus自定义指标QPS的扩容与缩容 Pod自动扩容/缩容(HPA) Horizontal Pod Autoscaler(HPA,Pod水平自动伸缩),根据资源利用率或者自定义指标自动调整replication controller, deployment 或 replica set,实现部署的自动扩展和缩减,让部署的规模接近于实际服务的负载.HPA不适于无法缩放的对象,例如DaemonSet. HPA主要是

Unix高级编程之进程控制

进程控制 ps auxps axjps axfps axm 一.进程标识符 pid_t ---->long int 进程的独一无二的标识 0 调用进程(内核) 1 init进程(用户态所有进程的祖先进程) getpid(2); getppid(2); 进程的状态 S 可中断的睡眠态 R 运行态 D 不可中断的睡眠态 T 停止态 X 终止态 Z 僵尸态进程优先级 s 会话组长 l 多线程 < 高优先级 N 低优先级 + 在前台进程组 二.fork(2)父子进程之间的不同: <1>pi