Kubernetes api-server 安全访问机制

引用: https://blog.csdn.net/qianghaohao/article/details/100012855

Kubernetes api-server 安全访问机制

kube-apiserver 是 k8s 整个集群的入口,是一个 REST API 服务,提供的 API 实现了 Kubernetes 各类资源对象(如 Pod,RC,Service 等)的增、删、改、查,API Server 也是集群内各个功能模块之间交互和通信的枢纽,是整个集群的总线和数据中心。

image.png

由此可见 API Server 的重要性了,我们用 kubectl、各种语言提供的客户端库或者发送 REST 请求和集群交互,其实底层都是以 HTTP REST 请求的方式同 API Server 交互,那么访问的安全机制是如何保证的呢,总不能随便来一个请求都能接受并响应吧。API Server 为此提供了一套特有的、灵活的安全机制,每个请求到达 API Server 后都会经过:认证(Authentication)–>授权(Authorization)–>准入控制(Admission Control) 三道安全关卡,通过这三道安全关卡的请求才给予响应:

image.png

认证(Authentication)

认证阶段的工作是识别用户身份,支持的认证方式有很多,比如:HTTP Base,HTTP token,TLS,Service Account,OpenID Connect 等,API Server 启动时可以同时指定多种认证方式,会逐个使用这些方法对客户请求认证,只要通过任意一种认证方式,API Server 就会认为 Authentication 成功。高版本的 Kubernetes 默认认证方式是 TLS。在 TLS 认证方案中,每个用户都拥有自己的 X.509 客户端证书,API 服务器通过配置的证书颁发机构(CA)验证客户端证书。
有两种用户:user account和service account,他们的区别:

ServiceAccount 是 k8s 内部资源,而普通用户是存在于 k8s 之外的;
ServiceAccount 是属于某个命名空间的,不是全局的,而普通用户是全局的,不归某个 namespace 特有;
ServiceAccount 一般用于集群内部 Pod 进程使用,和 api-server 交互,而普通用户一般用于 kubectl 或者 REST 请求使用;

对于user account,可以使用如下方式认证
a. X509 客户端证书

客户端证书验证通过为API Server 指定 --client-ca-file=xxx 选项启用,API Server通过此 ca 文件来验证 API 请求携带的客户端证书的有效性,一旦验证成功,API Server 就会将客户端证书 Subject 里的 CN 属性作为此次请求的用户名。关于客户端证书方式的用户后面会有专门的实践介绍。
可以参考:k8s之user account - 简书

b. 静态token文件

通过指定–token-auth-file=SOMEFILE 选项来启用 bearer token 验证方式,引用的文件是一个包含了 token,用户名,用户ID 的csv文件,请求时,带上 Authorization: Bearer xxx 头信息即可通过 bearer token 验证;
可以参考: https://studygolang.com/articles/11637?fr=sideba

c. 静态密码文件

通过指定 --basic-auth-file=SOMEFILE 选项启用密码验证,引用的文件是一个包含 密码,用户名,用户ID 的csv文件,请求时需要将 Authorization 头设置为 Basic BASE64ENCODED(USER:PASSWORD);
可以参考: https://blog.csdn.net/zhangoic/article/details/81174151

对于service account,可以使用如下方式访问

通过指定 --service-account-key-file=SOMEFILE,SOMEFILE一般为公钥/etc/kubernetes/pki/sa.pub,apiserver使用此公钥认证token。token是kube-controller通过私钥/etc/kubernetes/pki/sa.key给签名后颁发给sa。
可以参考: k8s之service account - 简书

授权(Authorization)

授权阶段判断请求是否有相应的权限,授权方式有多种:AlwaysDeny,AlwaysAllow,ABAC,RBAC,Node 等。API Server 启动时如果多种授权模式同时被启用,Kubernetes 将检查所有模块,如果其中一种通过授权,则请求授权通过。 如果所有的模块全部拒绝,则请求被拒绝(HTTP状态码403)。高版本 Kubernetes 默认开启的授权方式是 RBAC 和 Node。

准入控制(Admission Control)

准入控制判断操作是否符合集群要求,准入控制配备有一个“准入控制器”的列表,发送给 API Server 的每个请求都需要通过每个准入控制器的检查,检查不通过,则 API Server 拒绝调用请求,有点像 Web 编程的拦截器的意思。

参考

转载-HTTPS实战之单向验证和双向验证 - 简书
https://blog.csdn.net/zhaojie0708/article/details/104811117/
HTTPS数字证书与验证 - 简书

也可参考:Kubernetes api-server 安全访问机制 - 简书 (jianshu.com) 

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值