WEBKT

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

66 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服务的访问方式。
  • ValidatingWebhookConfiguration 或 MutatingWebhookConfiguration: 定义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-webhook的ValidatingWebhookConfiguration，它会拦截对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，它指示请求是否被允许。 如果 allowed 是 false，则 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