Kubernetes 身份认证和授权操作全攻略：K8s 访问控制入门

随着 Kubernetes 被广泛使用，成为业界公认的容器编排管理的标准框架，许多开发人员以及管理员对部署、弹性伸缩以及管理容器化应用程序等 Kubernetes 的关键概念都十分熟悉。而对于生产部署而言，Kubernetes 的安全性至关重要。因此，了解平台如何管理用户和应用程序的身份认证和授权十分必要。

我们将推出一系列文章，以一种实践性的视角来了解平台内部的 Kubernetes 和 Pod 外部用户的身份认证和授权。我也会解释如何使用角色以及角色绑定来允许或限制资源访问。

API Server——Kubernetes 网关

API 为 Kubernetes 各类资源对象（如节点、标签、Pod、服务、部署、secrets、configmaps 以及 ingress 等）提供访问接口。这些资源对象通过简单的 REST API 执行基本的 CRUD（增删改查）操作。

Kubernetes 的核心构建块之一是 API Server，它作为 Kubernetes 的网关，是访问和管理资源对象的唯一入口。内部组件（如 kubelet、调度程序和控制器）通过 API Server 访问 API 以进行编排和协调。分布式键/值数据库、etcd 只能通过 API Server 访问。

通常我们可以通过命令行工具 kubectl 来与 API Server 进行交互。从 kubectl 发送的任何内容最终都会被 API Server 所接收。因此，多个工具和插件会直接或间接地使用相同的 API。

即使在 Kubernetes 集群中访问或者操作对象之前，该请求也需要由 API Server 进行身份验证。REST 路径使用基于 X.509 证书的 TLS 协议来保护和加密流量。Kubectl 在编码和发送请求之前查找文件〜/ .kube / config 以检索 CA 证书和客户端证书。

apiVersion: v1clusters:- cluster:    certificate-authority: /Users/janakiramm/.minikube/ca.crt    server: https://192.168.99.100:8443  name: minikubecontexts:- context:    cluster: minikube    user: minikube  name: minikubecurrent-context: minikubekind: Configpreferences: {}users:- name: minikube  user:    client-certificate: /Users/janakiramm/.minikube/client.crt    client-key: /Users/janakiramm/.minikube/client.key

文件 ca.crt 表示集群使用的 CA 证书，文件 client.crt 和 client.key 映射到用户 minikube。Kubectl 使用上下文中的这些证书和密钥对请求进行编码。

我们可以通过 curl 命令访问 API Server 吗？答案是肯定的。

即使最常见的操作是通过运行 kubectl proxy 来使用 tunnel 协议，我们依然可以通过计算机上的可用证书来访问路径。除了 CA 证书之外，我们还需要在头部嵌入 base64 编码的令牌（token）。

如何检索令牌（token）以及从 curl 调用 API 的命令如下：

kubectl config view -o jsonpath='{"Cluster name\tServer\n"}{range .clusters[*]}{.name}{"\t"}{.clu

Cluster name Serverminikube https://192.168.99.100:8443

export CLUSTER_NAME="minikube"

APISERVER=$(kubectl config view -o jsonpath="{.clusters[?(@.name==\"$CLUSTER_NAME\")].cluster.server}")

接下来，一个重要的任务就是获取与默认 service account 关联的令牌。无需担心这一实体，我们将在之后的文章中更好地理解它。

TOKEN=$(kubectl get secrets -o jsonpath="{.items[?(@.metadata.annotations['kubernetes\.io/service-a

现在我们拥有调用 curl 的所有数据了：

curl -X GET \  --cacert ~/.minikube/ca.crt \  --header "Authorization: Bearer $TOKEN" \  $APISERVER/version

Kubernetes 访问控制的三个层次

如上文所述，用户和 Pod 在访问或操作对象之前都要由 API Server 进行身份认证。

当一个有效的请求发送到 API Server 时，在它被允许或被拒绝之前将经历 3 个步骤。

1、 身份认证

一旦 TLS 连接建立，请求就进入到身份认证阶段，在这一阶段，请求有效负载由一个或多个认证器模块检查。

认证模块时管理员在集群创建过程中配置的，一个集群可能有多个认证模块配置，每个模块会依次尝试认证， 直到其中一个认证成功。

在主流的认证模块中会包括客户端证书、密码、plain tokens、bootstrap tokens 以及 JWT tokens（用于 service account）。客户端证书的使用是默认的并且是最常见的方案。有关认证模块的详细列表，请参阅：

https://kubernetes.io/docs/reference/access-authn-authz/authentication/

请注意，Kubernetes 是没有用于验证用户身份的典型用户数据库或者配置文件。但是它使用从 X.509 证书以及令牌中提取的字符串，将它们传递到身份认证模块。OpenID，Github 甚至 LDAP 提供的外部认证机制可以通过其中一个认证模块与 Kubernetes 集成。

2、 授权

一旦 API 请求得到认证，下一步就是确认这一操作是否被允许执行。这是访问控制流程中的第二个步骤。

对于授权一个请求，Kubernetes 主要关注三个方面——请求者的用户名、请求动作以及该动作影响的对象。用户名从嵌入 token 的头部中提取，动作是映射到 CRUD 操作的 HTTP 动词之一（如 GET、POST、PUT、DELETE），对象是其中一个有效的 Kubernetes 对象，如 pod 或者 service。

Kubernetes 基于一个存在策略来决定授权。默认情况下，Kubernetes 遵循封闭开放的理念，这意味着需要一个明确的允许策略才可以访问资源。

与身份认证类似，授权也是基于一个或多个模块配置的，如 ABAC 模式、RBAC 模式以及 Webhook 模式。当管理员创建集群时，他们配置与 API sever 集成的授权模块。如果多个模块都在使用，Kubernetes 会检查每个模块并且如果其中任一模块授权了请求，则请求授权通过。如果所有模块全部拒绝请求，则请求被拒绝（HTTP 状态码 403）。如果想了解详细的受支持的模块列表，请参阅：

https://kubernetes.io/docs/reference/access-authn-authz/authorization/#authorization-modules

当您使用默认配置的 kubectl 时，所有的请求都会通过，因此此时您被认为时集群管理员。但当我们添加新的用户，默认状态下他们会限制访问权限。

3、 准入控制

通过准入控制是请求的最后一个步骤。与前两个步骤类似，准入控制也有许多模块。

但与前两个步骤不同的是，最后的阶段可以修改目标对象。准入控制模块作用于对象的创建、删除、更新和连接（proxy）阶段，但不包括对象的读取。举个例子，例如，准入控制模块可用于修改创建持久卷声明（PVC）的请求以使用特定存储类。模块可以实施的另一个策略是每次创建容器时提取镜像。更多关于准入控制模块的详情，请参阅：

https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/

在这一过程中，如果任一准入控制模块拒绝，那么请求立刻被拒绝。一旦请求通过所有的准入控制器，将使用对应 API 对象的验证流程对其进行验证，然后写入对象存储。

在下一部分的文章中，我们将更进一步了解创建用户以及为其配置身份认证。保持关注哟~

原文链接：

https://thenewstack.io/a-primer-on-kubernetes-access-control/