本文为原文前 6,000 字符的节选翻译，完整内容请查看原文。

The fastest way to create a security incident on Google Play isn’t a code vulnerability — it’s handing your agency “Admin” access because you were in a hurry. Play Console’s permission model is granular enough to do this properly, but most teams never go beyond the defaults. Here’s how to set up Google Play Console users and permissions so every person (and service) has exactly the access they need and nothing more.

在 Google Play 上引发安全事故的最快方式并非代码漏洞，而是因为匆忙而授予代理机构“管理员”权限。Play Console 的权限模型足够细化，可以妥善处理此类问题，但大多数团队从未超越默认设置。以下是如何设置 Google Play Console 用户和权限，以确保每个人（及服务）仅拥有其所需的精确访问权限，不多也不少。

In short: Play Console permissions work at two levels: account permissions apply to everything, while app permissions apply to specific apps. Give most people app-level access only, scoped to the apps they actually work on, and reserve account admin for one or two founders. Set an expiry date on every contractor invite, and review the whole user list once a quarter. Granular Google Play Console users and permissions prevent over-privileged team access.

简而言之：Play Console 权限分为两个级别：账户权限适用于所有内容，而应用权限仅适用于特定应用。应仅授予大多数人应用级别的访问权限，并将其范围限定在他们实际负责的应用上，同时将账户管理员权限保留给一两位创始人。为每位承包商的邀请设置过期日期，并每季度审查一次整个用户列表。细化的 Google Play Console 用户和权限设置可以防止团队成员拥有过度特权。

What are the two permission layers? Play Console permissions operate at two levels, and confusing them is the #1 mistake: Account permissions apply across everything: managing users, viewing financial reports, account-level settings. Admins live here. App permissions apply to specific apps: releases, store listings, testing, quality data. Always prefer app-level permissions. An ASO freelancer working on two of your six apps should never have account-level anything. Google’s guide to adding users and managing permissions explains how the two levels interact and lists every permission by its exact name.

什么是两个权限层级？Play Console 权限在两个级别上运行，混淆它们是第一大错误：账户权限适用于所有方面：管理用户、查看财务报告、账户级设置。管理员在此级别。应用权限适用于特定应用：发布、商店详情、测试、质量数据。始终优先选择应用级权限。一位负责你六个应用中两个的 ASO 自由职业者，绝不应拥有任何账户级权限。Google 关于添加用户和管理权限的指南解释了这两个级别如何交互，并列出了每个权限的确切名称。

Which permission groups actually matter? When you invite a user (Users and permissions → Invite new users), you choose from permission groups. The ones you’ll actually use: Different roles need different groups under Google Play Console users and permissions.

哪些权限组真正重要？当你邀请用户时（用户和权限 → 邀请新用户），你需要从权限组中进行选择。你实际会用到的组包括：不同的角色在 Google Play Console 用户和权限下需要不同的组。

Role Permission groups Scope Founder / CTO Admin (all permissions) Account level — everything Release manager Release to production, exclude devices, and use Play App Signing; View app information (read-only) Per app, production included Developer Release apps to testing tracks; View app information (read-only) Per app, testing tracks only QA tester View app information (read-only); View app quality information (read-only) Per app ASO / marketing Manage store presence; View financial data (optional) Per app Support agent Reply to reviews Per app Finance View financial data; Manage orders and subscriptions Account or per app

角色 权限组 范围 创始人 / CTO 管理员（所有权限） 账户级 — 所有内容 发布经理 发布到正式版、排除设备并使用 Play App Signing；查看应用信息（只读） 每个应用，包含正式版 开发者 发布应用到测试轨道；查看应用信息（只读） 每个应用，仅限测试轨道 QA 测试员 查看应用信息（只读）；查看应用质量信息（只读） 每个应用 ASO / 市场 管理商店展示；查看财务数据（可选） 每个应用 支持代理 回复评论 每个应用 财务 查看财务数据；管理订单和订阅 账户或每个应用

Two critical details people miss: Release rights are split by track. “Release apps to testing tracks” lets a developer ship to internal, closed and open testing without touching production; production needs the separate “Release to production, exclude devices, and use Play App Signing” permission. Give every developer the testing-tracks permission and reserve production for the release manager. “Reply to reviews” is separate from “Manage store presence.” Your support team doesn’t need listing edit rights, and your ASO person doesn’t need to reply to reviews. Split them.

人们容易忽略的两个关键细节：发布权限按轨道划分。“发布应用到测试轨道”允许开发者发布到内部、封闭和开放测试，而无需触及正式版；正式版需要单独的“发布到正式版、排除设备并使用 Play App Signing”权限。应授予每位开发者测试轨道权限，并将正式版权限留给发布经理。“回复评论”与“管理商店展示”是分开的。你的支持团队不需要商店详情编辑权限，而你的 ASO 人员也不需要回复评论。请将它们分开。

How do I onboard a new team member? Go to Users and permissions in Play Console (account level). Click Invite new users, enter their Google account email. (They need a Google account — not necessarily a Gmail, any Google-linked email works.) Set Account permissions: for most people, none. Seriously — leave it blank. Under App permissions, click Add app, select the specific apps, then tick only the needed groups per app. Set an access expiry date for contractors. This is the feature everyone forgets and then regrets. A 90-day expiry on agency access means you never have to remember to revoke it. The invitee accepts via email. Verify their access shows the correct scope before they start work. Follow these steps when onboarding with Google Play Console users and permissions. One more detail: an invitation expires after 30 days if the invitee doesn’t accept it, so if someone never shows up in your user list, resend the invite rather than assuming the permissions are wrong.

如何引导新团队成员入职？前往 Play Console 中的“用户和权限”（账户级）。点击“邀请新用户”，输入他们的 Google 账户邮箱。（他们需要一个 Google 账户——不一定是 Gmail，任何关联 Google 的邮箱都可以。）设置账户权限：对于大多数人，选择“无”。说真的——留空即可。在应用权限下，点击“添加应用”，选择特定应用，然后仅勾选每个应用所需的组。为承包商设置访问过期日期。这是每个人都会忘记并随后后悔的功能。为代理机构设置 90 天的过期时间意味着你永远不必记得去撤销它。受邀者通过电子邮件接受邀请。在他们开始工作前，验证其访问权限是否显示正确的范围。在进行 Google Play Console 用户和权限入职引导时，请遵循这些步骤。还有一个细节：如果受邀者在 30 天内未接受，邀请将会过期，因此如果某人从未出现在你的用户列表中，请重新发送邀请，而不是假设权限设置有误。

How do service accounts fit in? CI/CD pipelines, fastlane, and the Gradle Play Publisher plugin authenticate as service accounts — Google Cloud service accounts you invite like users. Treat them with the same least-privilege discipline:

服务账户如何适用？CI/CD 流水线、fastlane 和 Gradle Play Publisher 插件通过服务账户进行身份验证——即你像邀请用户一样邀请的 Google Cloud 服务账户。请以同样的最小权限原则对待它们：

Create the service account in Google Cloud

gcloud iam service-accounts create play-publisher
—display-name “Play Console publisher (CI)“

Create and download a key (store in CI secrets, never in the repo)

gcloud iam service-accounts keys create play-key.json
—iam-account play-publisher@your-project.iam.gserviceaccount.com

在 Google Cloud 中创建服务账户

gcloud iam service-accounts create play-publisher
—display-name “Play Console publisher (CI)“

创建并下载密钥（存储在 CI 密钥中，切勿存入代码仓库）

gcloud iam service-accounts keys create play-key.json
—iam-account play-publisher@your-project.iam.gserviceaccount.com

Then in Play Console: invite play-publisher@your-project.iam.gserviceaccount.com under Users and permissions, grant it Release apps to testing tracks permission scoped to the specific apps (and ideally testing tracks only for dev pipelines, production only for the release pipeline). Two separate service accounts — ci-testing and ci-production — is the clean setup. If the testing key leaks, production is untouched. Rotate service account keys on a schedule — quarterly is reasonable. And never commit play-key.json to version control; that’s how keys end up on GitHub and in someone else’s pipeline.

然后在 Play Console 中：在“用户和权限”下邀请 play-publisher@your-project.iam.gserviceaccount.com，授予其针对特定应用的“发布应用到测试轨道”权限（理想情况下，开发流水线仅限测试轨道，发布流水线仅限正式版）。两个独立的服务账户——ci-testing 和 ci-production——是整洁的设置。如果测试密钥泄露，正式版也不会受到影响。按计划轮换服务账户密钥——每季度一次是合理的。切勿将 play-key.json 提交到版本控制中；这就是密钥最终出现在 GitHub 和他人流水线中的原因。

What does the quarterly access review cover? Permissions rot. People change roles, contractors finish, co-founders drift. Every quarter: [ ] Export the user list from Users and permissions [ ] For each user: do they still need this access? At this scope? [ ] Check access expiry dates — extend or let lapse deliberately [ ] Verify no former employees or finished contractors remain [ ] Confirm service account keys were rotated [ ] Check that exactly 1–2 people hold account Admin (never more than necessary) The most common finding in these reviews: an agency that finished six months ago still has production release rights. The expiry-date feature exists precisely to prevent this.

季度访问审查涵盖哪些内容？权限会腐化。人员会更换角色，承包商会结束工作，联合创始人会离开。每季度：[ ] 从“用户和权限”导出用户列表 [ ] 对于每个用户：他们是否仍需要此访问权限？范围是否合适？ [ ] 检查访问过期日期——延长或故意让其过期 [ ] 验证没有前员工或已结束工作的承包商留存 [ ] 确认服务账户密钥已轮换 [ ] 检查是否仅有 1-2 人拥有账户管理员权限（绝不超过必要人数）。这些审查中最常见的发现是：六个月前结束工作的代理机构仍拥有正式版发布权限。过期日期功能的存在正是为了防止这种情况。

What about special cases? Transferring ownership when a founder leaves. Don’t just add the new person as Admin — remove the departing founder’s access entirely, rotate service account keys they may have.

特殊情况怎么办？当创始人离职时转移所有权。不要只是将新人添加为管理员——应完全移除离职创始人的访问权限，并轮换他们可能拥有的服务账户密钥。