PastaInc logo
Pasta Inc
web development

Moving IAM Permissions Between GCP Projects

Moving IAM Permissions Between GCP Projects
0 views
4 min read
#web development

Overview

Google Cloud Platform (GCP) offers powerful tools for managing Identity and Access Management (IAM) permissions across projects. This guide explores how to efficiently transfer IAM configurations between GCP projects using the Command Line Interface (CLI), covering export options in YAML and JSON formats, and providing step-by-step instructions for moving and verifying permissions.

Prerequisites for IAM Transfer

Before initiating the IAM permission transfer process, ensure you have the Google Cloud SDK installed and properly initialized on your local machine. For more information on how to set this up, please see my blog post entitled, "How to Set Up the Google Cloud SDK Locally and Authenticate via IAM"! You must also possess sufficient permissions to manage IAM policies in both the source and destination projects. It's crucial to have the necessary roles, such as "Security Admin" (roles/iam.securityAdmin), to execute get-iam-policy and set-iam-policy commands effectively. Familiarize yourself with the project IDs of both the source and destination projects, as these will be required throughout the transfer process.

Authenticating with Google Cloud CLI

To authenticate with Google Cloud Platform (GCP) using the command line interface (CLI), the primary method is the gcloud auth login command. This command initiates an interactive process that allows users to authorize gcloud to access Cloud Platform resources with their Google user credentials. For machines without a browser, the --no-browser flag can be used:

gcloud auth login --no-browser

This generates a URL that can be opened on a different machine with a browser to complete the authentication process. For non-interactive scenarios or automated scripts, service account authentication is recommended. This involves creating a service account, downloading its JSON key file, and using the command. For more detailed instructions on the best practices around JSON keys, please see my blog post entitled, "Best Practices for Using Service Account JSON Keys for IAM Authentication in GCP"!

gcloud auth activate-service-account --key-file=PATH_TO_KEY_FILE

This method securely authenticates without requiring user interaction. Please be aware that there are security risks around this method if JSON keys are not managed properly. See my blog post for more details so you can be aware and mitigate risks.

gcloud auth login

is primarily for CLI authentication, while

gcloud auth application-default login

is used for generating credentials for client libraries in local development environments.

Method 1: Export IAM Policies

Please skip to Method 2 if your intention is to Copy Permissions between GCP Projects! - Please only follow this section if you know this is what you need to do!

Exporting IAM Policies

To export IAM policies from a source project, use the gcloud projects get-iam-policy command with the desired format option. For YAML format, execute:

gcloud projects get-iam-policy SOURCE_PROJECT_ID --format=yaml source_iam_policy.yaml

Alternatively, for JSON format, run:

gcloud projects get-iam-policy SOURCE_PROJECT_ID \--format=json source_iam_policy.json

Replace "SOURCE_PROJECT_ID" with the appropriate project identifier. These commands save the IAM policy to a file, allowing for easy review and modification before applying to the destination project.

Applying and Verifying Policies

To apply the exported IAM policy to the destination project, use the

gcloud projects set-iam-policy

command, specifying the correct file format:

gcloud projects set-iam-policy DESTINATION_PROJECT_ID source_iam_policy.yaml

or

gcloud projects set-iam-policy DESTINATION_PROJECT_ID source_iam_policy.json

After application, verify the transferred permissions by running:

gcloud projects get-iam-policy DESTINATION_PROJECT_ID

This step ensures that all intended permissions have been correctly applied to the destination project. It's crucial to review the output carefully, comparing it with the original policy to confirm the successful transfer of IAM configurations.

Image

Best Practices: Please just copy your roles!

When transferring IAM permissions between projects, consider using the

gcloud iam roles copy

command to replicate custom roles. For selective permission transfer, utilize

gcloud projects add-iam-policy-binding

for individual roles or permissions. Exercise caution with service account-related permissions, as they are project-specific and may require creating equivalent accounts in the destination project. Adhere to the principle of least privilege and conduct regular audits of IAM policies to maintain robust security. After transferring permissions, thoroughly test access rights to ensure correct application and prevent unintended privilege escalation.

Copying IAM Roles Between GCP Projects or Organizations

The

gcloud iam roles copy

command is a powerful tool for replicating IAM roles across Google Cloud Platform projects or organizations. This command allows users to create a new role based on an existing one, facilitating the transfer of permissions between environments. To copy a role, use the following syntax:

gcloud iam roles copy --source="SOURCE_ROLE_ID" --destination=DESTINATION_ROLE_ID --dest-project=DESTINATION_PROJECT_ID

For example, to copy the "spanner.databaseAdmin" role to a custom role in a different project:

gcloud iam roles copy --source="roles/spanner.databaseAdmin" --destination=CustomSpannerDbAdmin --dest-project=PROJECT_ID

When copying roles between organizations, use the

--dest-organization

flag instead of

--dest-project

It's important to note that copying roles does not automatically grant permissions; you'll need to assign the newly created role to users or service accounts separately for that project. After copying, you can modify the new role using the gcloud iam roles update command to tailor it to your specific needs (or for the needs of that specific project).

Resources