控制 Kubernetes API 的访问

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

用户通过 kubectl、客户端库或发出 REST 请求来访问 Kubernetes API。人类用户和 Kubernetes 服务账号 (Service Accounts) 都可以被授权访问 API。当请求到达 API 时，它会经历如下图所示的几个阶段

Diagram of request handling steps for Kubernetes API request

传输安全

默认情况下，Kubernetes API 服务器监听第一个非 localhost 网络接口上的 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 请求；但它通常检查标头和/或客户端证书。

认证模块包括客户端证书、密码和明文令牌、引导令牌 (Bootstrap Tokens) 以及 JSON Web 令牌（用于服务账号）。

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

如果请求无法通过认证，它将被拒绝，并返回 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 PST：调整 /services-networking/ingress.md 中的换行 (49135cefb8)

控制 Kubernetes API 的访问

传输安全

认证

授权

准入控制

审计

接下来

反馈