kubernetes API 访问控制之:准入控制

API访问控制

可以使用kubectl、客户端库方式对REST API的访问,Kubernetes的普通账户和Service帐户都可以实现授权访问API。API的请求会经过多个阶段的访问控制才会被接受处理,其中包含认证、授权以及准入控制(Admission Control)等。如下图所示:
在这里插入图片描述

需要注意:认证授权过程只存在HTTPS形式的API中。也就是说,如果客户端使用HTTP连接到kube-apiserver,是不会进行认证授权的。所以说,可以这么设置,在集群内部组件间通信使用HTTP,集群外部就使用HTTPS,这样既增加了安全性,也不至于太复杂。


准入控制

准入控制(Admission Control)在授权后对请求做进一步的验证或添加默认参数,在对kubernetes api服务器的请求过程中,先经过认证、授权后,执行准入操作,在对目标对象进行操作。这个准入插件代码在apiserver中,而且必须被编译到二进制文件中才能被执行。

在对集群进行请求时,每个准入控制插件都按顺序运行,只有全部插件都通过的请求才会进入系统,如果序列中的任何插件拒绝请求,则整个请求将被拒绝,并返回错误信息。

在某些情况下,为了适用于应用系统的配置,准入逻辑可能会改变目标对象。此外,准入逻辑也会改变请求操作的一部分相关资源。


运行准入控制插件

旧版本:在kubernetes apiserver中有一个flag:admission_control,他的值为一串用逗号连接起、有序的准入模块列表,设置后,就可在对象操作前执行一定顺序的准入模块调用。

Kubernetes 1.10之后的版本, --admission-control 已经废弃,建议使用 --enable-admission-plugins --disable-admission-plugins 指定需要打开或者关闭的 Admission Controller。 同时用户指定的顺序并不影响实际 Admission Controllers 的执行顺序,对用户来讲非常友好。

在1.18版本中默认启动的插件:

NamespaceLifecycle, LimitRanger, ServiceAccount, TaintNodesByCondition, Priority, 
DefaultTolerationSeconds, DefaultStorageClass, StorageObjectInUseProtection, 
PersistentVolumeClaimResize, RuntimeClass, CertificateApproval, CertificateSigning, 
CertificateSubjectRestriction, DefaultIngressClass, MutatingAdmissionWebhook, 
ValidatingAdmissionWebhook, ResourceQuota

  • AlwaysAdmit
    结束所有的请求。

  • AlwaysPullImages
    该插件修改每个新的Pod,强制pull最新镜像,这在多租户群集中非常有用,以便私有镜像只能由拥有授权凭据的用户使用。

  • AlwaysDeny
    拒绝所有请求,一般用于测试。

  • DenyExecOnPrivileged(已弃用)
    该插件将拦截所有请求。如果pod有一个privileged container,将只执行这个pod中的命令。
    如果自己的集群支持privileged container,自己又希望限制用户在这些privileged container上执行命令,那么强烈推荐使用它。

此功能已合并到DenyEscalatingExec中。

  • DenyEscalatingExec
    禁止privileged container的exec和attach操作。

  • ImagePolicyWebhook
    通过webhook决定image策略,需要同时配置–admission-control=ImagePolicyWebhook,配置文件格式如下。

  • ServiceAccount
    该插件将serviceAccounts 实现了自动化。如果打算使用Kubernetes ServiceAccount对象,那么强烈建议使用此插件。

  • SecurityContextDeny
    该插件会将使用了 SecurityContext的pod中定义的选项全部失效 。

  • ResourceQuota
    该插件将会观察传入的所有请求,并确保它不会违反ResourceQuota对象中枚举的任何限制Namespace。如果在Kubernetes Deployment中使用了ResourceQuota对象,则必须使用此插件来约束Container。

  • LimitRanger
    该插件将会观察传入的所有请求,并确保它不会违反LimitRanger对象中枚举的任何限制Namespace,如果在Kubernetes Deployment中使用了LimitRanger对象,则必须使用此插件。LimitRanger还可使用Apply将default资源请求不指定任何的Pods; 目前LimitRanger对Default Namespace中的所有pod应用要求0.1 CPU

  • InitialResources(试验)
    根据镜像的历史使用记录,为容器设置默认资源请求和limits。

  • NamespaceLifecycle
    该插件确保处于Termination状态的Namespace不再接收新的对象创建请求,并拒绝请求不存在的Namespace。该插件还可以防止删除系统保留的Namespace:default,kube-system,kube-public。

  • DefaultStorageClass
    该插件将观察PersistentVolumeClaim,并自动设置默认的Storage Class。
    当没有配置默认Storage Class时,此插件不会执行任何操作。当有多个Storage Class被标记为默认值时,它也将拒绝任何创建,管理员必须重新访问StorageClass对象,并且只标记一个作为默认值。此插件不用于PersistentVolumeClaim的更新,仅用于创建。

  • DefaultTolerationSeconds
    该插件设置Pod的默认forgiveness toleration为5分钟。

  • PodSecurityPolicy
    该插件用于创建和修改pod,使用Pod Security Policies时需要开启。
    当 Kubernetes <1.6.0版本时,API服务器需要启用扩展名/ v1beta1 / podsecuritypolicy API扩展组(–runtime-config=extensions/v1beta1/podsecuritypolicy=true)。

  • NodeRestriction
    此插件限制kubelet修改Node和Pod对象,这样的kubelets只允许修改绑定到Node的Pod API对象,以后版本可能会增加额外的限制。
    限制kubelet仅可访问node、endpoint、pod、service以及secret、configmap、PV和PVC等相关的资源(仅适用于v1.7+)

猜你喜欢

转载自blog.csdn.net/qq_43762191/article/details/125097474
今日推荐