| <!-- |
| Licensed to the Apache Software Foundation (ASF) under one |
| or more contributor license agreements. See the NOTICE file |
| distributed with this work for additional information |
| regarding copyright ownership. The ASF licenses this file |
| to you under the Apache License, Version 2.0 (the |
| "License"); you may not use this file except in compliance |
| with the License. You may obtain a copy of the License at |
| |
| http://www.apache.org/licenses/LICENSE-2.0 |
| |
| Unless required by applicable law or agreed to in writing, |
| software distributed under the License is distributed on an |
| "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY |
| KIND, either express or implied. See the License for the |
| specific language governing permissions and limitations |
| under the License. |
| --> |
| |
| # Infrastructure Permissions Management |
| |
| This document outlines the structure of the Beam project control of infrastructure permissions and |
| provides instructions on how to manage a user or role's permissions. |
| |
| ## Overview |
| |
| ### Managing User Roles |
| |
| To manage user roles, edit the `users.yml` file. Add or modify entries under the `users` section to |
| reflect the desired roles for each user. Remember to follow the YAML format: |
| |
| ```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) |
| ``` |
| |
| > **Note**: `role/owner` roles are handled separately, adding them to the `users.yml` file will be ignored. |
| |
| ### Applying Changes |
| |
| After modifying the `users.yml` file, open a Pull Request (PR) to the `infra/iam` directory. |
| The changes will be reviewed and when approved, they will be merged into the main branch. |
| |
| Once the PR is merged, [the GitHub Actions workflow](../../.github/workflows/beam_UserRoles.yml) |
| will automatically trigger and apply the changes to the IAM policies in the GCP project using Terraform. |
| |
| This will update the IAM policies in the GCP project based on the changes made in the `users.yml` file. |
| |
| ## Directory Structure |
| |
| ### Terraform Configuration |
| |
| - **main.tf**: The main Terraform configuration file that defines the infrastructure resources and their permissions. |
| - **config.auto.tfvars**: Contains the configuration variables for the Terraform project. |
| - **users.tf**: Processes the `users.yml` file to associate users with their respective roles. |
| - **users.yml**: A YAML file that contains the IAM policies and permissions for users and roles in the Beam project. |
| |
| ### Migration and Automation |
| |
| - **migrate_roles.py**: Python script for migrating existing IAM policies to the new custom roles structure |
| |
| ## Custom Roles |
| |
| The Beam project uses custom IAM roles to provide granular permissions for different levels of access to GCP resources. These roles follow a hierarchical structure where higher-level roles inherit permissions from lower-level roles. |
| |
| ### Role Hierarchy |
| |
| The custom roles are structured in the following hierarchy: |
| |
| ``` |
| beam_viewer < beam_writer < beam_infra_manager < beam_admin |
| ``` |
| |
| ### Available Roles |
| |
| #### beam_viewer |
| - **Description**: Read-only access to the Beam project resources |
| - **Permissions**: View-only access to all services used by Beam |
| - **Exclusions**: Secret management permissions, destructive actions |
| - **Use case**: For team members who need to monitor and observe project resources |
| |
| #### beam_writer |
| - **Description**: User access to resources in the Beam project |
| - **Permissions**: Inherits all `beam_viewer` permissions plus additional permissions for: |
| - BigQuery data access and querying |
| - Cloud SQL instance usage |
| - Container cluster viewing and development |
| - Datastore usage |
| - Network viewing |
| - **Exclusions**: Destructive actions, administrative operations |
| - **Use case**: For active contributors who need to work with project resources |
| |
| #### beam_infra_manager |
| - **Description**: Editor access to the Beam project infrastructure |
| - **Permissions**: Inherits all `beam_writer` permissions plus: |
| - Cloud Build editor access |
| - Service account token creation and usage |
| - Storage object creation and viewing |
| - General editor role (with exclusions) |
| - **Exclusions**: Destructive permissions, full administrative access |
| - **Use case**: For infrastructure maintainers who manage deployments and resources |
| |
| #### beam_admin |
| - **Description**: Full administrative access to the Beam project |
| - **Permissions**: Complete access including: |
| - All previous role permissions |
| - Administrative access to all services |
| - Secret management capabilities |
| - Destructive operations |
| - **Exclusions**: None |
| - **Use case**: For project administrators and senior maintainers |
| |
| ### Managing Custom Roles |
| |
| Custom roles are defined and managed through configuration files in the `roles/` directory: |
| |
| - **roles_config.yaml**: Defines the roles, their hierarchy, services, and base permissions |
| - **generate_roles.py**: Python script that generates YAML role definitions from the configuration |
| - **roles.tf**: Terraform configuration that applies the custom roles to the GCP project |
| |
| To modify custom roles: |
| |
| 1. Edit the `roles_config.yaml` file to update role definitions |
| 2. Run `generate_roles.py` to regenerate the role YAML files |
| 3. Apply changes through Terraform or via pull request |
| |
| For detailed information about custom roles management, see the [roles directory README](roles/README.md). |
| |
| ### Migrating from Legacy Roles |
| |
| The `migrate_roles.py` script helps migrate existing GCP project IAM policies to the new custom roles structure. This is useful when transitioning from standard GCP roles to the custom Beam roles. |
| |
| #### Migration Rules |
| |
| The script applies the following hierarchical migration rules: |
| |
| - **Owner roles**: Left unchanged (highest privilege) |
| - **Admin/Secret roles**: Migrated to `beam_admin` (includes all lower roles) |
| - **Editor roles**: Migrated to `beam_infra_manager` (includes writer and viewer) |
| - **User roles**: Migrated to `beam_writer` (includes viewer) |
| - **Viewer roles**: Migrated to `beam_viewer` |
| |
| #### Using the Migration Script |
| |
| **Prerequisites:** |
| - Google Cloud SDK installed and authenticated |
| - Required Python dependencies (install with `pip install -r requirements.txt`) |
| - Appropriate GCP permissions to read IAM policies |
| |
| **Export and migrate IAM policies:** |
| ```bash |
| python migrate_roles.py <PROJECT_ID> |
| ``` |
| |
| This generates two files: |
| - `<PROJECT_ID>.original-roles.yaml`: Current IAM policy export |
| - `<PROJECT_ID>.migrated-roles.yaml`: Proposed migration to custom roles |
| |
| **Analyze permission differences for a specific user:** |
| ```bash |
| python migrate_roles.py <PROJECT_ID> --difference <USER_EMAIL> |
| ``` |
| |
| This generates: |
| - `<PROJECT_ID>.permission-differences.yaml`: Detailed comparison of permissions before and after migration |
| |
| **Example workflow:** |
| ```bash |
| # Export current IAM policies and generate migration |
| python migrate_roles.py apache-beam-testing |
| |
| # Check permission differences for a specific user |
| python migrate_roles.py apache-beam-testing --difference user@example.com |
| |
| # Review the generated files before applying changes |
| # Then apply via Terraform or manual IAM policy updates |
| ``` |
| |
| The migration script helps ensure a smooth transition to the custom roles while maintaining appropriate access levels for all users. |