【k8s】用户和服务账户联系(user、serviceaccount、sa)

文章目录

相关文章:
【k8s】serviceAccount、role、RoleBinding入门示例
【k8s】pod和serviceaccount关系
【k8s】用户和服务账户联系(user、serviceaccount、sa)
【k8s】--as=system:serviceaccount:demo-rbac:demo-user模拟某组件的某sa

概述

在 Kubernetes 和 OpenShift 中,用户和服务账户是两种不同的概念,用于控制权限和访问资源:

用户(User)
  1. 定义:

    用户是集群外部的实体,代表人或应用程序,通过 API 或命令行与 Kubernetes 集群进行交互。

  2. 来源:

    用户由集群管理员创建,可以是一个真实用户(如开发人员)或一个外部系统(如 CI/CD 工具)。它们是集群外部的身份,没有自动与 Pod 关联。

  3. 使用场景:

    • 用户通过工具(如 kubectloc)或 API 调用创建、管理资源(如 Pod、Deployment)。
    • 用户需要认证才能访问集群,通常通过以下方式认证:
      • 证书(x509 证书)
      • OAuth Token(在 OpenShift 中常用)
      • 服务提供的身份认证(如 OIDC 或 LDAP)
    • 用户权限通过 RoleClusterRoleRoleBindingClusterRoleBinding 授予。
  4. 与 Pod 的关系:

    用户本身不会直接运行 Pod,但可以通过创建资源(如 Deployment、Pod、Job 等)间接控制 Pod 的行为。Pod 的权限最终由 ServiceAccount 决定,而不是用户。


服务账户(ServiceAccount)
  1. 定义:

    服务账户是 Kubernetes 内部的一种身份,用于 Pod 和其他控制器(如 Deployment、Job)与 Kubernetes API 交互。

  2. 来源:

    每个 Pod 都必须关联一个服务账户:

    • 如果未显式指定服务账户,系统会自动使用命名空间中的默认服务账户(default)。
    • 你也可以创建自定义服务账户并为其分配特定权限。
  3. 作用:

    • 服务账户是 Kubernetes 集群内部的身份,用于 Pod 或控制器与 API 交互(例如获取 ConfigMap、Secret 或更新资源状态)。
    • 每个服务账户都有一个关联的令牌,挂载到 Pod 中,供应用程序访问 Kubernetes API。
  4. 与 Pod 的关系:

    • 服务账户直接与 Pod 绑定。
    • Pod 的运行时权限和安全上下文由绑定的服务账户和分配的 SCC 决定。

用户与服务账户的区别
属性 用户(User) 服务账户(ServiceAccount)
作用范围 外部用户与 Kubernetes 交互 Pod 或控制器内部与 Kubernetes 交互
身份来源 通过认证系统(如证书、Token、OIDC 等) Kubernetes 内部自动创建或手动创建
使用对象 人类用户、外部应用程序 Pod 或控制器(如 Deployment、CronJob)
权限管理 通过 Role/ClusterRole 授予权限 通过 Role/ClusterRole 和 SCC 授予权限
与 Pod 的关系 间接关系,通过 API 操作 Pod 直接关系,服务账户是 Pod 的运行身份


Pod 的身份来源:用户 vs 服务账户

1. 用户创建 Pod:

  • 用户通过 CLI 或 API 创建 Pod:

    bash 复制代码
    oc create -f pod.yaml
  • 用户需要被授予 create pods 的权限(通过 Role/ClusterRole)。

    系统会检查用户是否有权限执行此操作

2.服务账户运行 Pod:

  • 当 Pod 被创建后,它会使用指定的 serviceAccountName。
  • 如果未指定,则使用默认的 default 服务账户。
  • 该服务账户决定了 Pod 在运行时的权限和安全上下文(指的是scc)。

总结

  • 用户是集群外部的实体,创建和管理 Kubernetes 资源。
  • 服务账户是 Kubernetes 内部的实体,用于 Pod 与集群 API 的交互。
  • SCC 是绑定到用户或服务账户的,控制用户是否可以创建特定类型的 Pod,以及 Pod 运行时是否满足安全约束。
  • Pod 的权限最终由服务账户决定,而不是直接由用户决定。
相关推荐
江畔何人初7 小时前
pod的定义以及创建过程
linux·运维·云原生
等什么君!8 小时前
docker -数据卷技术
运维·docker·容器
花酒锄作田9 小时前
Debian 13基于kubeadm和containerd部署单节点kubernetes
kubernetes·containerd·cilium
上天_去_做颗惺星 EVE_BLUE9 小时前
Docker高效使用指南:从基础到实战模板
开发语言·ubuntu·docker·容器·mac·虚拟环境
Gary董10 小时前
高并发的微服务架构如何设计
微服务·云原生·架构
东哥爱编程10 小时前
使用Runpod进行gpu serverless推理
云原生·serverless
好好沉淀11 小时前
Docker开发笔记(详解)
运维·docker·容器
Ankie Wan12 小时前
cgroup(Control Group)是 Linux 内核提供的一种机制,用来“控制、限制、隔离、统计”进程对系统资源的使用。
linux·容器·cgroup·lxc
lcx_defender13 小时前
【Docker】Docker部署运行nacos
运维·docker·容器
啦啦啦小石头14 小时前
docker添加用户权限不使用sudo
运维·docker·容器