大数据批处理流处理数据工程【免费下载链接】beamApache Beam is a unified programming model for Batch and Streaming data processing.项目地址https://gitcode.com/gh_mirrors/beam4/beam点击查看免费下载本文以 Apache Beam 仓库中infra/iam目录的官方文档为核心完整讲解 Beam 项目如何用一个users.yml文件声明式管理 GCP 项目的用户与角色权限、如何通过 PR 与 GitHub Actions 自动应用变更以及beam_viewer beam_writer beam_infra_manager beam_admin四级自定义角色是如何由roles_config.yaml生成并经 Terraform 下发的。读完本文你将能够在 Beam 风格的基础设施中为用户申请/变更权限含过期时间条件、理解自定义角色的生成原理、并掌握从遗留 GCP 角色迁移到 Beam 自定义角色的完整流程。概述infra/iam目录承担 Beam 项目 GCP 基础设施的权限管理Infrastructure Permissions Management。它的核心思路是声明式 自动化所有谁拥有什么角色的意图集中写在一个 YAML 文件 users.yml 中修改该文件并提交 Pull Request 后GitHub Actions 工作流自动触发用 Terraform 将变更应用到 GCP 项目的 IAM 策略权限本身不直接使用 GCP 预定义角色随意堆砌而是收敛到 Beam 自建的四级自定义角色体系上。该模块管理的 GCP 项目由 config.auto.tfvars 声明# GCP Project ID project_id apache-beam-testing管理用户角色users.yml 声明格式管理用户角色的入口是编辑users.yml文件。在users部分添加或修改条目为每个用户设置期望的角色。文档规定的 YAML 结构如下users: - username: username email: email member_type: user|serviceAccount|group permissions: - role: role title: title (optional) description: description (optional) expiry_date: expiry_date (optional, format: YYYY-MM-DD) - role: role (optional, for multiple roles)字段要点字段必填说明username是用户/服务账号的标识名email是邮箱作为 IAM member 的主体member_type是取值user、serviceAccount、group决定 member 前缀role是IAM 角色可用 GCP 预定义角色也可用projects/PROJECT-ID/roles/beam_*形式的自定义角色title/description否用于生成 IAM 条件condition的标题与描述expiry_date否格式YYYY-MM-DD为授权设置过期时间注意原文档明确说明role/owner角色被单独处理写入users.yml的 owner 条目会被忽略。仓库中 users.yml 的真实条目印证了这些形态例如普通用户与多个角色的写法- username: abbymotley email: abbymotleygoogle.com member_type: user permissions: - role: roles/viewer服务账号member_type: serviceAccount邮箱形如nameproject.iam.gserviceaccount.com同样在此文件统一管理例如adudko-runner-gke-sa被授予roles/container.admin、roles/iam.serviceAccountTokenCreator等。源码级解析users.tf 如何消费这份声明Terraform 侧的处理逻辑集中在 users.tf值得逐点对照读取声明locals.users yamldecode(file(${path.module}/users.yml))直接把 YAML 解码进 TerraformPROJECT-ID 占位符替换users.tfrole replace(perm.role, PROJECT-ID, var.project_id)这解释了users.yml中为什么可以写projects/PROJECT-ID/roles/beam_admin这类占位写法——应用时会被替换为config.auto.tfvars中的apache-beam-testingowner 角色被排除users.tf过滤条件perm.role ! roles/owner与文档中owner 被单独处理、写入会被忽略的说明完全对应源码注释解释了原因——owner 授权需要用户本人接受accept过期时间变成 IAM 条件users.tf仅当expiry_date非空时才为google_project_iam_member资源动态生成一个condition块其表达式为request.time timestamp(expiry_dateT00:00:00Z)即把到期自动失效落到 GCP 的条件式 IAMConditional IAM机制上而不是依赖人工回收幂等键for_each以${email}-${role}作为资源键保证同一主体同一角色只产生一个 IAM 成员资源。应用变更PR GitHub Actions Terraform 的闭环文档规定的变更流程是修改users.yml对infra/iam目录开一个 Pull Request经评审后合并进主干PR 合并后GitHub Actions 工作流自动触发使用 Terraform 把变更应用到 GCP 项目的 IAM 策略。在仓库中承担这一职责的工作流是 beam_Infrastructure_UsersPermissions.ymlREADME 中旧链接指向的beam_UserRoles.yml在现行仓库中已更名为该文件。从工作流定义可见其触发与执行细节触发条件workflow_dispatch手动以及pull_request_target且路径命中infra/iam/users.ymlopened/synchronize/reopened/closed运行环境self-hosted, ubuntu-24.04runner超时 30 分钟执行步骤checkout→ 安装 gcloud → 安装 Terraform1.12.2→ 在./infra/iam下执行terraform init等后续 apply 步骤。Terraform 工程基础main.tf锁定hashicorp/googleprovider 为6.37.0state 后端为 GCS bucketbeam-terraform-infra-state前缀terraform/state并声明module beam_roles指向./roles目录把自定义角色管理纳入同一次 Terraform 执行config.auto.tfvars提供project_id apache-beam-testingusers.tf如上所述把users.yml展开为google_project_iam_member资源集合。自定义角色体系四级继承的 beam_* 角色Beam 项目用自定义 IAM 角色Custom IAM Roles对 GCP 资源做细粒度权限控制。角色之间呈层级结构高层级角色继承低层级的权限beam_viewer beam_writer beam_infra_manager beam_admin角色清单与适用场景beam_viewer定位对 Beam 项目资源的只读访问权限对 Beam 使用的所有服务的 view-only 权限排除Secret 管理权限、破坏性操作场景需要监控和观察项目资源的团队成员。beam_writer定位对 Beam 项目资源的使用者级访问权限继承全部beam_viewer权限另加BigQuery 数据访问与查询、Cloud SQL 实例使用、容器集群查看与开发、Datastore 使用、网络查看排除破坏性操作、管理类操作场景需要与项目资源打交道的活跃贡献者。beam_infra_manager定位对 Beam 项目基础设施的 Editor 级访问权限继承全部beam_writer权限另加Cloud Build 编辑器权限、服务账号 token 创建与使用、存储对象创建与查看、通用 editor 角色含排除项排除破坏性权限、完全管理权限场景负责部署与资源管理的基础设施维护者。beam_admin定位对 Beam 项目的完全管理访问权限包含此前所有角色的权限并对全部服务拥有管理权限、Secret 管理能力、破坏性操作能力排除无场景项目管理员与资深维护者。角色如何定义roles_config.yaml自定义角色由 roles/ 目录下的配置文件管理roles_config.yaml定义角色、层级、服务清单与基础角色generate_roles.py根据配置生成角色 YAML 定义文件roles.tfTerraform 配置把自定义角色应用到 GCP 项目。roles_config.yaml 中每个角色的定义由五部分组成name/hierarchy角色名与层级编号数值越大权限越高高层级自动累积低层级的services与rolesservices该角色可访问的服务前缀清单。例如viewer覆盖 artifactregistry、bigquery、cloudbuild、container、dataflow、pubsub、storage、spanner 等 28 个服务writer再叠加 cloudkms、dataform、dataplexadmin再叠加 secretmanagerroles该角色继承权限的来源基础角色。例如writer继承roles/bigquery.user、roles/cloudsql.instanceUser、roles/container.developer、roles/datastore.user等正好对应上文 beam_writer 的权限描述infra_manager则继承roles/cloudbuild.builds.editor、roles/iam.serviceAccountTokenCreator、roles/storage.objectCreator与roles/editor等except_suffixes要剔除的权限后缀组。viewer/writer/infra_manager都排除了destructive组而admin的except_suffixes为空——谁能删、谁能改配置就在这一行拉开差距。destructive后缀组在文件末尾统一定义共 7 个后缀suffixes: - name: destructive values: - .delete - .remove - .destroy - .purge - .cancel - .stop - .terminate生成机制generate_roles.py 的源码实现generate_roles.py 的生成管线可以从源码结构上概括为四步解析配置get_config按hierarchy升序排序角色并逐级累积services与roles集合实现高层级继承低层级的语义拉取基础角色的真实权限get_role_permissions通过iam_admin_v1.IAMClient的GetRoleRequest获取每个基础角色的included_permissions再调用QueryTestablePermissionsRequest查询每个权限的custom_roles_support_level只保留SUPPORTED即 GA 阶段的权限避免把 beta 权限固化进自定义角色双重过滤filter_permissions权限名必须以该角色services中某个服务前缀开头allowed_prefixes且不得以except_suffixes中任何后缀结尾。以viewer为例roles/viewer的权限先被裁剪到 28 个服务的命名空间内再剔除所有.delete、.stop等破坏性权限去重与落盘get_roles按层级处理时从当前角色中扣除低层级已分配的权限permissions_added集合保证四个角色文件之间权限无重叠、可独立叠加最后写出role.role.yaml内容形如role_id、title、stage: GA与排序后的permissions列表见 beam_viewer.role.yaml如artifactregistry.attachments.get等条目文件头部标注 auto-generated禁止手改。生成结果由 roles.tf 消费fileset(path.module, *.role.yaml)扫描目录下所有角色定义文件逐个创建google_project_iam_custom_role资源role_id、title、description、permissions、stage均来自 YAML。修改自定义角色的标准流程文档给出的三步流程为编辑roles_config.yaml更新角色定义运行generate_roles.py重新生成角色 YAML 文件通过 Terraform 或 Pull Request 应用变更。结合 roles/README.md 的补充说明实操命令为# 安装依赖对应 infra/iam/requirements.txtPyYAML、google-cloud、google-cloud-iam 等 pip install -r requirements.txt # 本地重新生成角色 YAML 文件 python3 generate_roles.py生成脚本只负责产出本地文件。之后若要应用到 GCP 项目需要拥有该项目的 owner 权限并在infra/iam目录执行terraform plan terraform apply从遗留角色迁移到自定义角色migrate_roles.py 脚本用于把 GCP 项目现有的 IAM 策略迁移到 Beam 自定义角色结构适用于从标准 GCP 角色过渡到自定义角色的场景。迁移规则脚本按层级顺序应用以下规则高层级命中后其包含的低层级一并生效Owner 角色保持不变最高权限Admin/Secret 类角色迁移到beam_admin包含其下所有角色Editor 角色迁移到beam_infra_manager包含 writer 与 viewerUser 类角色迁移到beam_writer包含 viewerViewer 角色迁移到beam_viewer。源码中的 migrate_permissions 印证了这一层级化判定roles/owner命中后仅保留 owner 并移除其他冗余角色角色名包含admin或secretmanager不区分大小写时升级为beam_admin精确等于roles/editor时落到beam_infra_manager其余非 viewer 角色落到 committer 级脚本输出中该级写作历史命名beam_committer与文档描述的 writer 层级对应仅有 viewer 者落到beam_viewer。非 owner 的迁移结果统一写成projects/PROJECT-ID/roles/beam_*占位形式恰好复用 users.tf 中replace(perm.role, PROJECT-ID, var.project_id)的占位符替换机制。使用迁移脚本前提条件已安装并认证 Google Cloud SDK已安装 Python 依赖pip install -r requirements.txt见 requirements.txtPyYAML、google-cloud、google-cloud-iam、google-cloud-resource-manager拥有读取 IAM 策略的 GCP 权限。导出并生成迁移方案python migrate_roles.py PROJECT_ID生成两个文件PROJECT_ID.original-roles.yaml当前 IAM 策略导出PROJECT_ID.migrated-roles.yaml迁移到自定义角色的提案。分析某个用户的权限差异python migrate_roles.py PROJECT_ID --difference USER_EMAIL生成PROJECT_ID.permission-differences.yaml迁移前后权限的详细对比。示例工作流# 导出当前 IAM 策略并生成迁移方案 python migrate_roles.py apache-beam-testing # 检查特定用户的权限差异 python migrate_roles.py apache-beam-testing --difference userexample.com # 审阅生成的文件后再应用变更 # 随后通过 Terraform 或手动更新 IAM 策略该脚本通过先导出对比、再统一应用的方式帮助团队在保持各用户访问水平的前提下平稳过渡到自定义角色体系。目录结构速查文件作用main.tfTerraform 主配置provider 版本、GCS state 后端、beam_roles模块引用config.auto.tfvars声明project_id等全局变量users.tf解析users.yml生成google_project_iam_member含条件式过期users.yml用户/服务账号/群组与角色的声明式清单migrate_roles.py遗留 IAM 策略导出与自定义角色迁移requirements.txtPython 依赖PyYAML、google-cloud-iam 等roles/roles_config.yaml角色层级、服务清单、基础角色与排除后缀定义roles/generate_roles.py从配置生成角色 YAML 定义roles/roles.tf创建google_project_iam_custom_role资源roles/beam_viewer.role.yaml、beam_writer.role.yaml、beam_infra_manager.role.yaml、beam_admin.role.yaml四级角色生成产物自动生成勿手改roles/README.md自定义角色的详细说明文档适用前提与限制以上流程面向 Beam 项目自身的apache-beam-testingGCP 项目与自托管 CI runner角色定义依赖 GCP IAM Admin API 可查询到对应权限其他团队若借鉴此模式需将config.auto.tfvars中的项目 ID、state bucket 与触发路径替换为自己的环境并保证 CI 服务账号具备google_project_iam_member与自定义角色的写权限。赞分享大数据批处理流处理数据工程【免费下载链接】beamApache Beam is a unified programming model for Batch and Streaming data processing.项目地址https://gitcode.com/gh_mirrors/beam4/beam点击查看免费下载相关推荐测试报告SteamOS-Waydroid-Installer支持的30热门Android游戏性能实测测试报告SteamOS Waydroid Installer支持的30热门Android游戏性能实测 SteamOS Waydroid Installer是Apache Beam 基础设施合规强制模块IAM 策略与服务账号密钥漂移检测实战Apache Beam 基础设施合规强制模块IAM 策略与服务账号密钥漂移检测实战 infra/enforcement 是 Apache Beam 仓库中用于大数据批处理流处理数据工程Azure权限管理深度解析从基础角色到自定义权限设计Azure权限管理深度解析从基础角色到自定义权限设计 一、Azure角色分配机制解析 在Azure云环境中角色分配是实现资源访问控制的核心机制。通过角色分配上一篇Platinum-MD实战指南免费实现NetMD设备现代化音乐传输革命下一篇CANN 样例实战基于 CANNSim 的 VF 性能分析指南cann-samples创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考