Kubernetes访问控制入门

本文翻译自“A Primer on Kubernetes Access Control”。

随着Kubernetes的发展，许多开发人员和管理员都熟悉了部署、扩展和管理容器化应用程序的概念。Kubernetes对生产部署的一个至关重要的领域是安全性。了解平台如何管理用户和应用程序的身份验证和授权非常重要。

本系列文章将实际了解平台内部的Kubernetes和pod之外的用户的身份验证和授权。我还将解释如何使用角色和角色绑定来允许或限制对资源的访问。

要按照演练中说明的步骤操作，您需要在计算机上运行最新版本的Minikube和kubectl。

API Server - Kubernetes网关

Kubernetes是关于对象的，它提供对这些对象访问的API。节点，标签，pod，deployment，service，secrets，configmap，ingress和更多资源被视为对象。这些对象通过简单的REST API对外公开，用户通过它们执行基本的CRUD操作。

Kubernetes的核心组件之一是API Server，它充当平台的网关。内部组件（如kubelet，scheduler和controller）也通过API Server访问API以进行编排和协调。分布式键/值数据库etcd只能通过API服务器访问。

管理Kubernetes的"瑞士军刀"Kubectl只是一个与API Server对话的工具。从kubectl发送的任何内容和所有内容最终都会经过API Server。多个其他工具和插件也都直接或间接使用相同的API。

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

apiVersion: v1
clusters:
- cluster:
    certificate-authority: /Users/janakiramm/.minikube/ca.crt
    server: https://192.168.99.100:8443
  name: minikube
contexts:
- context:
    cluster: minikube
    user: minikube
  name: minikube
current-context: minikube
kind: Config
preferences: {}
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使用当前上下文(context)中的这些证书和密钥对请求进行编码。

我们可以通过curl访问API Server吗？绝对可以！

尽管通常的做法是通过运行kubectl代理来使用隧道，但我们可以使用我们机器上可用的证书来访问api端点。除了CA证书之外，我们还需要在头部嵌入base64编码的令牌(token)。

以下命令显示如何检索令牌并从curl调用API。

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

Cluster name	Server
minikube	https://192.168.99.100:8443

export CLUSTER_NAME="minikube"

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

下一个重要的事情是获取与默认服务帐户关联的令牌。不要担心这个实体。我们将在本系列的后续部分中更好地理解它。

TOKEN=$(kubectl get secrets -o jsonpath="{.items[?(@.metadata.annotations['kubernetes\.io/service-account\.name']=='default')].data.token}"|base64 -D)

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

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

Kubernetes访问控制的三个层次

如上所述，API Server在访问和操作对象之前对用户和pod进行了身份验证。

当有效请求到达API Server时，它会在允许或拒绝之前经历三个阶段。

1.认证(Authentication)

在基于TLS发起请求之后，它将通过身份验证阶段，其中请求有效负载由一个或多个身份验证器模块进行检查。

身份验证模块由管理员在集群创建过程中配置。集群可以配置多个身份验证模块，在这种情况下，按顺序尝试每个身份验证模块，直到其中一个成功。

一些主流认证模块包括客户端证书，密码，普通令牌，引导令牌(bootstrap token)和JWT令牌（用于服务帐户）。客户端证书的使用是默认和最常见的方案。有关身份验证模块的详细列表，请参阅Kubernetes 文档。

重要的是要了解Kubernetes没有典型的用户数据库或配置文件来验证用户。相反，它使用从X.509证书和令牌中提取的任意字符串，并将它们传递给身份验证模块。OpenID，Github甚至LDAP提供的外部认证机制可以通过其中一个认证模块与Kubernetes集成。

2. 授权(Authorization)

对API请求进行身份验证后，下一步是确定是否允许该操作。这是在访问控制管道的第二阶段完成的。

为了授权请求，Kubernetes查看三个方面 - 请求者的用户名，请求的操作以及受操作影响的对象。用户名是从header中嵌入的令牌中提取的，该操作是映射到CRUD操作的HTTP动词之一，如GET，POST，PUT，DELETE，该对象是有效的Kubernetes对象之一，如pod或服务。

Kubernetes根据现有策略确定授权。默认情况下，Kubernetes遵循开放-关闭的理念，这意味着需要一个明确的允许策略来访问资源。

与身份验证一样，授权是基于一个或多个模块配置的，例如ABAC模式，RBAC模式和Webhook模式。当管理员创建集群时，他们会配置与API Server集成的授权模块。如果正在使用多个授权模块，Kubernetes将检查每个模块，如果任何模块授权该请求，则该请求可以继续。如果所有模块拒绝该请求，则拒绝该请求（HTTP状态代码403）。Kubernetes 文档包含受支持的授权模块列表。

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

3. 准入控制(Admission Control)

请求的最后阶段是通过准入控制。与身份验证和授权步骤一样，准入控制都是关于可插拔模块的。

与前两个阶段不同，最后阶段甚至可以修改目标对象。准入控制模块对正在创建，删除，更新或连接（代理）的对象起作用，但不对读取起作用。例如，准入控制模块可用于修改创建持久卷声明（PVC）的请求以使用特定存储类。模块可以实施的另一个策略是每次创建容器时提取image。有关准入控制模块的详细说明，请参阅Kubernetes 文档。

在访问控制过程中，如果任何准入控制器模块拒绝，则立即拒绝该请求。一旦请求通过所有许可控制器，就会使用相应API对象的验证例程对其进行验证，然后将其写入对象库

在本系列的下一部分中，我们将详细介绍如何创建用户并为其配置身份验证。敬请关注。

Note：在实战课：《Kubernetes实战：高可用集群搭建,配置,运维与应用》中有关于Kubernetes API访问验证、授权和准入控制的详细讲解，欢迎大家订阅学习。

讲师主页：tonybai_cn
讲师博客: Tony Bai
实战课：《Kubernetes实战：高可用集群搭建,配置,运维与应用》
免费课：《Kubernetes基础：开启云原生之门》