<!--
    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.