跳到页面内容
跳到互动练习
互动课堂 / 机器身份登记处DAILY / SECURITY TERMS

076 / 身份与访问 / Service Account

机器人还在上班,谁在管它的身份?

服务账户 · Service Account

夜里的机器人不用等人登录,就能读取工作文件。它凭什么证明自己,又为什么碰不到管理员的柜子?把机器身份、使用它的凭据和负责人,放进同一张可追溯的工作单。

开始探索 ↓8–12 分钟
动手实验 · 场景判断 · 实用检查

机器人从文件柜搬出工作资料,王冠被栏杆与守卫隔开,角落里一台旧机器人倒在沙漏旁。它们分别提示自动化身份、受限权限和退役复查;沙漏不代表所有服务账号都会自行过期。

服务账户 · 本课场景

Service Account 概念寓意:供应用和自动化任务使用的非人类身份,应严格限制权限并管理凭据。

机器人从文件柜搬出工作资料,王冠被栏杆与守卫隔开,角落里一台旧机器人倒在沙漏旁。它们分别提示自动化身份、受限权限和退役复查;沙漏不代表所有服务账号都会自行过期。

按 Esc 或点击画面外侧关闭。打开原图 ↗

本课任务 / 服务账户

分别验证工作负载如何取得机器身份、该身份获准做什么,以及谁负责它的整个生命期。

  • 区分服务主体与认证凭据
  • 检查工作负载信任和资源权限两道边界
  • 规划专用身份、责任人与退役流程

服务账号是机器人的密码吗?

服务账号通常是供应用或工作负载使用的非人类主体;凭据是证明能够代表这个主体的材料。主体可以继续存在,而密钥或短期凭据轮换;不能把一份密钥文件当作完整的身份。[1]

谁可以使用它,和它能做什么?

这是两道不同的边界。工作负载的信任关系决定谁能取得或代表该身份,授权策略决定该身份能访问的资源和动作。任一道过宽,都可能让无关程序借用现成权限。[1][2]

不用长期密钥就没有凭据风险吗?

托管身份或联邦方式可减少自行分发长期秘密,但仍要保护工作负载、短期凭据和信任配置。Google Cloud 的附加服务账号、模拟身份与联邦路径各有前提,不能当作所有平台的统一机制。[1][2]

亲手探索 / 不同条件,不同结果

先认对这台机器,再决定它能碰哪些文件。

配送机器人与无关统计程序都尝试使用 dispatch-bot 身份。比较可信绑定、有效旧密钥副本、过期或缺失证明,再把账号授权与东/西区边界取交集。小珊的责任登记另作治理提醒;不读取或创建真实秘密。

工作负载身份对照台 · Service Account

配送机器人是谁,凭什么,又能做什么?

把非人身份、认证材料与权限分成三张卡。再换成无关程序,比较正确的工作负载绑定与可复制旧密钥的差别。

非人身份
dispatch-bot
服务账号;不是小珊的个人账号
批准用途
读取东区配送单
只读任务无需修改或跨区权限
责任联系人
小珊 / 配送平台组
负责人负责生命周期,不冒充调用主体

本页固定服务账号仍启用。所有证明都是预设条件,全部选择只在页面内比较;不连接云账号,不创建或上传凭据,不改变任何安全设置。

预设可信平台已验证来源、接收方、有效期,并只把 delivery-worker 绑定到 dispatch-bot。
本页明确规定有效权限取交集;不冒充任何厂商完整的 IAM 求值规则。

认证卡:能否建立身份?

delivery-worker 尝试作为 dispatch-bot。

预设可信平台已验证来源、接收方、有效期,并只把 delivery-worker 绑定到 dispatch-bot。

授权卡:授权 ∩ 资源边界

下列是配置所产生的有效动作,不代表上方认证已经成功。

  • 包含:读取东区配送单
  • 排除:修改东区配送单
  • 排除:读取西区配送单
本页仅枚举这三种动作;真实环境应核对全部有效权限。
本模型中,登记缺失会产生治理告警,但不会自动撤销服务端已经授予的权限。
⑦ 预测:请求会停在哪里?

尚未运行。先预测,再检查本地教学模型。

先把“修改东区”换成“读取东区”。再选择无关统计程序,对比可信绑定与旧密钥副本。最后扩大账号授权,观察资源边界还能挡住什么、挡不住什么。换密钥会自动收窄账号权限吗?

随手查 / 把理解带回实际工作

理解机制之后,检查这些细节。

实验是简化模型。真实环境需要明确业务规则、验证失败路径,并持续维护配置与证据。

01 / 实用细节

一个用途配一份可追责的身份

为工作负载记录用途、环境、负责团队和联系点,避免多个无关服务共用一张万能通行证。专用身份让访问归因、权限调整和退役更清楚;负责人是治理责任,不是自动参与每次 API 决策的标准字段。[2]

02 / 实用细节

优先评估无需分发长期秘密的路径

平台支持时,使用托管的短期凭据或受约束的工作负载联邦方式。若确实必须管理长期密钥,记录使用位置和替换流程;不要只因应用无人值守,就默认需要一个永久不变的密码。[1][3]

03 / 实用细节

限制谁能代表这个主体

检查能附加、模拟或为服务账号创建凭据的主体,这些能力可能形成另一条提权路径。联邦信任要绑定预期工作负载;凭据已泄露时,账号名字再准确也无法证明请求来自原来的程序。[2][1]

04 / 实用细节

缩短凭据寿命不会收窄资源权限

一枚有效短期凭据仍可能携带过宽能力。给身份只授予任务所需的动作与资源,并按环境隔离;认证成功后,仍要独立检查当前请求是否获准,不能把“短期”当作“只读”的同义词。[2][1]

05 / 实用细节

轮换密钥与停用主体分别验证

替换密钥不等于停用账号。Google Cloud 明确说明,删除服务账号密钥不会撤销基于它已签发的短期凭据;事件响应需核对已发令牌和其他模拟路径,并评估停用主体会中断哪些工作负载,不能只删除本地文件。[3][4]

06 / 实用细节

机器退役,身份不能无人认领

服务停用时核对依赖和最近使用证据,按平台流程停用不再需要的身份并回收授权。Google Cloud 建议先停用再考虑删除;重新创建同名账号是新身份,不能假定原有绑定自动回来。[2]

从模拟,到验证

找一个获准的环境,实际检查一次。

勾选用于本页自查,不会自动标记整课已学会。练习与清单刷新后重置。

本页已检查 0 / 5 项

实际检查清单
30 秒场景小测

两个用途不同的服务应该共用最高权限账户吗?

能解释原因,再标记学会。

小测结果同步错题本;“已学会”沿用原有本地学习记录。

资料与依据

  1. Google Cloud · Service Accounts Overview ↗

    工作负载主体、凭据、附加账号与模拟身份

  2. Google Cloud · Use Service Accounts Securely ↗

    专用身份、文档责任人、模拟风险、最小权限与停用

  3. Google Cloud · Manage Service Account Keys ↗

    长期密钥风险、替代方案、轮换和泄露响应

  4. Google Cloud · Delete Service Account Keys ↗

    删除密钥不撤销已签发短期凭据,主体停用另有业务影响

本页场景、人物与数据均为教学示例。互动选择不会上传;收藏、已学会与错题沿用当前浏览器本地存储。来源正文核对日期:2026-10-08。