控制对 Kubernetes API 的访问

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

用户可以使用 kubectl、客户端库或通过发出 REST 请求来访问 Kubernetes API。人类用户和 Kubernetes 服务帐户 都可以获得 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 令牌(用于服务帐户)。

可以指定多个身份验证模块,在这种情况下,将按顺序尝试每个模块,直到其中一个成功为止。

如果请求无法通过身份验证,则会被拒绝,并显示 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 发出对 projectCaribou 命名空间中的对象进行写入(createupdate)的请求,则他的授权将被拒绝。如果 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 如何使用 密钥 获取 API 凭据。
上次修改时间:2023 年 6 月 1 日下午 9:29 PST:调整 /services-networking/ingress.md 中的换行符 (49135cefb8)