GitHub App 在最小权限和管理方面的改进

2026-10-14

我们今天发布多项 GitHub Apps 改进，帮助开发者摆脱经典 PAT，改善 GitHub App 管理，并请求更少的敏感权限。我们还让仓库管理员更容易使用其管理员已批准的应用程序，并在我们计划中的工作负载联合功能之前更新了 GitHub App 凭据管理 UI。

新增了两个仓库细粒度权限，适用于细粒度 PAT 和 GitHub Apps。

repository_creation:write：允许调用者在授予它的账户中创建仓库。

installation_repositories:write：允许调用者将该仓库添加至组织中的安装或从安装中移除。

你现在可以使用 repository_creation:write 权限创建仓库，而无需更宽泛的 repository_administration:write 权限。此前，应用或 PAT 需要 repository_administration:write 才能创建仓库。该权限还授予其他仓库管理功能，如删除和转移。这可能导致管理员拒绝应用、禁止具有该权限的 PAT，或不得不接受过度授权风险。新权限通过仅授予创建仓库的能力来支持最小权限方法。创建仓库时，创建它的应用或用户将被授予对该仓库的访问权限。使用此权限的应用仍需要组织管理员安装该应用。参见 API 文档中关于在组织中、从模板、为当前用户、使用 fork 以及通过 GraphQL 创建仓库的内容。

“向安装添加仓库”组织级 API 及其对应的移除 API 现在支持 GitHub Apps 和细粒度 PAT。此前，这些 API 仅支持粗粒度 repo 范围。这些 API 支持新的仓库级细粒度权限：installation_repositories:write。在某个仓库上拥有此权限允许调用者将该仓库添加至组织中的任何安装或从任何安装中移除。如果调用者是用户，他们还必须是组织所有者或相关仓库的管理员。这允许组织构建自动化，控制哪些仓库可被哪些 GitHub Apps 访问，而无需依赖具有广泛权限的管理员 PAT。

历史上，所有请求组织级访问权限的应用都会被仓库管理员阻止安装到仓库，无论如何。在应用已安装到组织的情况下，这一限制已放宽，这意味着它已获得组织所有者对该组织级访问的批准。仓库管理员现在可以编辑现有安装，将其仓库添加到应用，而无需组织所有者批准。这些应用已拥有组织级访问权限，因此将它们添加到组织中的另一个仓库不会增加该访问权限，也不会给仓库管理员额外权限。

GitHub 发布多项 GitHub Apps 权限与管理更新，新增 repository_creation:write 和 installation_repositories:write 两个仓库级细粒度权限，减少对宽泛 PAT 与过度授权的依赖，并放宽已获组织批准的应用由仓库管理员添加仓库的限制。

这是什么信号

这条 GitHub Changelog 信号的核心不是简单“加了两个权限”，而是 GitHub 正在把 GitHub Apps 替代 classic PAT 的路径补齐到更细的操作层：创建仓库不再必须拿 repository_administration:write，管理安装中的仓库也不再必须依赖粗粒度 repo scope。它把“最小权限”从安全口号变成可分配的仓库级权限，说明平台治理正在从粗放授权转向按操作拆分。

为什么重要

classic PAT 和宽泛权限长期是开发者平台治理的痛点：一个 PAT 可能同时具备创建、删除、转移仓库等能力，管理员要么拒绝应用，要么接受过度授权风险。新权限把创建仓库、安装仓库管理拆成单一职责，让自动化只拿必要能力；同时，已获组织批准的应用可由仓库管理员编辑安装并加入仓库，减少了组织 owner 的审批瓶颈。这不是单纯 API 更新，而是权限模型和审批责任边界的调整。

对谁有价值

平台工程、安全团队、DevOps、开发者工具厂商、开源组织管理员，以及正在把内部自动化从 classic PAT 迁移到 GitHub Apps 的团队，都会直接受益。尤其是需要批量创建仓库、控制哪些仓库可被哪些 App 访问、又不想发放管理员级 PAT 的组织，新权限提供了更可控的自动化接口。

可以怎么行动

先盘点现有 classic PAT、repository_administration:write 和粗粒度 repo scope 的使用场景，把“仅创建仓库”的流程迁移到 repository_creation:write，把“把仓库加入或移出安装”的流程迁移到 installation_repositories:write。随后梳理 App 安装审批矩阵，明确组织 owner 与仓库管理员的边界，并验证组织级 API、GraphQL 及用户调用时需满足的组织 owner 或仓库管理员条件。凭据管理 UI 的提前更新指向后续工作负载联合能力，但原文只说明是计划中功能，当前落地重点仍是权限拆分和安装管理。

风险或限制

新权限仍要求组织管理员安装应用；用户调用 installation_repositories:write 时还需具备组织 owner 或相关仓库管理员身份。放宽安装限制只适用于已安装到组织、已获组织级访问批准的应用，并不意味着所有历史应用都会自动被仓库管理员添加。迁移前应测试 API 兼容性和实际权限效果，避免权限碎片化后缺少审计。原文未给出具体迁移时间表，落地时需以实际文档和测试结果为准。

这条内容的真正价值，不只是“有人发布了一个新功能”，而是它揭示了 github.blog 背后的产品方向、工作流变化或竞争信号。对 OPC 来说，这种信息可以转化成持续追踪的栏目选题。

如果把《GitHub App 在最小权限和管理方面的改进》放到你的内容系统里，它最大的价值在于帮助读者更快看懂“为什么值得关注”，而不是只看到一条碎片化动态。