k8s 认证鉴权

[lqshow]

k8s APIServer 负责对外提供 k8s API 服务，它运行在 k8s 的 master 节点上。

作为系统管理指令的统一入口，APIServer 担负着统揽全局的重任，任何对资源进行增删改查的操作都需要交给 APIServer处理后才能提交给 etcd。

APIServer 启动过程中进行了3个初始化操作，创建了3个对象：认证，授权和多维资源管理。

所以访问 k8s 集群资源需要过三关：认证，鉴权，多维资源管理

1. 终端用户安全访问集群 API Server，需要证书，token，用户名和密码
2. Pod 访问需要 ServiceAccount

Authentication

基于客户端证书的认证机制

安全级别高

API Server配置

params	desc
--client-ca-file	CA 根证书
--tls-cert-file	API Server 证书
--tls-private-key-file	API Server 私钥文件

Client 配置

params	desc
--certificate-authority	CA根证书
--client-certificate	客户端证书文件
--client-key	客户端私钥文件

访问示例

kubectl --server=https://192.168.99.100:8443 --certificate-authority=ca.crt --client-key=client.key --client-certificate=client.crt get nodes

基于 token 的认证机制

安全级别中

API Server配置

params	desc
--token-auth-file	静态 Token文件，csv格式

Client 配置

kubectl --token

Authorization: Bearer ${token}

访问示例

kubectl --server=https://192.168.99.100:8443 --token=xxx --insecure-skip-tls-verify=true get nodes

curl -k --header "Authorization: Bearer xxx" https://192.168.99.100:8443/api

Basic 认证机制

安全级别低，不建议在生产环境中使用

API Server配置

params	desc
--basic_auth_file	basic 认证文件

Client 配置

kubectl --username --passwrod

Authorization: Basic BASE64ENCODED(USER:PASSWORD)

访问示例

kubectl --server=https://192.168.99.100:8443 --username=admin --password=1234 --insecure-skip-tls-verify=true get nodes

curl -k --header "Authorization: Basic YWRtaW46MTIzNAo=" https://192.168.99.100:8443/api

Authorization

用户认证后，对指定的资源是否有权限访问，还需要经过授权环节。

授权主要是用于对集群资源的访问控制，通过检查请求包含的相关属性值，与相对应的访问策略相比较，API 请求必须满足某些策略才能被处理。

请求属性

1. user, group, extra
2. namespace
3. resource
4. apiGroup
5. API，请求方法(GET, POST, UPDATE , PATCH, DELETE)以及请求 path

授权策略

API Server 支持多只授权策略，通过启动参数"--authorization_mode"来设置，可以同时启用多种策略

授权策略	功能描述
AlwaysAllow	接受所有请求，如果集群不需要授权流程，采用该策略
AlwaysDeny	屏蔽所有请求，一般用与测试
ABAC	基于属性的访问控制，使用用户配置的授权规则去匹配用户的请求
RBAC	基于角色的访问控制，RBAC 的授权策略可以利用 kubectl 或者 k8s API 直接进行配置。RBAC 可以授权给用户，让用户有权进行授权管理，这样就可以无需接触节点，直接进行授权管理
Node	对 Node授权，配合 NodeRestriction 准入控制来限制 kubectl 仅可访问 node,endpoint,pod,service,secret,configmap,pv和 pvc 等相关资源

RBAC（Role-Based Access Control）

允许通过 k8s API 动态配置策略

RBAC被映射成四种 k8s 顶级对象

角色

1. Role（适用带 namespace 的资源）
2. ClusterRole（适用集群资源或非资源 API）

建立用户与角色的绑定关系

角色绑定包含了一组相关主体（User, Group或者 Service Account）以及对被授予角色的引用

以下两者区别在于是否时 namespace 资源

1. RoleBinding
2. ClusterRoleBinding

Admission Control

APIServer会在用户的请求通过认证鉴权后调用 admission control，对用户请求进行进一步的审核。所以即使用户请求通过了认证鉴权，也有可能因为申请的资源超过了资源配额而被 admission control 驳回。

admission control 是一种多维度可扩展的资源管理机制，每个维度通过一个 admission control 插件实现，插件在 admission-control 中是以逗号作为分割符。

--admission-control=NamespaceLifecycle,LimitRanger,ServiceAcount,DefaultStorageClass,ResourceQuota

参考

• Using RBAC Authorization
• K8S安全原理剖析与实践