k8s认证

最新推荐文章于 2025-10-20 11:16:33 发布
原创 最新推荐文章于 2025-10-20 11:16:33 发布 · 1k 阅读 · 0 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。

本文深入探讨Kubernetes中的RBAC角色基于user, group和服务账户的权限设定，解析serviceaccount如何由K8s管理及pod访问apiserver的流程。同时，详细介绍了apiserver的启动参数配置，包括proxy-client证书、requestheader设置等关键信息，为理解Kubernetes的安全与认证机制提供了全面视角。

RBAC可以设置subject:user,group和serviceaccount.

user不是k8s管理的，可以通过具体的服务进行管理。对应k8s中就是secret。

serviceaccount是通过k8s管理的。就是每个pod访问api server的权限。

 

api启动参数分为--client的各种crt,key kubelete各种证书，tls(api srever自己用于客户端认证)各种证书，service account,etcd,bootstrap-token-auth（用于kubelete启动自动获取证书的证书）

 

aggregate api:

The kube-apiserver needs a proxy client certificate for the aggregated API servers to trust in order to effectively proxy authentication. kubeadm already has the cert/key pairs required and #43715 wires them together.

We need similar wiring for kube-up.sh so that our e2e tests can test the authentication and authorization flows.

所以apiserver需要设置如下:

 - --proxy-client-cert-file=/etc/kubernetes/secrets/apiserver-proxy.crt
        - --proxy-client-key-file=/etc/kubernetes/secrets/apiserver-proxy.key
        - --requestheader-client-ca-file=/etc/kubernetes/secrets/aggregator-ca.crt
        - --requestheader-allowed-names=kube-apiserver-proxy
        - --requestheader-extra-headers-prefix=X-Remote-Extra-
        - --requestheader-group-headers=X-Remote-Group
        - --requestheader-username-headers=X-Remote-User
k8s 认证机制源码分析
fengcai_ke的博客
09-27 1180
k8s认证机制源码分析
【k8s】9、安全认证
努力充实，远方可期
06-20 505
第九章 安全认证 本章节主要介绍Kubernetes的安全认证机制。 访问控制概述 ​ Kubernetes作为一个分布式集群的管理工具，保证集群的安全性是其一个重要的任务。所谓的安全性其实就是保证对Kubernetes的各种客户端进行认证和鉴权操作。 客户端 在Kubernetes集群中，客户端通常有两类： User Account：一般是独立于kubernetes之外的其他服务管理的用户账号。 Service Account：kubernetes管理的账号，用于为Pod中的服务进程在访问K
Kubernetes精讲之认证授权
m2282475145的博客
09-12 1050
服务账户管理器管理各命名空间下的服务账户，并且保证每个活跃的命名空间下存在一个名为 “default” 的服务账户。服务账户准入控制器（Service account admission controller）在创建pod时会镜像下载会受阻，因为docker私有仓库下载镜像需要认证。服务账户控制器（Service account controller）建立名字为admin的ServiceAccount。建立私有仓库并且利用pod访问私有仓库。Authorization（授权）将secrets注入到sa中。
k8s证书处理
最新发布
一名在A股的韭菜，永远加仓，永远热泪盈眶。好来斯技术博客，`https://howlaisi.com`，微信公众号：韭菜张师傅。
10-20 911
本文介绍了一个用于更新Kubernetes集群证书的脚本工具，主要针对使用kubeadm初始化的集群。该脚本可将kubeadm生成的有效期1年的证书更新为10年有效期，仅需在master节点执行，worker节点证书会自动轮换。使用前需克隆GitHub仓库并赋予执行权限，支持docker和containerd两种CRI运行时。执行脚本后会备份原证书并更新所有相关证书文件，包括etcd、apiserver等组件证书，最后自动重启相关服务。对于多master集群，需要在每个master节点分别执行。脚本会输出详
linux12k8s --＞14安全认证
明日之星
08-10 359
二、 安全认证 本章节主要介绍Kubernetes的安全认证机制。 1、访问控制概述 ​ Kubernetes作为一个分布式集群的管理工具，保证集群的安全性是其一个重要的任务。所谓的安全性其实就是保证对Kubernetes的各种客户端进行认证和鉴权操作。 客户端 ...
k8s学习笔记-证书详解
weixin_30321449的博客
06-18 1253
在进行二进制搭建K8S集群前，我们需要梳理最磨人的一个点，就是各种各样的证书。 官方文档参考：https://kubernetes.io/docs/setup/certificates/ 一共有多少证书： 先从Etcd算起： 1、Etcd对外提供服务，要有一套etcdserver证书 2、Etcd各节点之间进行通信，要有一套etcdpeer证书 3、Kube-APIserver访问...
k8s证书认证
weixin_33955681的博客
06-21 4862
kubernetes 提供了多种安全认证机制， 其中对于集群通讯间可采用 TLS(https) 双向认证机制，也可采用基于 Token 或用户名密码的单向 tls 认证。k8s一般在内网部署，采用私有 IP 地址进行通讯，权威CA只能签署域名证书，我们这里采用自建CA。创建TLS证书和秘钥步鄹1.下载安装SSL,下载cfssl工具：https://pkg.cfssl.org/...
精选资源
k8s 认证 cka-模拟环境资料
01-05
文章《K8s 认证工程师 CKA 考题分析和题库练习》中需要用到的文件资料！里面包含 addon.tar.gz、etcd-v3.4.13-linux-amd64.tar.gz、metrics.yaml、metrics-server-amd64-0-3-6.tar.gz 4 个文件。
k8s认证和授权
梵修
10-15 2902
在Kubernetes中API Server是访问和管理资源对象的唯一入口。所有客户端均要通过API Server访问或者改变集群状态以及完成数据存储，API Server会对每一次请求进行合法性校验，校验包括：用户身份验证、操作权限验证以及操作是否符合全局规范约束等。所有检查均正常完成才能访问或存储数据到etcd。如下图所示：客户端认证操作由API Server配置的一到多个认证插件完成，收到请求后API Server会串行调用这些插件，直到一个插件可以成功识别用户身份为止。
Kubernetes那点事儿——k8s安全认证
liangpangpangyo的博客
03-04 1543
要允许这些插件组件以超级用户权限运行，需要将集群的 cluster-admin 权限授予 kube-system 名字空间中的 “ServiceAccount” 服务账户。Adminssion Control实际上是一个准入控制器插件列表，发送到API server的请求都需要经过这个列表中的每个准入控制器插件的检查，检查不通过，则拒绝请求。RBAC（Role-Based Access Control，基于角色的访问控制），允许通过Kubernetes API动态配置策略。
Kubernetes（k8s）证书机制
叮当猫的喵i
09-15 3811
参考 数字证书原理 数字签名是什么？ 一文带你彻底厘清 Kubernetes 中的证书工作机制 前置知识 数字证书原理 梳理 k8s组件的认证方式 原理 数字证书的验证是在协议层面通过TLS完成的，应用层不需要特殊处理，有两种方式 单向TLS验证：客户端验证服务端的证书，只需要验证服务端身份 双向TLS验证：客户端和服务端双向验证，双方互相验证 k8s各个组件的接口都包含了集群的内部信息，因此采用双向验证，会涉及到的相关文件 服务器端证书：包含服务器端公钥和服务端身份信息 服务器端私钥 客户
kubernetes视频教程笔记 （30）-安全-鉴权Authorization
软件工程小施同学 的专栏
12-10 621
一、Authentication 1. HTTP Token 认证： 通过一个 Token 来识别合法用户 HTTP Token 的认证是用一个很长的特殊编码方式的并且难以被模仿的字符串 - Token 来表达客户的一种方式。 Token 是一个很长的很复杂的字符串，每一个 Token 对应一个用户名存储在 API Server 能访问的文件中。 当客户端发起 API 调用请求时，需要在 HTTP Header 里放入 Token 2. HTTP Base 认证： 通过 用户名+密码 的.
K8S安全认证
2301_78530830的博客
04-23 1194
指定用于客户端认证的证书文件路径，--client-key=/etc/kubernetes/pki/devman.key。：用于配置 Kubernetes 的上下文信息，上下文定义了集群、用户和命名空间的组合，devman@kubernetes。2.Service Account：K8S管理的账号，用于为Pod中的服务进程在访问K8S提供身份标识。3.ABAC：基于属性的访问控制，表示使用用户配置的授权配置的授权规则对用户请求匹配和控制。3.HTTPS证书认证：基于CA根证书签名的双向数字认证的认证方式。
K8S 安全认证
elihe2011的专栏
12-27 4154
1. 安全机制 1.1 认证 (Authentication) 1.1.1 认证方式 HTTP Token：Authorization: Bearer $TOKEN HTTP Basic： Authorization: Basic $(base64encode USERNAME:PASSWORD), HTTPS: 基于CA根证书签名的客户端身份认证方式（推荐） 证书颁发： 手动签发：通过k8s集群的根 ca 进行签发 HTTPS 证书 自动签发：kubelet 首次访问 API Serv
k8s安全认证
杨海吉
01-31 598
Kubernetes作为一个分布式集群的管理工具，保证集群的安全性是其一个重要的任务。所谓的安全性其实就是保证对Kubernetes的各种客户端进行认证和鉴权操作。客户端：一般是独立于kubernetes之外的其他服务管理的用户账号。：kubernetes管理的账号，用于为Pod中的服务进程在访问Kubernetes时提供身份标识。认证、授权与准入控制ApiServer是访问及管理资源对象的唯一入口。Authentication（认证）：身份鉴别，只有正确的账号才能够通过认证。
K8S认证以及serviceaccount
weixin_45483207的博客
03-22 698
APIServer对用户访问的认证，用户提供账号密码 授权检查，准入控制（级联操作）， 2.1. Token 预共享密钥（对称密钥） 2.2.ssl认证 2.2.1.客户端要求服务端发送签署的证书，客户端需要进行证书验证。 2.2.2.服务器需要对客户端进行证书认证，这个证书同样得是服务端认可的CA证书，然后进行ssl会话。 认证插件只要通过一个即可 在本地启动8080端口的代理 列出集群的名称空间 映射关系 K8S认证一共分为两类 1.用户账号 2.pod内应用程序访问APIServer所用到的.
k8s - 安全认证（RBAC）
栋院
03-18 3152
api server 是集群访问控制的统一入口 k8s认证过程： 认证 -> 授权 - > 准入控制 （adminationcontroller） 1 认证（）是对客户端的认证，简单说就是账户密码 2 授权（）是资源的授权，容器、网络、存储资源的权限 3 准入机制 准入控制器位于api server ,在对象被持久化之前，准入控制器拦截对api server 的请求，一般用来做认证和授权。其中包括连个控制器： MutatingAdmissionWebhook 和 Validating
k8s认证方式
09-12
<think> 我们正在讨论Kubernetes（k8s）的认证方式。根据引用内容，k8s提供了多种认证机制来验证客户端的身份。下面我将总结主要的认证方式，并参考引用内容进行说明。 ### 一、Kubernetes认证方式概述 Kubernetes API Server是集群的网关，所有客户端（包括用户、Pod、服务账户等）的请求都必须通过认证。API Server支持多种认证方式，且可以同时启用多个认证模块。当请求到达时，API Server会依次尝试这些认证方式，直到有一个认证成功或全部失败（返回401 Unauthorized）[^3]。 以下是主要的认证方式： #### 1. **HTTPS证书认证（X509客户端证书认证）** 这是安全性最高的认证方式，基于双向数字证书认证[^2]。 - **工作原理**： - 客户端使用CA签发的客户端证书发起HTTPS请求 - API Server验证证书的合法性（签名、有效期等） - 验证通过后，从证书中提取用户信息（如`CN=用户名,O=组名`） - **适用场景**：管理员操作、长期运行的客户端[^1][^3] - **特点**： - 证书需要预先申请和分发 - 支持细粒度的RBAC授权控制 #### 2. **Bearer Token认证** 通过Token字符串验证用户身份[^2]。 - **工作原理**： - 客户端在HTTP Header中携带Token（`Authorization: Bearer <token>`） - API Server验证Token的有效性（与存储的Token比对） - **Token类型**： - **静态Token文件**：通过`--token-auth-file`指定（已弃用） - **ServiceAccount Token**：自动注入到Pod的`/var/run/secrets/kubernetes.io/serviceaccount/token` - **OpenID Connect（OIDC）**：集成第三方身份提供商（如Keycloak） - **示例**：ServiceAccount的创建与查看[^4] ```bash kubectl create sa haha # 创建名为haha的ServiceAccount kubectl describe sa haha ``` #### 3. **HTTP Base认证（已弃用）** 通过用户名和密码认证[^2]。 - **工作原理**： - 用户名密码用Base64编码后放入Header（`Authorization: Basic <base64>`） - API Server解码后验证凭据 - **现状**：Kubernetes 1.19+ 已移除支持[^3] #### 4. **匿名认证** 默认允许未认证请求以`system:anonymous`身份访问[^3]。 - **控制方式**：通过`--anonymous-auth=true|false`启用/禁用 - **权限**：通常配合RBAC限制匿名用户的权限 #### 5. **Webhook认证** 集成外部认证服务（如Open Policy Agent）[^3]。 - **工作原理**： - API Server将认证请求转发到外部Webhook服务 - 根据Webhook响应决定认证结果 - **适用场景**：需要自定义认证逻辑的企业环境 ### 二、认证流程示意图 ```mermaid sequenceDiagram Client->>+API Server: 发送请求（携带证书/Token等） loop 认证模块列表 API Server->>API Server: 尝试认证方式1 API Server->>API Server: 尝试认证方式2... end alt 认证成功 API Server-->>Client: 200 OK（携带用户信息） else 全部失败 API Server-->>Client: 401 Unauthorized end ``` ### 三、最佳实践建议 1. **生产环境优先使用X509证书或ServiceAccount Token** - 避免使用静态Token文件（安全风险高） 2. **集群内Pod访问推荐ServiceAccount** - 自动挂载Token到Pod，无需手动管理 3. **人类用户操作使用kubectl配置证书** ```yaml # ~/.kube/config示例 users: - name: dev-user user: client-certificate: dev.crt client-key: dev.key ``` 4. **禁用匿名认证**（除非有特殊需求） ```bash kube-apiserver --anonymous-auth=false ``` ### 四、相关问题 1. **如何在Kubernetes集群中为ServiceAccount绑定自定义权限？RBAC模型中Role与ClusterRole的区别是什么？** 2. **X509客户端证书认证过程中，如何确保证书不被中间人攻击？证书轮换机制如何实现？** 3. **当使用Webhook认证时，如何设计认证服务以支持高并发场景？认证超时或服务不可用时的降级策略是什么？** 4. **Kubernetes 1.19+ 版本弃用HTTP Base认证后，替代的密码认证方案有哪些？如何安全地管理这些凭据？** --- ### 参考资料梳理 - 引用[2][3]：详细说明了三种主要认证方式（证书/Token/Base）及匿名认证 - 引用[4]：展示了ServiceAccount（Token认证载体）的操作示例 - 引用[1]：补充了X509证书的实际应用场景 </think> ### Kubernetes 认证机制详解 Kubernetes 提供了多种认证机制来验证客户端身份，确保集群安全。以下是根据引用内容整理的认证方式分类及原理说明： --- #### 一、核心认证方式 1. **X509 客户端证书认证** - **安全性最高**：基于 CA 根证书签名的双向数字证书验证[^2][^3] - **工作原理**： ```mermaid sequenceDiagram 客户端->> API Server: 发送携带客户端证书的HTTPS请求 API Server->> CA机构： 验证证书签名有效性 CA机构-->> API Server: 返回验证结果 alt 证书有效 API Server->> RBAC: 提取证书中的用户信息 else 证书无效 API Server-->> 客户端: 返回401 Unauthorized end ``` - **适用场景**：管理员操作、永久性客户端接入[^1] 2. **Bearer Token 认证** - **核心原理**：通过加密字符串验证身份[^2][^3] - **流程特点**： - Token 存储在 Secret 中，与服务账户（ServiceAccount）绑定[^4] - 请求头格式：`Authorization: Bearer <token>` - **操作示例**： ```bash # 创建服务账户（自动生成Token） kubectl create sa haha # 查看Token关联的Secret kubectl describe sa haha ``` - **适用场景**：Pod内部服务调用、CI/CD流水线[^4] 3. **HTTP Base 认证（已弃用）** - **原工作方式**： - 用户名密码经 Base64 编码：`echo -n "user:pass" | base64` - 请求头格式：`Authorization: Basic dXNlcjpwYXNz` - **现状**：Kubernetes 1.19+ 版本已移除支持[^3] --- #### 二、辅助认证机制 1. **Webhook 认证** - 将认证请求转发到外部 REST 服务[^3] - 适用场景：与企业单点登录（SSO）系统集成 2. **匿名认证** - 默认允许未携带凭证的请求以 `system:anonymous` 身份访问[^3] - 需配合 RBAC 限制权限 --- #### 三、认证流程全景 ```mermaid graph LR A[客户端请求] --> B{认证模块} B --> C[X509证书认证] B --> D[Bearer Token认证] B --> E[Webhook认证] B --> F[匿名认证] C --> G[成功?] D --> G E --> G F --> G G -- 是 --> H[进入鉴权模块] G -- 否 --> I[返回401错误] ``` > 💡 **关键特性**：认证模块按顺序执行，任意模块认证成功即通过[^3] --- #### 四、最佳实践建议 1. **生产环境优先使用 X509 证书** - 启用双向 TLS 验证（mTLS） - 定期轮换证书（建议90天） 2. **服务间通信使用 ServiceAccount** ```yaml # Pod自动挂载Token示例 spec: serviceAccountName: haha containers: - name: app image: nginx ``` 3. **禁用高风险配置** - 关闭匿名访问：`kube-apiserver --anonymous-auth=false` - 弃用静态密码认证 --- ### 相关问题 1. **在 X509 证书认证中，如何通过证书的 Subject 字段（如 CN/O）实现细粒度的 RBAC 权限控制？** 2. **当使用 Webhook 认证时，如何设计外部认证服务以保证高可用性和低延迟？认证失败时应返回什么格式的 HTTP 响应？** 3. **ServiceAccount Token 的自动轮换机制是如何工作的？在哪些场景下需要手动管理 Token 的生命周期？** 4. **如何通过 Kubernetes Audit Logs 监控和分析认证失败事件？哪些关键指标可用于构建认证安全仪表盘？**
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值