Users Should Use Work Email For Access

More Info:

User should have access via their official corporate email id and not their personal id.

Risk Level

Medium

Address

Reliability, Security

Compliance Standards

CIS GCP
CIS GCP 2.0.0
Cloudanix Best Practice
NIST CSF
PCI
SOC2

Triage and Remediation

Remediation

Remediation

Using Console

To remediate the misconfiguration "Users Should Use Work Email For Access" in GCP using GCP console, you can follow these steps:

Go to the GCP Console and select the project for which you need to remediate the misconfiguration.
Click on the "IAM & Admin" menu from the left-hand side navigation menu.
Click on the "IAM" tab to view the list of IAM roles and members.
Select the user for whom you want to remediate the misconfiguration.
Click on the "Edit" button next to the user's email address.
In the "Edit member" dialog box, scroll down to the "Role" section.
Click on the "Add Another Role" button to add a new role.
In the "Select a Role" dialog box, search for the "Organization Policy User" role and select it.
Click on the "Save" button to add the new role to the user.
Repeat the above steps for all the users who have access to the project.

By adding the "Organization Policy User" role to the users, you are enforcing the organization policy that requires users to use their work email for access. This will ensure that only authorized users with valid work emails can access the GCP resources.

Using CLI

To remediate the misconfiguration "Users Should Use Work Email For Access" in GCP using GCP CLI, you can follow the below steps:

Open the Cloud Shell in the GCP Console.
Run the following command to check if the G Suite domain is set for the organization:
```
gcloud organizations describe ORGANIZATION_ID
```
Replace ORGANIZATION_ID with your organization ID.
If the G Suite domain is not set for the organization, follow the instructions given in the following link to set up a G Suite domain:

https://cloud.google.com/resource-manager/docs/creating-managing-organization#setup_a_g_suite_domain
Once the G Suite domain is set up, run the following command to enable domain-restricted sharing:
```
gcloud beta identity organizational-settings domains update DOMAIN_NAME --allow-unrestricted-sharing=false --force
```
Replace DOMAIN_NAME with your G Suite domain name.

This command restricts sharing of GCP resources to only users with email addresses in the specified G Suite domain.
Run the following command to verify that the domain-restricted sharing is enabled:
```
gcloud beta identity organizational-settings domains describe DOMAIN_NAME
```
Replace DOMAIN_NAME with your G Suite domain name.

This command should return the following output:
```
allowUnrestrictedSharing: false
```
This confirms that the domain-restricted sharing is enabled.
Finally, you can check the users who have access to your GCP resources using the following command:
```
gcloud projects get-iam-policy PROJECT_ID
```
Replace PROJECT_ID with your GCP project ID.

This command lists all the users who have access to your GCP resources. Make sure that all the users have email addresses in the specified G Suite domain. If any user does not have an email address in the specified G Suite domain, remove their access to the GCP resources using the following command:
```
gcloud projects remove-iam-policy-binding PROJECT_ID --member=user:EMAIL_ADDRESS --role=ROLE
```
Replace PROJECT_ID with your GCP project ID, EMAIL_ADDRESS with the email address of the user, and ROLE with the role that the user has been assigned.

This command removes the user's access to the specified GCP resources.

Using Python

To remediate the misconfiguration "Users Should Use Work Email For Access" in GCP, we can use the following steps using Python:

First, we need to identify the users who are not using their work email for access to GCP. We can do this by using the google-auth and google-api-python-client libraries to authenticate and make API requests to the GCP Admin SDK.
Once we have identified the users, we can update their email addresses to their work email using the googleapiclient.discovery module. We can use the users().update() method to update the email address of the user.
We can also set up a notification system to alert users who are not using their work email for access to update their email address.

Here is a sample Python code to remediate the misconfiguration "Users Should Use Work Email For Access" in GCP:

from google.oauth2 import service_account
from googleapiclient.discovery import build

# Replace with the path to your service account key file
KEY_FILE_LOCATION = '/path/to/keyfile.json'

# Replace with your GCP project ID
PROJECT_ID = 'your-project-id'

# Replace with the domain of your organization
DOMAIN = 'your-domain.com'

# Authenticate using a service account key file
creds = service_account.Credentials.from_service_account_file(
    KEY_FILE_LOCATION,
    scopes=['https://www.googleapis.com/auth/admin.directory.user']
)

# Create the Admin SDK API client
service = build('admin', 'directory_v1', credentials=creds)

# Get a list of all users in the domain
users = service.users().list(domain=DOMAIN).execute()

# Loop through the users and update their email address if it is not their work email
for user in users['users']:
    if user['primaryEmail'].endswith('@gmail.com'):
        # Update the user's email address to their work email
        new_email = user['primaryEmail'].replace('@gmail.com', '@your-domain.com')
        service.users().update(userKey=user['id'], body={'primaryEmail': new_email}).execute()

        # Send a notification to the user to update their email address
        print(f"Updated email address for user {user['primaryEmail']}. Please update your email address to your work email.")

Note: This code assumes that all users in the domain have a work email address with the same domain as the organization. If this is not the case, you may need to modify the code to handle different email domains.

Using Terraform

This cannot be remediated directly in Terraform, because GCP IAM identities are external principals (Google accounts, Cloud Identity users, or workspace users); Terraform cannot change a user’s email address, only what principals are bound to which roles.

You can only:

Remove bindings that reference personal emails.
Add bindings that reference the correct corporate-domain identities (after they exist).

Example of tightening a binding to only allow your corporate domain:

resource "google_project_iam_binding" "project_editors_corporate_only" {
  project = "YOUR_PROJECT_ID"

  role    = "roles/editor"

  members = [
    # Replace with your corporate identities only
    "user:ALICE@YOUR_CORP_DOMAIN",
    "user:BOB@YOUR_CORP_DOMAIN",
    # "user:alice.personal@gmail.com", # <- remove any personal emails from here
  ]
}

To systematically enforce “work email only,” use an organization policy in the console (or Terraform) that restricts domains allowed as principals; the identity creation and email migration itself must be done outside Terraform (Cloud Identity / Google Workspace admin console).

Verification: terraform plan should show removal of bindings for personal-email principals and additions (if any) for corporate-domain principals, with no resource replacements, only IAM binding updates.

More Info:​

Risk Level​

Address​

Compliance Standards​

Triage and Remediation​

Remediation​