Kubernetes 认证授权服务

Kubernetes 认证授权服务

APIserver 是k8s集群的网关，是能够与etcd通信的唯一入口

​ kube-controller-manage，kube-scheduler，kubelet,kube-proxy，以及后续部署的集群插件coredns,project,calico等，彼此不通信，彼此间的所有均经由APIserver的rest api 进行，他们说API server的客户端 #（restapi 具有通信功能）

​ 确保对API server的安全访问至关重要

​ 客户端对apiserver的访问应经过身份验证及权限检查；为防止中间人攻击，各类客户端与API server间的通信都应使用TLS进行加密

​ 各kubelet也会监听一些套接字，提供一个小型的rest api

​ 10250 是具有所在节点pod管理权限的读写端口，应谨慎管理， 10255仅提供只读操作，是rest api 的子集

​ 另外，10248是本地healthz端点使用的端口

API server 内置的访问控制机制

api server 内置了一个有着三级别的访问控制机制

认证：核验请求者身份的合法性

授权：核验请求的操作是否获得许 可

准入控制：检查操作内容是否合规

插件化机制，每种访问控制机制均有一组专用的插件栈

​ 认证：身份核验过程遵循或逻辑，且任何监控核验成功后的都将不再进行后续的插件验证

​ 均不成功，则失败，或以匿名者身份访问

​ 建议禁用匿名者

授权：鉴权过程遵循或的逻辑，且任何一个插件对操作的许可授权后都将不在进行后续的插件验证

​ 均为许可，则拒绝请求的操作

准入控制：内容合规性检查过程遵循与逻辑，且无论成败，每次操作请求都要经由所有插件的校验（对写操作有效，读操作无效）

​ 将数据写入etcd前，负责检查内容的有效性，因此仅对写操作有效

​ 分俩类：validating(校验)和mutating(补全或订正)告诉用户在那一步失败

RBCK 基于角色的访问控制

ABAC基于属性的访问控制

身份标识符：检查用户身份是否是自己生成的

kubernetes系统的用户大体可分为2类

​ serviceaccount：服务账户，指定pod内的进程访问API service时使用的身份信息

​ api server 使用service account类型的资源对象来保存该类账号

​ 认证到APIserver的认证信息称为service account token，它们保存于同名的专用类型secret对象中

​ 名称空间级别

useraccount ：用户账户，指非pod类的客户端访问挨批server时使用的身份标识，一般是现实中的人

API server 没有为这类账户提供保存其信息的资源类型，相关的信息通常保存于外部的文件或认证系统中

身份核验操作可由api server 进行，也可能是由外部身份认证服务完成

本身非由kubenetes管理，因而作用域为整个集群级别

不能被识别为service account，也不能识别为user account的用户，即‘’匿名用户‘’

访问：分别分开管理俩种用户

kubectl 交互式客户端

命令行；配置文件

pod 服务进程

sso单点登录

周期型扫描 /etc/kubernetes/

生成静态令牌

echo "$(openssl rand -hex 3).(openssl rand -hex 8)"

生成static token文件

配置kube-apiserver加载该静态令牌文件以启用相应的认证功能

测试命令

curl -k -H "Authorization:Bearer TOKEN" -k https://API_server:643/api/v1/namespaces/default/pods

curl -k -H "Authorization:Bearer TOKEN" -k https://API_server:643/api/v1/namespaces/default/pods