1. 概述

Kubernetes 对于访问 API 来说提供了两个步骤的安全措施：认证和授权。认证解决用户是谁的问题，授权解决用户能做什么的问题。通过合理的权限管理，能够保证系统的安全可靠。

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

下图是 API 访问要经过的三个步骤，前面两个是认证和授权，第三个是 Admission Control，它也能在一定程度上提高安全性，不过更多是资源管理方面的作用。

整体结构.png

2. 整体结构

安全控制认证与授权功能主要由AuthN和AuthZ功能完成。AuthN负责用户身份的认证，AuthZ负责根据用户身份对其行为做权限控制。

2.1 AuthN 系统

2.1.1 简介

Kubernetes 的 AuthN 系统主要完成了以下工作:
根据配置验证用户凭证，通常是 Bearer Token 或者 Basic Auth Password。
解析用户信息，包括 Username，Groups，Uid 等。这些信息将用于之后的 Authz 系统授权。

2.1.2 认证模式

一般有以下几种用户身份认证模式:

• X509 Client Certs —— Client Certs 模式
  通过传入 --client-ca-file 到 Apiserver 开启。其中证书的 /CN （common name）表示用户名，/O （organization）表示 Groups。
  Client Cert 模式通常用于某些受信任的组件访问 Apiserver，如 Kubernetes 各个组件访问 Apiserver。

• Static Token File —— 静态 Token 文件模式
  通过传入 --token-auth-file 到 Apiserver 开启。以下是其中一条记录的模版。HTTP 请求在 Header 中传入 Authorization: Bearer Token 来认证。

  
  
  image.png

• Static Password File —— 静态 Password 文件模式
  通过传入 --basic-auth-file 到 Apiserver 开启。以下是其中一条记录的模版。HTTP 请求在 Header 中传入 Authorization:Basicbase64(user:password)来认证。

  
  
  image.png

• Service Account Tokens
  Service Account Token 主要是用来给 Pod 提供访问 Apiserver 的权限。当 Pod 通过 Service Account 访问 Apiserver 时，用户名为 system:serviceaccount: (NAMESPACE):(SERVICEACCOUNT)，并且属于system: serviceaccounts和system: serviceaccounts:(NAMESPACE) 这两个 Group。当一个 Pod 使用 InClusterConfig 创建 Client 访问 Apiserver 时，Client 会自动载入 Service Account 的 Token。

• OIDC Token
  OIDC 是除了 WebHook 外 Kubernetes 提供的唯一一个动态的 AuthN 方案。相比较于上面几种方案的小打小闹，OIDC 提供了标准的 AuthN 流程，真正能够作为 Kubernetes 系统用户认证的企业级解决方案。

2.1.3 OpenID Connect Tokens 认证

OpenID Connect 是一些由OAuth2提供商支持的OAuth2，特别是Azure Active Directory，Salesforce和Google。OAuth2的协议的主要扩展是增加一个额外字段，返回了一个叫ID token的access token。这个token是被服务器签名的JSON Web Token (JWT) ，具有众所周知的字段，比如用户的email。

为了识别用户，验证使用来自OAuth2 token响应的id_token (而不是 access_token)作为bearer token。token如何包含在请求中可以参考下图：

认证流程

使用OpenID认证，API Server需要配置

• --oidc-issuer-url，如https://accounts.google.com
• --oidc-client-id，如kubernetes
• --oidc-username-claim，如sub
• --oidc-groups-claim，如groups
• --oidc-ca-file，如/etc/kubernetes/ssl/kc-ca.pem

2.1.4 Webhook Token 认证

Webhook Token 认证方式可以让用户使用自己的认证方式，用户只需要按照约定的请求格式和应答格式提供 HTTPS 服务，当用户把 Bearer Token 放到请求的头部，kubernetes 会把 token 发送给事先配置的地址进行认证，如果认证结果成功，则认为请求用户合法。 这种方式下有三个参数可以配置：

• –authentication-token-webhook-config-file ：kubeconfig 文件说明如果访问认证服务器
• –authentication-token-webhook-cache-ttl ：认证结果要缓存多久，默认是两分钟
• --runtime-config=authentication.k8s.io/v1beta1=true。

Webhook 的配置文件具体如下：

webhook请求端配置.png

Webhook Service 需要实现 TokenReview 的接口：

webhook服务端配置.png

2.1.5 认证代理

API Server需要配置

--requestheader-username-headers=X-Remote-User
--requestheader-group-headers=X-Remote-Group
--requestheader-extra-headers-prefix=X-Remote-Extra-
# 为了防止头部欺骗，证书是必选项
--requestheader-client-ca-file
# 设置允许的CN列表。可选。
--requestheader-allowed-names

2.1.6 Keystone Password 认证

Keystone 是 openstack 提供的认证和授权组件，这个方法对于已经使用 openstack 来搭建 Iaas 平台的公司比较适用，直接使用 keystone 可以保证 Iaas 和 Caas 平台保持一致的用户体系。

需要API Server在启动时指定--experimental-keystone-url=<AuthURL>，而https时还需要设置--experimental-keystone-ca-file=SOMEFILE。

2.1.7 匿名请求

如果请求没有通过以上任何方式的认证，正常情况下应该是直接返回 401 错误。但是 kubernetes 还提供另外一种选择，给没有通过认证的请求一个特殊的用户名 system:anonymous 和组名 system:unauthenticated 。

这样的话，可以跟下面要讲的授权结合起来，为匿名请求设置一些特殊的权限，比如只能读取当前 namespace 的 pod 信息，方便用户访问。

如果使用AlwaysAllow以外的认证模式，则匿名请求默认开启，但可用--anonymous-auth=false禁止匿名请求。

2.2 AuthZ

2.2.1 简介

Kubernetes 的 AuthZ 系统主要完成了以下几件事情:
解析 HTTP 请求，获取请求的各种属性
根据属性和 AuthN 获取的用户信息，依次匹配 AuthZ 规则，如果成功则通过，如果全部失败则返回禁止访问。
不同于 AuthN 方案，AuthZ 方案在 Kubernetes 中和其 API 风格有相当大的关联。由于严格遵循 RESTful 标准定义 API，Kubernetes 在提取 HTTP 请求属性和定义 AuthZ 规则等方面有了极大的便利。
下面是 Kubernetes 提供的两种 AuthZ 方案 —— ABAC 和 RBAC。

2.2.2 ABAC

ABAC 全称 Attribute Based Access Control（基于属性的访问控制）。通过 --authorization-mode=ABAC 开启，并且通过 --authorization-policy-file 指定策略文件。
以下是 ABAC 的一条记录的例子：

image.png

可以发现 ABAC 定义的字段基本上就是来自于上述的 Attributes 接口能够获取的信息。另外值得一提的是 Kubernetes 中的 ABAC 没有动态方案，修改策略文件后必须重启 Apiserver。

2.2.3 RBAC

RBAC 全称 Role Based Access Control（基于角色的访问控制）， 通过 --authorization-mode=RBAC 开启。

目前和 RBAC 相关的 Resource 有以下 4 种：

Role
RoleBinding
ClusterRole
ClusterRoleBinding

image.png

Role 和 RoleBinding 是 NameSpace 下的资源，而 ClusterRole 和 ClusterRoleBinding 是系统级的资源。1.8 后 RBAC 所属的资源已经从 v1beta1 升级到 v1。

2.2.3.1 Role

Role 的例子如下：

image.png

2.2.3.2 ClusterRole

ClusterRole 的例子如下：

image.png

ClusterRole 可以用来定义全局的 Resource。当使用 ClusterRoleBinding 绑定时，表示能访问所有 NameSpace 下的资源（如上述的 secrets），当使用 RoleBinding 绑定时，表示只能访问 RoleBinding 所属的 NameSpace 下的资源。

2.2.3.3 RoleBinding

RoleBinding 的例子如下：

image.png

RoleBinding 负责绑定 Subjects 和某一个 Role 或者 ClusterRole。

2.2.3.4 ClusterRoleBinding

ClusterRoleBinding 的例子如下：

image.png

ClusterRoleBinding 能够绑定 Subjects 和 ClusterRole。

2.2.3.5 Subjects

Subjects 分为以下 3 种类型，Subjects 来自于 AuthN 的结果。

User
Group
ServiceAccount

2.2.4 Authz 的Webhook配置

AuthZ 系统也可以通过 Webhook 实现。不过比起 AuthN，AuthZ 系统通常没有必要使用 Webhook。
通过传入

--authorization-webhook-config-file 

开启，另外还要添加

--runtime-config=authorization.k8s.io/v1beta1=true。

Webhook 的配置文件如下：

image.png

Webhook Service 需要实现 SubjectAccessReview 的接口

image.png

3. 参考文章

link1
link2