深入理解Kube-APIServer

深入理解Kube-APIServer

文章目录

API Server

访问控制概览访问控制细节认证

认证插件基于webhook的认证服务集成 鉴权

RBAC vs ABACbinding账户／组的管理针对群租授权

API Server

kube-apiserver是Kubernetes最重要的核心组件之一，主要提供以下的功能
• 提供集群管理的REST API接口，包括认证授权、数据校验以及集群状态变更等
• 提供其他模块之间的数据交互和通信的枢纽（其他模块通过API Server查询或修改数据，只有API Server才直接 *** 作etcd）

访问控制概览

Kubernetes API的每个请求都会经过多阶段的访问控制之后才会被接受，这包括认证、授权以及准入控制（Admission Control）等。

apiserver本身是一个rust server，首先要有一个http handler来处理不同版本的请求，接收到请求之后要做认证、鉴权，然后到转变，对应两个webhook（可以自定义开发，在到达mutating步骤时，apiserver会校验有没有对应的webhook，有的话则会被调用，改变对象的值webhook会进行回转），接下来到schema步骤，apiserver会继续校验这个对象是不是有效的（主要是k8s内嵌的逻辑），

访问控制细节

红色箭头为整个apiserver细节调用链：
首先会做request-timeout的检查，然后做认证相关的校验，接下来到audit，主要记录k8s的日志审计（谁在哪个时间点修改了对象？）
inpersonation（不太常用），在请求的handler里边模拟用户请求（a用户代替b用户）
max-in-flight（用作限流），可以设置多少个请求发到apiserver，但是还没有返回，可以理解为在整个调用过程中设置上限值
authorization 做鉴权
kube-aggregator（抽象为多个apiserver汇总），本身是一个api gateway，大概可以理解为它可以分配多个apiserver来进行任务处理，把其中的一部分请求转到其他apiserver做处理
resource handler，首先会解码——》做准入——》校验——》存储etcd中

认证

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

认证插件

X509证书
• 使用X509客户端证书只需要API Server启动时配置–client-ca-file=SOMEFILE。在证书认证时，其CN域用作用户名，而组织机构域则用作group名。

静态Token文件
• 使用静态Token文件认证只需要API Server启动时配置–token-auth-file=SOMEFILE。
• 该文件为csv格式，每行至少包括三列token,username,user id，
token,user,uid,"group1,group2,group3”
参考资料：https://github.com/cncamp/101/blob/master/module6/basic-auth/static-token.csv

## Static token
### Put static-token to target folder

mkdir -p /etc/kubernetes/auth
cp static-token /etc/kubernetes/auth

### Backup your orginal apiserver

cp /etc/kubernetes/manifests/kube-apiserver.yaml ~/kube-apiserver.yaml

### Override your kube-apiserver with the one with static-token config

cp ./kube-apiserver.yaml /etc/kubernetes/manifests/kube-apiserver.yaml

### Get kubernetes object with static token

curl https://192.168.34.2:6443/api/v1/namespaces/default -H "Authorization: Bearer cncamp-token" -k

引导Token
• 为了支持平滑地启动引导新的集群，Kubernetes 包含了一种动态管理的持有者令牌类型， 称作 启动引导令牌（Bootstrap Token）。
• 这些令牌以 Secret 的形式保存在 kube-system 名字空间中，可以被动态管理和创建。
• 控制器管理器包含的 TokenCleaner 控制器能够在启动引导令牌过期时将其删除。
• 在使用kubeadm部署Kubernetes时，可通过kubeadm token list命令查询。

静态密码文件
• 需要API Server启动时配置–basic-auth-file=SOMEFILE，文件格式为csv，每行至少三列password, user, uid，后面是可选的group名
password,user,uid,"group1,group2,group3”

ServiceAccount
• ServiceAccount是Kubernetes自动生成的，并会自动挂载到容器的/run/secrets/kubernetes.io/serviceaccount目录中。
创建ns默认都会创建一个，自动会mount到容器里边。

~]# kubectl get sa -oyaml
apiVersion: v1
items:
- apiVersion: v1
  kind: ServiceAccount
  metadata:
    creationTimestamp: "2022-01-06T12:12:13Z"
    name: default
    namespace: default
    resourceVersion: "383"
    selflink: /api/v1/namespaces/default/serviceaccounts/default
    uid: ba297c44-2a92-4c17-9db2-9e804e76d4b1
  secrets:
  - name: default-token-zj56s	#同时k8s会创建一个secret
kind: List
metadata:
  resourceVersion: ""
  selflink: ""

~]# kubectl get secret default-token-zj56s -oyaml
。。。
这个文件中会带有ns、ca文件、token，是apiserver给颁发的

echo "token的值" |base64 -d 
是一个标准的gwt token，apiserver颁发的——》解码
用这个token文件去访问apiserver，就会知道是哪个用户访问的?

1、当开发k8s组件时，例如写operator，理论上要监听集群apiserver来获取数据，有没有权限读/写 完全要基于身份
2、团队希望每个人有自己的sa，来单独做调试

OpenID
• OAuth 2.0的认证机制

Webhook 令牌身份认证
• --authentication-token-webhook-config-file 指向一个配置文件，其中描述 如何访问远程的 Webhook 服务。
• --authentication-token-webhook-cache-ttl 用来设定身份认证决定的缓存时间。 默认时长为 2 分钟。

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

基于webhook的认证服务集成

参考资料：https://github.com/cncamp/101/tree/master/module6/authn-webhook

构建符合Kubernetes规范的认证服务
需要依照Kubernetes规范，构建认证服务，用来认证tokenreview request
认证服务需要满足如下Kubernetes的规范

URL： https://authn.example.com/authenticate
Method： POST
Input:
Output:

鉴权

授权主要是用于对集群资源的访问控制，通过检查请求包含的相关属性值，与相对应的访问策略相比较，API请求必须满足某些策略才能被处理。跟认证类似，Kubernetes也支持多种授权机制，并支持同时开启多个授权插件（只要有一个验证通过即可）。如果授权成功，则用户的请求会发送到准入控制模块做进一步的请求验证；对于授权失败的请求则返回HTTP 403。

Kubernetes授权仅处理以下的请求属性：
• user, group, extra
• API、请求方法（如get、post、update、patch和delete）和请求路径（如/api） • 请求资源和子资源
• Namespace
• API Group
目前，Kubernetes支持以下授权插件：
• ABAC
• RBAC
• Webhook
• Node

RBAC vs ABAC

ABAC（Attribute based Access Control）本来是不错的概念，但是在 Kubernetes 中的实现比较难于管理和理解，而且需要对 Master 所在节点的 SSH 和文件系统权限，要使得对授权的变更成功生效，还需要重新启动 API Server。
而 RBAC 的授权策略可以利用 kubectl 或者 Kubernetes API 直接进行配置。RBAC 可以授权给用户，让用户有权进行授权管理，这样就可以无需接触节点，直接进行授权管理。RBAC 在 Kubernetes 中被映射为 API 资源和 *** 作。

k8s设计了一系列对象，例如：Role（代表角色），里边定义了一些resources资源和verb（动作），称为一组对象的 *** 作权限聚合成一个角色，subject（抽象为主体）分为user（外部用户）和serviceaccount（内部用户）两种，subject和role通过rolebinding产生关联，最终rbac的定位是谁对哪些对象做什么样的 *** 作；
clusterrole和role的区别：
有时候角色（clusterrole）是一个全局的，role跟namespace是关联的，可以在某一个ns下创建role，clusterrole在整个集群下可以授权给其他用户权限，带clusterrole均为全局性的。

专业术语：
Role（角色）是一系列权限的集合，例如一个角色可以包含读取 Pod 的权限和列出 Pod 的权限。
Role只能用来给某个特定namespace中的资源作鉴权，对多namespace和集群级的资源或者是非资源类的API（如/healthz）使用ClusterRole。

binding

账户／组的管理

角色绑定（Role Binding）是将角色中定义的权限赋予一个或者一组用户。
它包含若干 主体（用户、组或服务账户）的列表和对这些主体所获得的角色的引用。

组的概念：

当与外部认证系统对接时，用户信息（UserInfo）可包含Group信息，授权可针对用户群组当对ServiceAccount授权时，Group代表某个Namespace下的所有ServiceAccount
针对群租授权