当前位置： 首页 > news >正文

K8s访问控制(一)

news 2025/9/6 8:24:05

K8s访问控制

描述 K8s API 访问控制

API Server 认证流程

当一个请求到达 API Server 时，会依次经过以下几个步骤：

  1. 认证（Authentication）

    • 确认你是谁。

    • 常见方式：

      • 证书认证（TLS 双向认证，kubelet、kubectl 默认用证书）

      • Token 认证（ServiceAccount、OIDC 等）

      • 静态用户名密码文件（一般只用于测试）

    🔑 输出结果：用户身份（如 User: alice、ServiceAccount: default:nginx-sa）。

  2. 鉴权（Authorization）

    • 确认你是否有权限做这件事。

    • 常见方式：

      • RBAC（基于角色的访问控制） ✅ 最常用

      • ABAC（基于属性的访问控制）

      • Node（Kubelet 默认使用的权限控制器）

    🔑 输出结果：允许/拒绝。

  3. 准入控制（Admission Control）

    • 在通过认证+鉴权后，还会有一些插件执行进一步校验或修改请求。

    • 例如：

      • LimitRanger：限制 Pod 的 CPU/内存大小。

      • NamespaceLifecycle：禁止删除关键 namespace。

      • PodSecurity（新版本代替 PSP）：控制 Pod 的安全上下文。

API组

在 K8s 里，**API 组（API Group）是对 Kubernetes API 资源的一种逻辑分类机制。

K8s 的 API 是通过 RESTful 风格设计的，路径一般长这样：

/apis/<API组>/<版本>/<资源>

比如：

  • 核心 API 组（core group，也叫 legacy group，没有名字）：

    /api/v1/pods
/api/v1/namespaces

  • apps 组：

    /apis/apps/v1/deployments
/apis/apps/v1/statefulsets

  • rbac.authorization.k8s.io 组：

    /apis/rbac.authorization.k8s.io/v1/roles

👉 也就是说，同一个 API 组下可以包含多个资源（Pods、Deployments 等），每个资源有不同版本。

常见的 API 组

  • 核心组（Core/Legacy）
    没有组名，路径就是 /api/v1/...，包含 Pods、Services、ConfigMaps、Secrets 等常用对象。

  • apps
    主要是工作负载资源：Deployment、DaemonSet、StatefulSet、ReplicaSet 等。

  • batch
    Job、CronJob。

  • rbac.authorization.k8s.io
    RBAC 相关：Role、ClusterRole、RoleBinding、ClusterRoleBinding。

  • apiextensions.k8s.io
    CRD（自定义资源定义）。

  • 其他扩展
    networking.k8s.io、policy、autoscaling、storage.k8s.io 等。

在访问控制（RBAC）里的作用

RBAC 授权规则里，权限绑定需要指定 资源对象归属的 API 组。
这样可以实现更细粒度的权限控制。

举例：

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:namespace: defaultname: pod-reader
rules:
- apiGroups: [""]           # 空字符串表示 core groupresources: ["pods"]verbs: ["get", "list"]
- apiGroups: ["apps"]       # apps 组resources: ["deployments"]verbs: ["get", "list"]

解释：

  • apiGroups: [""] 表示核心组（pods 就属于 core）。

  • apiGroups: ["apps"] 表示 apps 组（deployments 就属于 apps/v1）。

  • 如果写 apiGroups: ["*"]，就表示所有 API 组。

描述 RBAC

Role-Based Access Control（基于角色的访问控制）。

它是一种授权机制，用于 将权限分配给角色，再将角色绑定到用户/ServiceAccount。

在 K8s 中，RBAC 是通过 API 资源对象 来定义的，主要涉及：

  • Role / ClusterRole：定义一组权限。
  • RoleBinding / ClusterRoleBinding：把权限绑定到用户或 ServiceAccount。

RBAC 的多维度权限控制

RBAC 在 K8s 中就是一个 权限矩阵，你可以从多个维度组合权限：

维度含义示例
用户 / 组谁来操作用户 alice、组 dev-team、ServiceAccount nginx-sa
资源 (resources)操作的对象pods、deployments、services、configmaps
命名空间 (namespace)作用范围只能访问 dev 命名空间的 Pod
API 组 (apiGroups)资源所属的 API核心资源 ("")，apps 组 (apps/v1)，RBAC 组 (rbac.authorization.k8s.io)
操作方法 (verbs)允许的操作get、list、watch、create、update、delete

这样组合后，你就能非常细粒度地定义权限，比如：
👉 alice 用户在 dev 命名空间 只能查看 Pod 和 Service，不允许修改。

使用 RBAC 资源对象

RBAC 主要有 四个对象：

  • Role / ClusterRole：定义权限

  • RoleBinding / ClusterRoleBinding：把权限分配给用户/组/SA

例子 1：给某个用户分配 namespace 级别权限

让用户 alice 只能在 dev 命名空间查看 Pod 和 Service。

# Role: 定义权限规则
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:namespace: devname: dev-viewer
rules:
- apiGroups: [""]                   # "" 表示 core API group (pods, services, configmaps)resources: ["pods", "services"]   # 限定资源verbs: ["get", "list", "watch"]   # 允许的操作方法
---
# RoleBinding: 把权限赋给用户
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:name: dev-viewer-bindingnamespace: dev
subjects:
- kind: User                        # 可以是 User, Group, ServiceAccountname: alice                       # 用户名apiGroup: rbac.authorization.k8s.io
roleRef:kind: Rolename: dev-viewerapiGroup: rbac.authorization.k8s.io

例子 2：组权限

让 dev-team 组的所有人都能管理 deployments。

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:namespace: devname: deployment-admin
rules:
- apiGroups: ["apps"]              # 指定 API 组 (apps/v1)resources: ["deployments"]verbs: ["*"]                     # 允许所有操作 (create, update, delete, get...)
---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:namespace: devname: deployment-admin-binding
subjects:
- kind: Group                      # 对整个组赋权name: dev-teamapiGroup: rbac.authorization.k8s.io
roleRef:kind: Rolename: deployment-adminapiGroup: rbac.authorization.k8s.io

例子 3：集群级别权限

让 bob 拥有 跨命名空间的 Node 查看权限。

# ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:name: node-reader
rules:
- apiGroups: [""]resources: ["nodes"]verbs: ["get", "list", "watch"]
---
# ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:name: node-reader-binding
subjects:
- kind: Username: bobapiGroup: rbac.authorization.k8s.io
roleRef:kind: ClusterRolename: node-readerapiGroup: rbac.authorization.k8s.io

好的，我来帮你系统梳理一下 K8s 面向用户授权 和 面向应用程序授权 的过程。

练习:使用RBAC进行授权

Kubernetes 的授权对象主要有两类：

  • 用户（User/Group）：通常代表人类用户。

  • 服务账号（ServiceAccount）：通常代表 Pod 内运行的应用程序。

两者最终都是通过 RBAC 规则（Role/ClusterRole + RoleBinding/ClusterRoleBinding） 来实现权限分配。

面向用户授权

授权过程

  1. 创建证书和用户配置

    • 用户要访问集群，需要身份凭证。常见方式：

      • 使用 kubeadm/cfssl 等生成 X.509 客户端证书

      • 或者直接创建一个 kubeconfig 配置文件，里面包含证书和集群 API 地址。

    示例生成证书：

    # 生成私钥
openssl genrsa -out user.key 2048# 生成证书签名请求
openssl req -new -key user.key -out user.csr -subj "/CN=myuser/O=mygroup"# 使用集群 CA 签发
openssl x509 -req -in user.csr -CA ca.crt -CAkey ca.key -CAcreateserial \
-out user.crt -days 365

    其中 CN=myuser 是用户名，O=mygroup 是用户组。

  2. 生成 kubeconfig 文件

    • 将证书、CA、公私钥等信息写入用户专属的 kubeconfig：
    kubectl config set-credentials myuser \--client-certificate=user.crt \--client-key=user.key
kubectl config set-context myuser-context \--cluster=kubernetes \--namespace=default \--user=myuser
kubectl config use-context myuser-context

  3. 定义角色（Role/ClusterRole）

    • Role：命名空间级权限

    • ClusterRole：集群级权限

    例：只允许 myuser 在 default 命名空间获取和列出 Pod：

    apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:namespace: defaultname: pod-reader
rules:
- apiGroups: [""]resources: ["pods"]verbs: ["get", "list"]

  4. 绑定角色（RoleBinding/ClusterRoleBinding）

    • 将角色和用户绑定：
    apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:name: read-pods-bindingnamespace: default
subjects:
- kind: Username: myuser   # 必须和证书 CN 对应apiGroup: rbac.authorization.k8s.io
roleRef:kind: Rolename: pod-readerapiGroup: rbac.authorization.k8s.io

  5. 测试用户权限

    kubectl --context=myuser-context get pods   #  成功
kubectl --context=myuser-context delete pods testpod   #  无权限
内置集群角色

K8s 内置了许多 ClusterRole，常用的有：

  • cluster-admin：对整个集群有最高权限

  • admin：对某个 namespace 拥有管理权限

  • edit：对某个 namespace 拥有读写权限（但不能管理 RBAC）

  • view：对某个 namespace 只有只读权限

这些可以直接用来绑定给用户/组。虽然这些是集群角色,但使用时也可以进行命名空间限制.

面向应用程序授权

应用程序（Pod）通常通过 ServiceAccount (SA) 与 RBAC 配合来进行授权。

授权过程

  1. 创建 ServiceAccount

    apiVersion: v1
kind: ServiceAccount
metadata:name: app-sanamespace: default

  2. 创建角色（Role/ClusterRole）
    例如：允许应用读取 ConfigMap：

    apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:namespace: defaultname: configmap-reader
rules:
- apiGroups: [""]resources: ["configmaps"]verbs: ["get", "list"]

  3. 绑定角色到 ServiceAccount

    apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:name: read-configmaps-bindingnamespace: default
subjects:
- kind: ServiceAccountname: app-sanamespace: default
roleRef:kind: Rolename: configmap-readerapiGroup: rbac.authorization.k8s.io

  4. 在 Pod 中使用该 ServiceAccount

    apiVersion: v1
kind: Pod
metadata:name: app-podnamespace: default
spec:serviceAccountName: app-sacontainers:- name: appimage: nginx

    Pod 内的容器会自动挂载该 SA 的 Token 文件到 /var/run/secrets/kubernetes.io/serviceaccount/，应用程序就能以这个身份访问 API。

总结：

  • 用户授权：基于证书 + kubeconfig + Role/ClusterRole + RoleBinding/ClusterRoleBinding

  • 应用程序授权：基于 ServiceAccount + RBAC

隐藏模块:

某教材的味一下就来了...


文章转载自：

http://K8kKhxzn.xmnLc.cn
http://u1B0Qyza.xmnLc.cn
http://iG6y0TVg.xmnLc.cn
http://XcPbrk6W.xmnLc.cn
http://MAVN4lja.xmnLc.cn
http://I2gBNlq8.xmnLc.cn
http://LAd6Vrfv.xmnLc.cn
http://pGVmYHGk.xmnLc.cn
http://esucrhzb.xmnLc.cn
http://rrC4gYMD.xmnLc.cn
http://YPsiPZQH.xmnLc.cn
http://o2mOzeIG.xmnLc.cn
http://5I9awJ5S.xmnLc.cn
http://8xUwikK4.xmnLc.cn
http://HDrzrdDf.xmnLc.cn
http://nV0Hf9nV.xmnLc.cn
http://sNeF2Ofe.xmnLc.cn
http://oG4flE4I.xmnLc.cn
http://3zMnC1DY.xmnLc.cn
http://CteAd5Xo.xmnLc.cn
http://bRT6EZix.xmnLc.cn
http://xKiaYXE8.xmnLc.cn
http://BhP1Glnn.xmnLc.cn
http://XrsMU3bE.xmnLc.cn
http://dsMI8H2M.xmnLc.cn
http://kQSeyzmI.xmnLc.cn
http://Gbei5zGP.xmnLc.cn
http://nK5xkHso.xmnLc.cn
http://W7k7nJXv.xmnLc.cn
http://gjH6Lwr9.xmnLc.cn
http://www.dtcms.com/a/368781.html

相关文章：

  • 动物专家？单词测试！基于 TensorFlow+Tkinter 的动物识别系统与动物识别小游戏
  • 腾讯最新开源HunyuanVideo-Foley本地部署教程：端到端TV2A框架，REPA策略+MMDiT架构，重新定义视频音效新SOTA！
  • GD32入门到实战33--用单片机内部FLASH保护产品参数
  • Python的RSS/Atom源解析库feedparser
  • 抓虫：loongarch64架构selinux强防开启程序执行报错execmod
  • 酷柚易汛ERP 2025-09-05系统升级日志
  • STM32——WDG看门狗
  • Redis 发布订阅：社区的 “通知栏与分类订阅” 系统
  • WordPress性能优化全攻略：从插件实战到系统级优化
  • [新启航]激光频率梳 3D 轮廓测量 - 蓝光机械 3D 扫描的工作原理及优缺点
  • 3DEXPERIENCE平台五大实用技巧指南
  • 彻底搞懂深度学习-模型压缩（减枝、量化、知识蒸馏）
  • 概率论第二讲——一维随机变量及其分布
  • ChartGPT深度体验：AI图表生成工具如何高效实现数据可视化与图表美化？
  • 【AndroidStudio】官网下载免安装版，AndroidStudio压缩版的配置和使用
  • Android Activity的启动流程
  • 将 Android 设备的所有系统日志（包括内核日志、系统服务日志等）完整拷贝到 Windows 本地
  • NGUI--三大基础控件
  • 服务器IP暴露被攻击了怎么办？
  • Transformer实战——使用 run_glue.py 微调模型
  • SQLalachemy 错误 - Lost connection to MySQL server during query
  • 门控MLP(Qwen3MLP)与稀疏混合专家(Qwen3MoeSparseMoeBlock)模块解析
  • React Hooks useContext
  • 【Linux】Linux 的 cp -a 命令的作用
  • 基于FPGA实现CRC校验码算法（以MODBUS中校验码要求为例）verilog代码+仿真验证
  • LeetCode刷题-top100（ 矩阵置零）
  • 算法模板（Java版）_DFS与BFS
  • 一分钟了解Modbus 转 IEC61850 网关
  • Webpack 有哪些特性？构建速度？如何优化？
  • 2025精选5款AI视频转文字工具，高效转录秒变文字！