WEBKT

Kubernetes准入控制器深度剖析:安全策略与合规性检查的利器

50 0 0 0

Kubernetes准入控制器深度剖析:安全策略与合规性检查的利器

什么是准入控制器?

准入控制器的类型

Admission Webhooks:自定义准入控制的强大工具

Admission Webhook的工作流程

如何配置Admission Webhook

开发Admission Webhook

部署Admission Webhook

最佳实践和注意事项

Pod Security Admission:更简单的安全策略实施

总结

Kubernetes准入控制器深度剖析:安全策略与合规性检查的利器

作为一名平台工程师,我经常被问到如何增强Kubernetes集群的安全性,以及如何确保集群中的资源符合特定的规范。今天,我想深入探讨Kubernetes准入控制器,它就像集群的“守门人”,能够在资源被创建、更新或删除之前,对其进行拦截和验证,从而实现自定义的安全策略和合规性检查。

什么是准入控制器?

准入控制器(Admission Controller)是Kubernetes API服务器的一个插件,它在请求到达持久化存储之前,拦截对Kubernetes API的请求。你可以把它想象成一道安全阀,只有通过了准入控制器的检查,请求才能被允许执行。准入控制器可以执行各种操作,包括:

  • 验证(Validating): 检查请求是否符合预定义的策略。如果请求不符合策略,准入控制器会拒绝该请求。
  • 变更(Mutating): 修改请求,例如添加默认值、标签或注解。

准入控制器允许你实施各种安全策略和合规性检查,例如:

  • 限制容器的资源使用: 确保容器不会过度消耗CPU或内存。
  • 强制执行镜像来源: 只允许从受信任的镜像仓库拉取镜像。
  • 添加网络策略: 限制Pod之间的网络通信。
  • 实施命名规范: 确保资源的命名符合特定的模式。
  • 防止特权容器的运行: 阻止运行具有root权限的容器。

准入控制器的类型

Kubernetes提供了多种内置的准入控制器,以及自定义准入控制器的机制。以下是一些常用的内置准入控制器:

  • AlwaysAdmit: 允许所有请求。在测试或开发环境中很有用。
  • AlwaysDeny: 拒绝所有请求。通常用于临时禁用API服务器。
  • NamespaceLifecycle: 防止在不存在的命名空间中创建资源,并防止删除活动命名空间。
  • LimitRanger: 强制执行LimitRange对象中定义的资源限制。
  • ServiceAccount: 自动为Pod分配ServiceAccount,并验证请求是否经过授权。
  • PersistentVolumeClaimResize: 限制PVC的大小调整。
  • PodSecurityPolicy: 根据PodSecurityPolicy对象中定义的策略,限制Pod的安全配置。(注意: PodSecurityPolicy已弃用,建议使用Pod Security Admission替代。)
  • PodSecurityAdmission: 根据预定义的Pod安全标准(PSS)强制执行安全策略。这是替代PodSecurityPolicy的推荐方法。
  • ResourceQuota: 强制执行ResourceQuota对象中定义的资源配额。

除了内置的准入控制器,你还可以使用以下两种方式创建自定义准入控制器:

  • Admission Webhooks: 允许你调用外部HTTP回调函数来处理准入控制请求。这是最常用的自定义准入控制器的方式。
  • 编写API服务器插件: 你可以直接修改Kubernetes API服务器的代码,添加自定义的准入控制逻辑。这种方式非常灵活,但也很复杂,需要深入了解Kubernetes的内部机制。

Admission Webhooks:自定义准入控制的强大工具

Admission Webhooks是自定义准入控制器的首选方式,因为它具有以下优点:

  • 易于开发和部署: 你可以使用任何编程语言开发Webhook,并将其部署为独立的HTTP服务。
  • 无需修改Kubernetes核心组件: Webhook与Kubernetes API服务器通过HTTP进行通信,无需修改API服务器的代码。
  • 高度灵活: 你可以根据自己的需求,编写各种各样的准入控制逻辑。

Admission Webhooks有两种类型:

  • ValidatingAdmissionWebhook: 用于验证请求。如果Webhook返回错误,请求将被拒绝。
  • MutatingAdmissionWebhook: 用于修改请求。Webhook可以修改请求的内容,例如添加默认值或标签。

Admission Webhook的工作流程

  1. 用户向Kubernetes API服务器发送请求,例如创建一个Pod。
  2. API服务器检查是否存在与该请求匹配的Admission Webhook配置。
  3. 如果存在匹配的Webhook,API服务器将向Webhook发送一个HTTP POST请求,其中包含请求的详细信息。
  4. Webhook接收到请求后,执行自定义的准入控制逻辑。
  5. Webhook返回一个HTTP响应,其中包含允许或拒绝请求的决定,以及可选的修改操作。
  6. 如果Webhook允许请求,API服务器将继续处理该请求。如果Webhook拒绝请求,API服务器将返回一个错误给用户。

如何配置Admission Webhook

要配置Admission Webhook,你需要创建以下两个资源:

  • Service: 定义Webhook服务的访问方式。
  • ValidatingWebhookConfigurationMutatingWebhookConfiguration: 定义Webhook的配置,例如匹配的资源类型、操作类型和Webhook服务的地址。

以下是一个ValidatingWebhookConfiguration的示例:

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
name: my-validating-webhook
webhooks:
- name: check-pod-labels.example.com
rules:
- apiGroups: ["""]
apiVersions: ["v1"]
operations: [ "CREATE", "UPDATE" ]
resources: [ "pods" ]
clientConfig:
service:
name: my-webhook-service
namespace: default
path: /validate
caBundle: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUN5RENDQWNJZ0F3SUJBZ0lRQmZKN01NeU1zbjNtYmJkU3lQdldCREFLQmdncWhrak9QUVFEQWpBdk1ROHdEUVlKCk1pNDhEREFLQmdOVkJBTUNNRWt3RmpBWUJnTlZCQVlUQWtSa01TQXdRd1lEVlFRS0RBeFRZVzF3YkdWelkyVnlkR1Z6ClRFRWNNQjRYRFRJd016QTBNREF3TVRFd01Gb1hEVEkwTURBd01EQXdNVEl3TUZvd01ROHdEUVlLMU1pNDhEREFLQmdOVgpCQVlUQ0Rrd0ZqQVlCZ05WQkFNTUVrTXdJaUFjVEdGVE1Ga3dFd1lEVlFRREV4aFRZVzF3YkdWelkyVnlkR1Z6VGpJdwpEQVlEVlFRREV4aFRZVzF3YkdWelkyVnlkR1Z6VHpJeEd6QVZCZ05WQkFvTUVVbEFkZ1lLYVdkekxtZHlZWFZrUkVJeApNQjRYRFRJd016azNNVEV4TURBd01Gb1hEVEkwTURrek1URXhNRFF3TUZvd01ROHdEUVlLMU1pNDhEREFLQmdOVgpCQVlUQ0Rrd0ZqQVlCZ05WQkFNTUVrTXdJaUFjVEdGVE1Ga3dFd1lEVlFRREV4aFRZVzF3YkdWelkyVnlkR1Z6VGpJdwpEQVlEVlFRREV4aFRZVzF3YkdWelkyVnlkR1Z6VHpJeEd6QVZCZ05WQkFvTUVVbEFkZ1lLYVdkekxtZHlZWFZrUkVJeApNQTRHQTFVZEV3RUIvd1FFQXdJQUtDQVFFd0RnWURWUjBQAjBEQmdRUERRUTlJdndSYkF2V3RuY2hDTGZTQkRQQwpzeTBMeVRBc0JnZ3Foa2pPUFFRREFnZ0VQQURDQVFJZ1JBT3VlTnlOWHh4U050QWJXTmF2d1p0RmFUaWMyOHl4ClEvcGRiN1h6aVB3R0V4Q2dZSUtvWkl6ajBFQXdJRFJ3QXdSQUlnWGJwRzFkZVN5RjY0cEZ0THlxNTRTNktkR28zYgpzR2ZFMHpqbzFpY21kNW90YTh4dkU9Ci0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K
admissionReviewVersions: ["v1", "v1beta1"]
sideEffects: None

这个示例定义了一个名为my-validating-webhookValidatingWebhookConfiguration,它会拦截对Pod的CREATE和UPDATE请求。clientConfig部分定义了Webhook服务的访问方式,包括服务名称、命名空间和路径。caBundle包含了用于验证Webhook服务器证书的CA证书。

开发Admission Webhook

Admission Webhook本质上是一个HTTP服务器,它接收AdmissionReview对象作为请求,并返回AdmissionReview对象作为响应。AdmissionReview对象包含了请求的详细信息,例如资源类型、操作类型和资源内容。你的Webhook需要解析AdmissionReview对象,执行自定义的准入控制逻辑,并生成一个包含允许或拒绝请求的决定的AdmissionReview对象。

以下是一个简单的Python Flask Webhook示例:

from flask import Flask, request, jsonify
import json
app = Flask(__name__)
@app.route('/validate', methods=['POST'])
def validate():
request_info = request.get_json()
# 从请求中获取Pod信息
pod = request_info['request']['object']
# 检查Pod是否包含required-label标签
if 'required-label' not in pod['metadata']['labels']:
return jsonify({
'apiVersion': 'admission.k8s.io/v1',
'kind': 'AdmissionReview',
'response': {
'uid': request_info['request']['uid'],
'allowed': False,
'status': {
'code': 400,
'message': 'Pod must have required-label label',
},
}
})
# 允许请求
return jsonify({
'apiVersion': 'admission.k8s.io/v1',
'kind': 'AdmissionReview',
'response': {
'uid': request_info['request']['uid'],
'allowed': True,
}
})
if __name__ == '__main__':
app.run(host='0.0.0.0', port=443, debug=True, ssl_context=('cert.pem', 'key.pem'))

这个示例Webhook检查Pod是否包含required-label标签。如果Pod缺少该标签,Webhook将拒绝该请求,并返回一个错误消息。否则,Webhook将允许该请求。

一些关键点

  • 证书: Webhook 需要使用 TLS 证书,因为 Kubernetes API 服务器需要安全地与 Webhook 通信。示例中使用 ssl_context=('cert.pem', 'key.pem') 指定证书和密钥文件。
  • AdmissionReview 对象: Webhook 的核心是处理 AdmissionReview 对象。 这个对象包含了所有关于准入请求的信息,例如请求的资源对象,操作类型(CREATE, UPDATE 等),以及发起请求的用户。
  • 响应: Webhook 必须返回一个 AdmissionReview 对象作为响应。 响应中最重要的字段是 allowed,它指示请求是否被允许。 如果 allowedfalse,则 status 字段应该包含拒绝的原因。
  • UID: response 中的 uid 字段必须与请求中的 uid 字段相匹配。 这是 Kubernetes 用来关联请求和响应的方式。

部署Admission Webhook

  1. 创建TLS证书: 使用OpenSSL或其他工具生成TLS证书和密钥。
  2. 创建Docker镜像: 将Webhook代码打包成Docker镜像。
  3. 部署Webhook服务: 将Docker镜像部署到Kubernetes集群中,创建一个Service来暴露Webhook服务。
  4. 配置ValidatingWebhookConfiguration或MutatingWebhookConfiguration: 创建相应的配置,指定Webhook服务的地址和匹配规则。

最佳实践和注意事项

  • 保持Webhook的简单和高效: Webhook的性能会直接影响API服务器的响应时间。尽量保持Webhook的逻辑简单,避免执行耗时的操作。
  • 使用缓存: 如果Webhook需要查询外部数据,可以使用缓存来提高性能。
  • 处理错误: 确保Webhook能够正确处理各种错误情况,例如网络连接失败或API调用失败。
  • 监控Webhook: 监控Webhook的性能和错误率,及时发现和解决问题。
  • 考虑Webhook的顺序: 如果你配置了多个Webhook,它们的执行顺序可能会影响最终的结果。确保Webhook的顺序符合你的预期。
  • 小心副作用: MutatingWebhook可以修改请求的内容,这可能会导致意想不到的副作用。在编写MutatingWebhook时,要仔细考虑修改操作的影响。
  • 使用Webhook测试工具: 使用Webhook测试工具可以帮助你验证Webhook的配置和逻辑是否正确。
  • 避免过度设计: 准入控制器应该只负责执行安全策略和合规性检查,不应该承担过多的业务逻辑。

Pod Security Admission:更简单的安全策略实施

Kubernetes 1.23 引入了 Pod Security Admission (PSA),作为 PodSecurityPolicy (PSP) 的替代品。 PSP 在 Kubernetes 1.25 中已被移除。 PSA 通过命名空间级别的标签来工作,允许你为每个命名空间设置不同的安全级别。

Pod Security Levels:

  • Privileged: 不受限制的策略,提供最广泛的可能的权限。此策略允许已知的特权升级。
  • Baseline: 最小限制策略,阻止已知的权限提升。允许默认的 Pod 配置。
  • Restricted: 严格限制策略,遵循当前的 Pod 强化最佳实践。

如何使用 PSA:

  1. 为命名空间打标签:

    apiVersion: v1
    kind: Namespace
    metadata:
    name: my-namespace
    labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/enforce-version: v1.28

    可以设置以下标签:

    • enforce: 违反策略时阻止 Pod 创建。
    • warn: 违反策略时发出警告,但允许 Pod 创建。
    • audit: 在审计日志中记录违反策略的行为,但允许 Pod 创建。
  2. 创建 Pod: 当你在带有 PSA 标签的命名空间中创建 Pod 时,Kubernetes 会根据所选级别强制执行相应的安全策略。

总结

准入控制器是Kubernetes安全体系中的一个重要组成部分,它可以帮助你实施自定义的安全策略和合规性检查,从而提高集群的安全性。通过深入了解准入控制器的原理和使用方法,你可以更好地保护你的Kubernetes集群,并确保其中的资源符合你的预期。

希望这篇文章能够帮助你更好地理解Kubernetes准入控制器。如果你有任何问题或建议,请随时与我交流。

K8s探索者 KubernetesAdmission Controller安全策略

评论点评

打赏赞助
sponsor

感谢您的支持让我们更好的前行

分享

QRcode

https://www.webkt.com/article/9737