【k8s系列】RBAC

原创

已于 2025-02-20 17:04:23 修改 · 104 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#kubernetes #容器

于 2023-04-10 15:39:06 首次发布

本文介绍了Kubernetes中保障API安全的三个关键机制：认证、授权和准入控制。认证包括HTTPS证书、HTTPToken和HTTP基本认证；授权主要通过RBAC实现细粒度访问控制；准入控制则在授权后对请求内容进行验证或修改。文章还详细阐述了ServiceAccount、Role、ClusterRole、RoleBinding和ClusterRoleBinding的使用和配置步骤。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

前言

kubernetes对API访问提供了三种安全访问控制措施：认证，授权，准入控制。

认证解决用户是谁的问题
授权解决用户能做什么的问题
准入控制是资源管理方面的作用。
集群的所有操作基本上都是通过kube-apiserver组件进行，它提供http Restful 形式的api供集群内外客户端调用。

认证

对外不暴露8080端口，只内部访问，对外使用6443端口。（k8s不直接管理用户，不创建user对象，也不存储）

认证方式有：

HTTPS证书认证，基于ca证书
http token认证，通过token识别用户
http基本认证，用户名+密码

授权

对集群资源的访问控制，通过检查请求包含的相关属性值，与相对应的访问策略相比较，api请求必须满足某些策略才能被处理。
授权请求属性：user、group、namespace、请求方法（get、post、update、delete）
授权插件：RBAC、ABAC

准入控制

在授权后对请求做进一步的验证或添加默认参数，还处理请求内容，仅对创建、更新、删除、连接等有效，对读操作无效

注意

认证授权过程只存在HTTPS形式的api中。如果客户端使用http连接到kube-apiserver就不会进行认证授权的。可以这么设置，在集群内部组件间通信使用http，集群外部就使用HTTPS，既增加安全性，也不至于太复杂。

RBAC

让用户能够访问kubernetes API 资源的授权方式。基于角色的访问控制机制（Role-Based Access），角色与权限相关联，用户通过成为适当角色的成员而得到这些角色的权限。
可以利用kubectl 或者 kubernetes api 进行配置，可以授权给用户，让用户有权进行授权管理，无需接触节点，直接进行授权。

主体

user、group、serviceAccount

部署步骤

新建命名空间
ns里新建pod
创建角色role
创建角色绑定rolebinding
生成证书，识别身份
查看pod、svc

ServiceAccount

Service account 是为了方便 Pod 里面的进程调用 Kubernetes API 或其他外部服务而设计的， service account 则是仅局限它所在的namespace；
每个 namespace 都会自动创建一个 default service account，Token controller 检测 service account 的创建，并为它们创建 secret；
开启 ServiceAccount Admission Controller 后，每个 Pod 在创建后都会自动设置 spec.serviceAccountName 为 default（除非指定了其他 ServiceAccout）；
验证 Pod 引用的 service ac