从零开始入门 K8s | K8s 安全之访问控制

 

**导读：**访问控制是云原生安全的一个重要组成部分，也是 K8s 集群在多租环境下必要且基本的安全加固手段。在 K8s 体系中，访问控制又分为三个重要的组成部分，请求认证，鉴权和运行时刻的 admission 准入控制。在本文中，作者将带领大家了解这 3 部分的基本定义和使用方法，并给出多租环境下安全加固的相关最佳实践。

一、Kubernetes API 请求访问控制

访问控制

大家都知道访问控制是云原生安全中的一个重要组成部分。也是一个 Kubernetes 集群在多租户环境下必须要采取的一个基本的安全防护手段。

那么在概念上可以抽象的定义为谁在何种条件下可以对什么资源做什么操作。这里的资源就是在 Kubernetes 中我们熟知的：Pod、 ConfigMaps、Deployment、Secrets 等等这样的资源模型。

Kubernetes API 请求

由上图来介绍一下 Kubernetes API 的请求从发起到其持久化入库的一个流程。

首先看一下请求的发起，请求的发起分为两个部分：

• 第一个部分是人机交互的过程。 是大家非常熟悉的用 kubectl 对 apiserver 的一个请求过程；
• 第二个部分是 Pod 中的业务逻辑与 apiserver 之间的交互。

当我们的 apiserver 收到请求后，就会开启访问控制流程。这里面分为三个步骤：

• Authentication 认证阶段：判断请求用户是否为能够访问集群的合法用户。如果用户是个非法用户，那 apiserver 会返回一个 401 的状态码，并终止该请求；

• 如果用户合法的话，我们的 apiserver 会进入到访问控制的第二阶段 Authorization：鉴权阶段。在该阶段中 apiserver 会判断用户是否有权限进行请求中的操作。如果无权进行操作，apiserver 会返回 403 的状态码，并同样终止该请求；

• 如果用户有权进行该操作的话，访问控制会进入到第三个阶段：AdmissionControl。在该阶段中 apiserver 的 admission controller 会判断请求是否是一个安全合规的请求。如果最终验证通过的话，访问控制流程才会结束。

此时我们的请求将会转换为一个 Kubernetes objects 相应的变更请求，最终持久化到 ETCD 中。

二、Kubernetes 认证

Kubernetes 中的用户模型

对于认证来说，首先我们要确定请求的发起方是谁。并最终通过认证过程将其转换为一个系统可识别的用户模型用于后期的鉴权，那么先来看一下 Kubernetes 中的用户模型。

1. Kubernetes 没有自身的用户管理能力

什么是用户管理能力呢？我们无法像操作 Pod 一样，通过 API 的方式创建删除一个用户实例。同时我们也无法在 ETCD 中找到用户对应的存储对象。

2. Kubernetes 中的用户通常是通过请求凭证设置

在 Kubernetes 的访问控制流程中用户模型是如何产生的呢？答案就在请求方的访问控制凭证中，也就是我们平时使用的 kube-config 中的证书，或者是 Pod 中引入的 ServerAccount。经过 Kubernetes 认证流程之后，apiserver 会将请求中凭证中的用户身份转化为对应的 User 和 Groups 这样的用户模型。在随后的鉴权操作和审计操作流程中，apiserver 都会使用到改用户模型实例。

3、Kubernetes支持的请求认证方式主要包括：

• Basic 认证

该认证方式下，管理员会将 Username 和 Password 组成的白名单放置在 apiserver 读取的静态配置文件上面进行认证，该方式一般用于测试场景，在安全方面是不推荐且不可拓展的一种方式。

• X509 证书认证

该方式是 apiserver 中相对应用较多的使用方式，首先访问者会使用由集群 CA 签发的，或是添加在 apiserver Client CA 中授信 CA 签发的客户端证书去访问 apiserver。apiserver 服务端在接收到请求后，会进行 TLS 的握手流程。除了验证证书的合法性，apiserver 还会校验客户端证书的请求源地址等信息。开启双向认证，X509 认证是一个比较安全的方式，也是 Kubernetes 组件之间默认使用的认证方式，同时也是 kubectl 客户端对应的 kube-config 中经常使用到的访问凭证。

• Bearer Tokens(JSON Web Tokens)
  • Service