后端微服务【免费下载链接】jupyterhubMulti-user server for Jupyter notebooks项目地址https://gitcode.com/gh_mirrors/ju/jupyterhub点击查看免费下载JupyterHub 2.0 引入的 RBACRole Based Access Control框架改变了权限体系的底层数据模型它消除了 OAuth Token 与 API Token 的区分要求把原先分属两张数据库表的令牌合并为一张因此升级过程与以往任何版本都不同——所有已存在的令牌会被 Hub 在数据库升级期间删除并重建而手动签发或持久化存储的令牌则必须由管理员在升级后重新签发。本文以 docs/source/rbac/upgrade.md 为主线结合仓库中的 Alembic 迁移脚本与角色实现源码完整讲解升级前的准备、逐步操作、升级后权限调整的推荐流程以及 OAuth/API Token 在新旧体系下的本质区别帮助部署者安全、无遗漏地完成这次迁移。升级背景RBAC 为什么需要完全不同的数据库设置RBAC 框架与 JupyterHub 所有历史版本的关键差异在于它不再区分 OAuth Token 和 API Token详见下文OAuth vs API tokens一节。由于令牌的两种形态被统一原先分别存储它们的两张数据库表必须合并成一张旧版中OAuth Token 用于识别登录用户存储在浏览器 cookie 中旧版中API Token 用于服务与 Hub API 之间的通信新版中API Token 承担一切动作包括登录与认证OAuth Token 被彻底移除。这一结构性变更的直接后果是所有在升级前创建的令牌都不再符合新数据库结构必须全部替换。仓库中的迁移脚本印证了这一点——jupyterhub/alembic/versions/833da8570507_rbac.py 在upgrade()中直接执行op.drop_table(api_tokens) op.drop_table(oauth_access_tokens)脚本注释对此作出了明确说明FIXME, maybe: currently drops all api tokens and forces recreation!这能保证数据库的一致性但要求1. 升级前必须停止所有服务器2. 任何手动签发/存储的令牌都必须重新签发。通过配置文件加载的令牌会在启动时自动重建不受影响。也就是说升级的令牌处理策略是先全删、再按需重建而不是逐行迁移。后续的迁移脚本 jupyterhub/alembic/versions/651f5419b74d_api_token_scopes.py 再为重建后的api_tokens表补充scopes列、为oauth_clients表补充allowed_scopes列把旧的角色关联api_token_role_map、oauth_client_role_map折算为具体的 scope 集合从而完成权限模型的数据落地。升级影响范围被删除数据库中全部已有令牌包括 OAuth Token 与 API Token。自动重建通过jupyterhub_config.py配置文件加载的令牌会以更新后的结构在 Hub 启动时自动创建。需要手动处理任何通过 API、UI 或脚本手动签发、以及被持久化存储在其他系统中的令牌不会被自动重建必须手动重新签发。不受影响除令牌外其他所有数据库记录用户、组、服务、服务器信息等均不受影响。升级前的充分准备RBAC 升级属于破坏性迁移动手之前应当完成以下准备工作详细流程见 docs/source/howto/upgrading.md通知用户默认配置下由 JupyterHub 托管configurable-http-proxy时升级期间用户将经历服务中断应选择影响最小的时段并提前告知。备份数据库备份 JupyterHub 数据库默认是 SQLite即jupyterhub.sqlite文件若使用 MySQL/Postgres 则备份相应数据库。备份配置备份jupyterhub_config.py文件。备份用户数据用户主目录虽一般不受升级直接影响但属于关键数据建议一并备份。盘点手动令牌列出所有通过 API/hub/token或POST /users/:username/tokens签发、以及通过jupyterhub_config.py之外的方式持久化存储的令牌清单便于升级后逐一重新签发。升级步骤核心三步依据 docs/source/rbac/upgrade.md 的Upgrade steps一节完整流程如下第 1 步停止所有正在运行的服务器所有正在运行的服务器single-user server必须在升级前停止。这不仅是为了避免迁移期间数据竞争也是迁移脚本drop_table(api_tokens)的硬性前提——正在运行的服务器持有旧结构令牌若不停止其后续 API 调用将因表被删除而失败。第 2 步按标准流程升级 Hub按 Upgrading JupyterHub 的标准步骤执行关闭 Hub 进程使用进程管理器systemd、supervisord、docker等对应的命令停止 JupyterHub。升级软件包Hub 环境与 notebook 用户环境中安装的jupyterhub版本必须一致。pip 安装方式执行python3 -m pip install --upgrade jupyterhubversionconda 安装方式执行conda install -c conda-forge jupyterhubversion同时留意所用 Authenticator 与 Spawner 的新版本。升级数据库在jupyterhub_config.py所在目录执行jupyterhub upgrade-db该命令会自动定位数据库并执行必要的 Alembic 迁移即上文分析的两个迁移脚本所完成的工作删除api_tokens与oauth_access_tokens表、重建令牌相关结构、为角色/scope 建立新的关联模型。重启 JupyterHub迁移完成后重新启动 Hub 进程。⚠️重要建议升级完成、Hub 首次重启后暂时不要在jupyterhub_config.py中定义任何新角色。这样能保留 Hub 的当前状态所有既有实体自动获得默认角色之后任意一次后续启动中再定义和分配新角色都完全可行。第 3 步重新签发所有手动令牌重启后立即重新签发所有此前手动签发即非通过jupyterhub_config.py加载的令牌包括用户通过 API 或/hub/token页面申请的个人 API Token以脚本或外部系统方式签发并持久化存储的令牌任何在升级前已写入其他服务如 CI 系统、监控脚本的令牌。这些令牌在升级时已被数据库迁移删除不重新签发将导致对应集成失效。升级后首次启动会发生什么当 JupyterHub 在升级后第一次重启时所有存储在数据库中、或通过配置文件重新加载的用户、服务与令牌都会被分配其默认角色用户 → 默认user角色拥有self元作用域可访问与操作自身资源管理员用户 → 额外获得admin角色包含全部可用 scope且该角色不可被编辑令牌 → 默认token角色inherit元作用域解析为与令牌持有者相同的权限服务 → 默认无角色没有角色则无法访问受保护的 API 端点组 → 默认无角色组内用户自动继承组的权限。这一逻辑直接对应 jupyterhub/roles.py 中的assign_default_roles()def assign_default_roles(db, entity): if isinstance(entity, orm.Group): return kind type(entity).__name__ if entity.admin: grant_role(db, entityentity, rolenameadmin) else: admin_role orm.Role.find(db, admin) if admin_role in entity.roles: strip_role(db, entityentity, rolenameadmin) if kind User: grant_role(db, entityentity, rolenameuser)四个默认角色的完整 scope 定义见同一文件中的get_default_roles()jupyterhub/roles.py。在此之后新建的实体只有在没有请求其他特定角色时才会被赋予默认角色一旦通过配置或 API 指定了特定角色则以指定为准。升级后如何开始调整权限完成上述升级步骤后RBAC 框架即可投入使用。你可以定义新角色、修改默认角色admin除外并将其分配给实体详细方法见 docs/source/rbac/roles.md 中Defining Roles一节的说明。官方推荐的 RBAC 起步流程如下识别目标确定哪些管理员用户与服务你希望仅授予其实际所需的最小权限。剥离 admin 状态通过 API 或 UI 移除这些用户/服务的 admin 状态其角色将从admin降为user。注意从实体上移除角色目前只能通过jupyterhub_config.py完成重新定义角色时不列出该实体即可使其脱离该角色参见 docs/source/rbac/roles.md 中关于移除角色的说明。定义新角色在jupyterhub_config.py中用合适的 scope 定义新角色并分配给这些实体。重启生效重启 JupyterHub 使新角色生效。一个典型的角色定义示例load_roles以字典列表形式配置# in jupyterhub_config.py c.JupyterHub.load_roles [ { name: server-rights, description: Allows parties to start and stop user servers, scopes: [servers], users: [alice, bob], services: [idle-culler], groups: [admin-group], } ]角色名必须满足长度 3–255 字符、仅含小写 ASCII 字母/数字及 URL 保留字符-_.~、以字母开头、以字母或数字结尾校验逻辑见 jupyterhub/roles.py 中的_role_name_pattern与_validate_role_name。users、services、groups字段只能引用数据库中已存在、或文件中先前已定义的实体——不能通过定义角色隐式创建新用户。若新角色未定义任何 scopeJupyterHub 会给出警告提供不存在的 scope 则会直接报错。若同名角色已存在于数据库其定义与 scopes 将被覆盖admin角色除外试图覆盖会抛出RoleValueError。更完整的实战场景如 idle-culler 服务、API 启动器、按组授权的教师角色等可参考 docs/source/rbac/use-cases.md。理解关键前提OAuth vs API tokens要正确执行本次升级必须理解新旧两套令牌模型的差异。以下是 docs/source/rbac/upgrade.md 中OAuth vs API tokens一节的完整阐释。RBAC 之前双轨制令牌旧版 JupyterHub 使用两种令牌OAuth Token: 用户登录时由 Hub 签发给 single-user server。存储在浏览器 cookie 中用于在 OAuth 流程中标识拥有该服务器的用户。默认情况下cookie 到期默认 2 周JupyterHub 1.3.0 之前为 1 小时时该令牌随之过期。API Token: Hub 在启动 single-user server 时签发用于服务器与 Hub API 通信例如上报活动activity或完成 OAuth 流程。默认永不过期。此外API Token 还可以通过以下途径签发给用户与服务API 接口/hub/token令牌页面POST /users/:username/tokensREST API服务通过jupyterhub_config.py配置获得用于执行 API 请求。RBAC 之后统一令牌RBAC 框架通过附加在角色上的 scope授予令牌不同级别的权限。单独的 OAuth Token 所承担的仅用于身份识别这一用途不再需要——API Token 可以用于所有动作包括登录与认证此时使用一个不带角色即不含任何可用 scope的 API Token 即可。因此OAuth Token 在升级到 RBAC 框架的 Hub 中被正式移除。这也是升级过程中oauth_access_tokens表被直接删除、相关 cookie 需要重新登录的根本原因升级后所有用户都需要重新登录一次以在新体系下获得基于 API Token 的新会话。迁移的源码级验证与注意事项为便于读者在仓库中核对这里汇总本次升级相关的实现证据删除旧令牌表jupyterhub/alembic/versions/833da8570507_rbac.pyRBAC 基础迁移JupyterHub 2.0 引入直接drop_table(api_tokens)与drop_table(oauth_access_tokens)并注释说明了停止服务器、重新签发手动令牌两大前提。其downgrade()同样不可逆地删除api_tokens及相关角色映射表升级前务必做好数据库备份。重建令牌与 scope 结构jupyterhub/alembic/versions/651f5419b74d_api_token_scopes.py 为api_tokens增加scopes列、为oauth_clients增加allowed_scopes列并把旧的角色关系api_token_role_map、oauth_client_role_map折算为 scope 集合oauth_codes为短生命周期数据直接新增scopes列即可无需逐条迁移。默认角色分配jupyterhub/roles.py 的assign_default_roles()与 jupyterhub/roles.py 的get_default_roles()共同决定了升级后首次启动时各实体的默认角色行为。scope 体系scope 的语法约定read:、list:、admin:、access:、resource:subresource、!user等水平/垂直过滤与全部可用 scope 层级见 docs/source/rbac/scopes.mdtoken 请求与 API 请求时的权限解析流程见 docs/source/rbac/tech-implementation.md。给部署者的三点提醒备份优先由于downgrade()同样是破坏性的直接删除令牌表回滚也意味着令牌全部失效务必在升级前保留完整数据库备份。令牌清单化升级前把配置文件令牌与手动令牌分开清单管理。前者会自动重建、无需干预后者必须人工重发遗漏会导致外部集成CI、监控、自动脚本静默失效。分批启用 RBAC首次重启后保持配置不变确认 Hub 状态正常、所有实体获得默认角色后再在后续启动中逐步定义新角色并剥离不必要的 admin 权限以最小化风险。至此你的 JupyterHub 已升级至 RBAC 框架令牌体系统一、权限粒度可控、实体用户/服务/组均可通过角色获得精确的 scope 集合为最小权限原则下的精细化治理打下了基础。赞分享后端微服务【免费下载链接】jupyterhubMulti-user server for Jupyter notebooks项目地址https://gitcode.com/gh_mirrors/ju/jupyterhub点击查看免费下载相关推荐JupyterHub REST API 实战指南从 API Token 创建、权限 Scope 到分页请求与命名服务器编排JupyterHub REST API 实战指南从 API Token 创建、权限 Scope 到分页请求与命名服务器编排 本文基于 JupyterHub 官后端微服务RedwoodJS 基于角色的访问控制RBAC实战指南从身份验证到 Web/API 双端权限保护RedwoodJS 基于角色的访问控制RBAC实战指南从身份验证到 Web/API 双端权限保护 RBACRole based Access Contr后端前端Web框架开发工具Kubernetes RBAC 授权机制实战从 ABAC 迁移到基于角色的访问控制kubernetes-handbookKubernetes RBAC 授权机制实战从 ABAC 迁移到基于角色的访问控制kubernetes handbook 本指南以 Kubernetes教程云原生容器编排上一篇抖音批量下载神器一键获取创作者完整作品库的终极指南下一篇用 Rufus 免费免安装制作 Windows U 盘启动盘:全程半小时以内创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考