1. APIServer安全模型

APIServer的安全验证环节

• 0：传输安全（Transport Sercurity）
• 1：身份验证（Authentication）
• 2：授权（Authorization）
• 3：准入控制（Admission Control）

传输安全是APIServer安全模型的基础

• APIServer的非安全端口（–insecure-port）近用于测试或其他master组件与APIServer交互，不会进行身份验证和授权
• APIServer的安全端口（–secure-port=6443）
• 所有内外部发起的到APIServer的请求均通过安全端口与APIServer进行交互

2. APIServer安全验证步骤

2.1 身份验证（Authentication）

身份验证环节关注API请求的Header

• 目标：身份验证，并识别出请求所代表的kubemetes user信息
• 验证策略：支持client certificates， bearer tokens，HTTP basic auth以及authenticating proxy
• 结果：通过身份验证的请求会被附上一些身份信息属性，包括Username、UID、Groups以及一些对授权环节可能有用的信息

Kubernetes 中的"User"：Normal User和ServiceAccount

• Normal User：Kubernetes中并没有任何对象可以用来表示Normal User
• Service Account：由Kubernetes管理的、用于pod访问apiserver的"user"
• 匿名请求：username - system:anonymous , group - system:unauthenticated

身份验证策略：支持多种验证策略，采用"短路验证"方式

• 客户端证书验证：–client-ca-file=SOMEFILE。Usemame={CN}，Groups={Organizations}
• Basic Auth：–basic-auth-file=SOMEFILE

Authorization： Basic BASE64ENCODED(USER:PASSWORD} -> password,user,uid,“groupl,group2,group3”

• Bearer Token：–token-auth-file=SOMEFILE

Authorization：Bearer THETOKEN -> token,user,uid,“groupl,group2,group3”

Service Account:

• 由Kubernetes自动创建，使用签名bearer token对请求进行验证
• 组成：Service Account -> {name, namespace, secret}；secret -> {ca.crt, namespace, token}
• Secret 对象自动挂载到 Pod 内/var/run/secrets/kubernetes.io/serviceaccount 路径下

Username: system:serviceaccount:(NAMESPACE):(SERVICEACCOUNT)
Groups:system:serviceaccounts、system:serviceaccounts:(NAMESPACE)

2.2 授权（Authorization)

根据请求信息和授权策略判断请求是否具有操作目标对象的权限

• 支持多种授权模块：ABAC，RBAC，Node，Webhook等
• 启用授权模块：–authorization-mode=xx,yy
• 开启多种授权模块时，采用短路方式授权

Kubernetes RBAC实现
通过Role和RoleBinding实现了RBAC中三类元素的映射连接

2.3 准入控制（Admission Control）

API请求的结果写入etcd之前的最后一道安全防线

• Kubernetes内置了一些admission controllers，可以通过apiserver 的–admission-control 配置开启
• 意义：和APIServer配合共同实现一些高级功能
• 工作方式：请求依次通过所有admission controller，如果有一个controller返回失败，则请求失败