控制对 Kubernetes API 的访问

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

用户使用 kubectl、客户端库或通过发出 REST 请求来访问 Kubernetes API。人类用户和 Kubernetes 服务帐户 都可以被授权访问 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 请求;但是,它通常检查标头和/或客户端证书。

身份验证模块包括客户端证书、密码和普通令牌、引导令牌以及 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 向其他命名空间(例如 projectFish)中的对象发出读取 (get) 请求,则他的授权将被拒绝。

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)