控制对 Kubernetes API 的访问

本页面概述了如何控制对 Kubernetes API 的访问。

用户使用 kubectl、客户端库或发出 REST 请求来访问 Kubernetes API。人类用户和 Kubernetes ServiceAccount 都可以获得 API 访问授权。当请求到达 API 时，它会经历几个阶段，如下图所示：

Diagram of request handling steps for Kubernetes API request

传输安全

默认情况下，Kubernetes API 服务器在第一个非本地回环网络接口的 6443 端口上监听，并受 TLS 保护。在典型的生产 Kubernetes 集群中，API 在 443 端口上提供服务。可以使用 --secure-port 改变端口，使用 --bind-address 标志改变监听 IP 地址。

API 服务器提供证书。此证书可以使用私有证书颁发机构 (CA) 签名，也可以基于链接到公认 CA 的公钥基础设施。可以使用 --tls-cert-file 和 --tls-private-key-file 标志设置证书和相应的私钥。

如果你的集群使用私有证书颁发机构，你需要在客户端的 ~/.kube/config 中配置该 CA 证书的副本，以便你可以信任连接并确信连接未被拦截。

你的客户端在此阶段可以提供 TLS 客户端证书。

认证

一旦 TLS 建立，HTTP 请求就会进入认证阶段。这在图表中显示为步骤 1。集群创建脚本或集群管理员配置 API 服务器运行一个或多个认证模块。认证器在认证中有更详细的描述。

认证步骤的输入是完整的 HTTP 请求；但是，它通常会检查请求头和/或客户端证书。

认证模块包括客户端证书、密码、纯文本令牌、引导令牌和 JSON Web Token（用于 ServiceAccount）。

可以指定多个认证模块，在这种情况下，每个模块都会按顺序尝试，直到其中一个成功为止。

如果请求无法认证，则会因 HTTP 状态码 401 而被拒绝。否则，用户将被认证为特定的 username，并且该用户名可用于后续步骤的决策。一些认证器还会提供用户的组成员身份，而其他认证器则不会。

虽然 Kubernetes 使用用户名进行访问控制决策和请求日志记录，但它没有 User 对象，也不会在 API 中存储用户名或关于用户的其他信息。

授权

请求被认证为来自特定用户后，必须进行授权。这在图表中显示为步骤 2。

请求必须包含请求者的用户名、请求的操作以及受该操作影响的对象。如果现有策略声明该用户具有完成请求操作的权限，则该请求被授权。

例如，如果 Bob 有以下策略，那么他只能读取 projectCaribou 命名空间中的 Pod。

{
    "apiVersion": "abac.authorization.kubernetes.io/v1beta1",
    "kind": "Policy",
    "spec": {
        "user": "bob",
        "namespace": "projectCaribou",
        "resource": "pods",
        "readonly": true
    }
}

如果 Bob 发出以下请求，该请求将被授权，因为他被允许读取 projectCaribou 命名空间中的对象。

{
  "apiVersion": "authorization.k8s.io/v1beta1",
  "kind": "SubjectAccessReview",
  "spec": {
    "resourceAttributes": {
      "namespace": "projectCaribou",
      "verb": "get",
      "group": "unicorn.example.org",
      "resource": "pods"
    }
  }
}

如果 Bob 请求写入（create 或 update）projectCaribou 命名空间中的对象，他的授权将被拒绝。如果 Bob 请求读取（get）不同命名空间（例如 projectFish）中的对象，那么他的授权将被拒绝。

Kubernetes 授权要求你使用通用的 REST 属性来与现有组织范围或云提供商范围的访问控制系统交互。使用 REST 格式非常重要，因为这些控制系统可能除了 Kubernetes API 之外还会与其他 API 交互。

Kubernetes 支持多种授权模块，例如 ABAC 模式、RBAC 模式和 Webhook 模式。管理员创建集群时，会配置 API 服务器中应使用的授权模块。如果配置了多个授权模块，Kubernetes 会检查每个模块，如果任何模块授权了请求，则请求可以继续。如果所有模块都拒绝请求，则请求被拒绝（HTTP 状态码 403）。

要了解有关 Kubernetes 授权的更多信息，包括使用受支持的授权模块创建策略的详细信息，请参见授权。

准入控制

准入控制模块是可以修改或拒绝请求的软件模块。除了授权模块可用的属性之外，准入控制模块还可以访问正在创建或修改的对象的原始内容。

准入控制器对创建、修改、删除或连接（代理）对象的请求起作用。准入控制器不对仅读取对象的请求起作用。当配置了多个准入控制器时，它们会按顺序调用。

这在图表中显示为步骤 3。

与认证和授权模块不同，如果任何准入控制器模块拒绝，则请求将立即被拒绝。

除了拒绝对象外，准入控制器还可以为字段设置复杂的默认值。

可用的准入控制模块在准入控制器中有所描述。

请求通过所有准入控制器后，将使用相应 API 对象的验证例程进行验证，然后写入对象存储（显示为步骤 4）。

审计

Kubernetes 审计提供了一系列与安全相关的、按时间顺序排列的记录，记录了集群中的操作序列。集群审计由用户、使用 Kubernetes API 的应用程序以及控制平面本身生成的活动。

更多信息请参见审计。

接下来

阅读更多关于认证、授权和 API 访问控制的文档

你可以了解

Pod 如何使用Secret 获取 API 凭据。

最后修改时间：太平洋时间 2023 年 6 月 1 日晚上 9:29：调整 /services-networking/ingress.md 中的换行 (49135cefb8)

控制对 Kubernetes API 的访问

传输安全

认证

授权

准入控制

审计

接下来

反馈