Add an environment

JIT Groups lets you configure one or more environments. Environments correspond to segments of your Google Cloud organizational hierarchy, and you can use environments to delegate the management of these resources to different teams or business units.

For each environment, JIT Access maintains:

A policy document that defines the groups for this environment.
A Secret Manger secret that contains the policy document.
A service account that's used to provision IAM bindings for resources in this environment.

If you're planning to use a single environment, it's best to create the secret and service account in the project that contains the JIT Groups application. If you're planning to use multiple environments, and delegate the administration of these environments to different teams, then it's best to create a dedicated project for each environment and create the secret and service account there.

Register the environment

The steps to register an environment differ depending on whether you're using the project that contains the JIT Groups application or a separate project:

Same project

Copy the example policy document to a file environment.yaml:

cp target/sources/src/main/resources/oobe/policy.yaml environment.yaml

Open your existing Terraform configuration and add the following:

module "application" {
    ...
    environments                = [ # List of environments, identified by service account
        "serviceAccount:${module.environment.service_account}"
    ]
    ...
}

module "environment" {
    source                      = "./target/terraform/jitgroups-environment"
    project_id                  = local.project_id
    application_service_account = module.application.service_account

    name                        = "NAME"
    policy                      = file("environment.yaml")
}

output "environment"  {
    value                       = module.environment.service_account
}

output "url" {
    value                       = module.application.url
}

output "service_account" {
    value                       = module.application.service_account
}

Replace NAME with the name of the environment.

The application uses the environment name as unique identifier and incorporates it into the name of Cloud Identity groups. Names must therefore comply with the following restrictions:

Names are case-insensitive. You can't have two environments whose names only differ in casing.
Names must be no longer than 16 characters.
Names must only use the following characters: A-Z, a-z, 0-9, -.

The name can't be changed later.

Note

To add multiple environments, duplicate the highlighted section and assign unique names to the modules and outputs.

Authorize terraform:
```
gcloud auth application-default login
```
Reinitialize Terraform and apply the configuration change:
```
terraform init 
terraform apply 
```
Open a browser and navigate to the URL that you obtained after running terraform apply.
Open the environment selector and select your environment.

Grant access to resources

As a result of applying the Terraform configuration change, your project now contains an additional service account, jit.NAME@PROJECT.iam.gserviceaccount.com where NAME is the name of the environment and PROJECT is the project ID.

You must grant this service account permission to modify IAM policies of the resources that the environment corresponds to. Because this step might require privileged access to these resources, it's not performed automatically by Terraform.

For example, if the environment corresponds to the development folder of your Google Cloud organization, then you must grant the service account permission to modify the IAM policy of that folder.

ProjectFolderOrganization

If the environment corresponds to a single project, do the following:

RESOURCE_ID=PROJECT_ID
ENVIRONMENT_SERVICE_ACCOUNT=$(terraform output -raw environment)

gcloud projects add-iam-policy-binding $RESOURCE_ID \
  --member "serviceAccount:$ENVIRONMENT_SERVICE_ACCOUNT" \
  --role "roles/resourcemanager.projectIamAdmin" \
  --format "value(etag)" \
  --condition None

Replace PROJECT_ID with the project ID that that you want to grant access to.

If the environment corresponds to a folder, do the following:

RESOURCE_ID=FOLDER_ID
ENVIRONMENT_SERVICE_ACCOUNT=$(terraform output -raw environment)

gcloud resource-manager folders add-iam-policy-binding $RESOURCE_ID \
  --member "serviceAccount:$ENVIRONMENT_SERVICE_ACCOUNT" \
  --role "roles/resourcemanager.projectIamAdmin" \
  --format "value(etag)" \
  --condition None

Replace FOLDER_ID with the folder ID that that you want to grant access to.

If the environment corresponds to the entire organization, do the following:

RESOURCE_ID=ORG_ID
ENVIRONMENT_SERVICE_ACCOUNT=$(terraform output -raw environment)

gcloud resource-manager folders add-iam-policy-binding $RESOURCE_ID \
  --member "serviceAccount:$ENVIRONMENT_SERVICE_ACCOUNT" \
  --role "roles/resourcemanager.projectIamAdmin" \
  --format "value(etag)" \
  --condition None

Replace ORG_ID with the organization ID that that you want to grant access to.

Grant access to the VPC Service Controls perimeter

If you're using the environment to manage access to projects that are part of a VPC Service Controls perimeter, then you must create an ingress rule that permits JIT Groups to access the perimeter:

In the Cloud Console, go to VPC Service Controls and open the service perimeter.
Click Edit perimeter.
Select Ingress Policy.
Click Add rule and configure the following settings:
- Source: All sources
- Identity: the email address of the environment's service account (jit.NAME@PROJECT.iam.gserviceaccount.com)
- Project: the project to manage access for, or All projects
- Services: Google Cloud Resource Manager API
Click Save

Customize the policy

To customize the policy document of your environment, do the following:

In the web interface, click View policy.
Use the YAML editor to modify the policy. For details about the syntax, see policy documents.
Click Validate to let JIT Groups check the YAML syntax, CEL expressions, and other configuration details.

Note

JIT Groups doesn't have permission to modify the Secret Manager secret and therefore doesn't let you save or apply the policy changes in the web interface.

To save and apply your policy changes, do the following:

Copy the updated YAML code to the environment.yaml file.
Run Terraform to apply the configuration:
```
terraform apply 
```

What's next

Set up continuous deployment Customize your policy document