Kubernetes API 访问控制

Kubernetes API 访问控制

Access control 访问控制

Kubernetes 对 API 访问提供了三种安全访问控制措施：Authentication、Authorization 和 Admission Control。认证解决用户是谁的问题，授权解决用户能做什么的问题，Admission Control 则是资源管理方面的作用。通过合理的权限管理，能够保证系统的安全可靠。

Kubernetes 集群的所有操作基本上都是通过 kube-apiserver 这个组件进行的，它提供 HTTP RESTful 形式的 API 供集群内外客户端调用。需要注意的是：认证授权过程只存在 HTTPS 形式的 API 中。也就是说，如果客户端使用 HTTP 连接到 kube-apiserver，那么是不会进行认证授权的。所以说，可以这么设置，在集群内部组件间通信使用 HTTP，集群外部就使用 HTTPS，这样既增加了安全性，也不至于太复杂。

可以使用 kubectl、客户端库方式对REST API的访问，Kubernetes 的 user 和 service accounts 都可以实现授权访问 API。API的请求会经过多个阶段的访问控制才会被接受处理，其中包含认证、授权以及准入控制（Admission Control）等。

Authentication 认证

开启 TLS 时，所有的请求首先需要认证（如图步骤1）。Kubernetes 支持多种认证机制，并支持同时开启多个认证插件（只要有一个认证通过即可）。如果认证成功，则用户的username 会传入授权模块做进一步授权验证；对于认证失败的请求则返回 HTTP 401。

Kubernetes 不直接管理用户 虽然 Kubernetes 认证和授权用到了 user 和 group，但 Kubernetes 并不直接管理用户，不能创建 user 对象，也不存储 user。

目前，Kubernetes 支持以下认证插件：

X509 Client Certs Static Token File Bootstrap Tokens Service Account Tokens OpenID Connect Tokens Webhook Token Authentication Authenticating Proxy

Authorization 授权

在通过第一步的认证之后，我们已经知道请求的用户是谁了，那么下一步就需要判断该用户是否对请求的资源有相应的权限（如图步骤 2）。

跟认证类似，Kubernetes 也支持多种授权机制，并支持同时开启多个授权插件（只要有一个验证通过即可）。如果授权成功，则用户的请求会发送到准入控制模块做进一步的请求验证；对于授权失败的请求则返回 HTTP 403。

Kubernetes 授权仅处理以下的请求属性：

user - 认证期间提供的user字符串 group - 认证用户所属的组名列表 “extra” - 由认证层提供的任意字符串键到字符串值的映射 API - 指示请求是否为API resource Request path - 到其他非request端点的路径，如/api或/healthz。 API request verb - API verbs get，list，create，update，patch，watch，proxy，redirect，delete，和deletecollection用于请求resource。要确定resource API端点的请求verbs 。 HTTP request verb - HTTP verbs get，post，put，和delete用于非资源请求 Resource -被访问（仅用于resource 请求）的resource 的ID或名字- *对于使用resource 的请求get，update，patch，和delete，必须提供resource 名称。 Subresource - 正在访问的subresource （仅用于请求resource ） Namespace - 正在访问对象的命名空间（仅针对命名空间的请求资源） API group - 正在访问的API组（仅用于请求资源）。空字符串指定核心API组。

目前，Kubernetes 支持以下授权插件：

ABAC：基于属性的访问控制（ABAC）模式允许你 使用本地文件配置策略。 RBAC：基于角色的访问控制（RBAC）模式允许你使用 Kubernetes API 创建和存储策略。 Webhook：WebHook 是一种 HTTP 回调模式，允许你使用远程 REST 端点管理鉴权。 Node：节点鉴权是一种特殊用途的鉴权模式，专门对 kubelet 发出的 API 请求执行鉴权。

AlwaysDeny 和 AlwaysAllow Kubernetes 还支持 AlwaysDeny 和 AlwaysAllow 模式，其中 AlwaysDeny 仅用来测试，而 AlwaysAllow 则 允许所有请求（会覆盖其他模式）。

调试小技巧

kubectl 客户端有一个子命令是 auth can-i 可以快速检查执行者是否有对应的 API 权限，该命令使用 SelfSubjectAccessReview API 来确定当前用户是否可以执行给定的操作，并且无论使用何种授权模式都可以工作。

kubectl auth can-i create deployments --namespace dev

输出是 yes 证明有权限，否则就是 no。

管理员可以将此与 user impersonation 结合使用，以确定其他用户可以执行的操作。

伪装成用户 dave 来探测是否有相应的权限。

kubectl auth can-i list secrets --namespace dev --as dave

类似地，检查名字空间 dev 里的 dev-sa 服务账号是否可以列举名字空间 target 里的 Pod。

kubectl auth can-i list pods \ --namespace target \ --as system:serviceaccount:dev:dev-sa

除了伪装 User，还可以伪装 ServiceAccount，当然也可以伪装 Group，如使用 --as-group=system:masters。

除了上面使用命令探测外，也可以通过创建普通的 Kubernetes 资源来查询这些 API，其中返回对象的响应 "status" 字段是查询的结果。

kubectl create -f - -o yaml << EOF apiVersion: authorization.k8s.io/v1 kind: SelfSubjectAccessReview spec: resourceAttributes: group: apps name: deployments verb: create namespace: dev EOF

生成的 SelfSubjectAccessReview 为（在阿里云的 AKS 中操作）：

apiVersion: authorization.k8s.io/v1 kind: SelfSubjectAccessReview metadata: creationTimestamp: null spec: resourceAttributes: group: apps name: deployments namespace: dev verb: create status: allowed: true reason: 'RBAC: allowed by ClusterRoleBinding "212335916464555765-cluster-admin-clusterrolebinding" of ClusterRole "cluster-admin" to User "212335916464555765-1639030041"'

Admission control 准入控制

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

准入控制器对创建、修改、删除或（通过代理）连接对象的请求进行操作。 准入控制器不会对仅读取对象的请求起作用。 有多个准入控制器被配置时，服务器将依次调用它们。

这一操作如上图的步骤 3 所示。

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

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

可用的准入控制模块在准入控制器中进行了描述。

请求通过所有准入控制器后，将使用检验例程检查对应的 API 对象，然后将其写入对象存储（如步骤 4 所示）。

API 服务器端口和 IP

前面的讨论适用于发送到 API 服务器的安全端口的请求（典型情况）。 API 服务器实际上可以在 2 个端口上提供服务：

默认情况下，Kubernetes API 服务器在 2 个端口上提供 HTTP 服务：

localhost端口: 用于测试和引导，以及 master 节点上的其他组件（scheduler, controller-manager）与 API 通信 没有 TLS 默认为端口 8080 默认 IP 为 localhost，使用 --insecure-bind-address 进行更改 请求 绕过 身份认证和鉴权模块 由 admission control 模块处理的请求 受需要访问主机的保护 “Secure port”： 尽可能使用 使用 TLS。 用 --tls-cert-file 设置证书，用 --tls-private-key-file 设置密钥 默认端口 6443，使用 --secure-port 更改 默认 IP 是第一个非本地网络接口，使用 --bind-address 更改 请求须经身份认证和鉴权组件处理 请求须经准入控制模块处理 身份认证和鉴权模块运行

参考文档：https://kubernetes.io/docs/reference/using-api/api-concepts/

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。