Product documentation
Citrix Virtual Apps and Desktops
Service Current Release 2402 LTSR 2311 2308 2305 2303 2212 2209 2206 2203 LTSR 1912 LTSR
View PDF

Google Cloud environments

April 4, 2024
Contributed by: 
C L

Citrix Virtual Apps and Desktops lets you provision and manage machines on Google Cloud. This article walks you through using Machine Creation Services (MCS) to provision virtual machines in your Citrix Virtual Apps or Citrix Virtual Desktops service deployment.

Requirements

  • Citrix Cloud account. The feature described in this article is available only in Citrix Cloud.
  • Citrix DaaS subscription. For details, see Get started.
  • A Google Cloud project. The project stores all compute resources associated with the machine catalog. It can be an existing project or a new one.
  • Enable four APIs in your Google Cloud project. For details, see Enable Google Cloud APIs.
  • Google Cloud service account. The service account authenticates to Google Cloud to enable access to the project. For details, see Configure and update service accounts.
  • Enable Google private access. For details, see Enable-private-google-access.

Enable Google Cloud APIs

To use the Google Cloud functionality through the Citrix Virtual Apps and Desktops Full Configuration interface, enable these APIs in your Google Cloud project:

  • Compute Engine API
  • Cloud Resource Manager API
  • Identity and Access Management (IAM) API
  • Cloud Build API
  • Cloud Key Management Service (KMS)

From the Google Cloud console, complete these steps:

  1. In the upper left menu, select APIs and Services > Dashboard.

    APIs and Services Dashboard select image

  2. On the Dashboard screen, ensure that Compute Engine API is enabled. If not, follow these steps:

    1. Navigate to APIs and Services > Library.

      APIs and Services Library image

    2. In the search box, type Compute Engine.

    3. From the search results, select Compute Engine API.

    4. On the Compute Engine API page, select Enable.

  3. Enable Cloud Resource Manager API.

    1. Navigate to APIs and Services > Library.

    2. In the search box, type Cloud Resource Manager.

    3. From the search results, select Cloud Resource Manager API.

    4. On the Cloud Resource Manager API page, select Enable. The status of the API appears.

  4. Similarly, enable Identity and Access Management (IAM) API and Cloud Build API.

You can also use Google Cloud Shell to enable the APIs. To do this:

  1. Open the Google Console and load the Cloud Shell.

  2. Run the following four commands in the Cloud Shell:

    • gcloud services enable compute.googleapis.com
    • gcloud services enable cloudresourcemanager.googleapis.com
    • gcloud services enable iam.googleapis.com
    • gcloud services enable cloudbuild.googleapis.com
  3. Click Authorize if the Cloud Shell prompts.

Configure and update service accounts

Note:

GCP is introducing changes to Cloud Build Service’s default behavior and use of service accounts after April 29, 2024. For more information, see Cloud Build Service Account Change. Your existing Google projects with Cloud Build API enabled before April 29, 2024 are not affected by this change. However, if you want to have existing Cloud Build Service behavior after April 29, you can create or apply the organization policy to disable the constraint enforcement before you enable the Cloud Build API. As a result, the following content is divided into two: Before April 29, 2024 and After April 29, 2024. If you set the new organization policy, follow the section Before April 29, 2024.

Before April 29, 2024

Citrix Cloud uses three separate service accounts within the Google Cloud project:

  • Citrix Cloud Service Account: This service account enables Citrix Cloud to access the Google project, provision, and manage machines. This service account authenticates to Google Cloud using a key generated by Google Cloud.

    You must create this service account manually as outlined here. For more information, see Create a Citrix Cloud Service Account.

    You can identify this service account with an email address. For example, <my-service-account>@<project-id>.iam.gserviceaccount.com.

  • Cloud Build Service Account: This service account is provisioned automatically after you enable all the APIs mentioned in Enable Google Cloud APIs. To view all automatically created service accounts, navigate to IAM & Admin > IAM in the Google Cloud console and select the Include Google-provided role grants checkbox.

    You can identify this service account by an email address that begins with the Project ID and the word cloudbuild. For example, <project-id>@cloudbuild.gserviceaccount.com

    Verify if the service account has been granted the following roles. If you must add roles, follow the steps outlined in Add roles to the Cloud Build Service Account.

    • Cloud Build Service Account
    • Compute Instance Admin
    • Service Account User

  • Cloud Compute Service Account: This service account is added by Google Cloud to instances created in Google Cloud once the Compute API is activated. This account has the IAM basic editor role to do the operations. However, if you delete the default permission to have more granular control, you must add a Storage Admin role that requires the following permissions:

    • resourcemanager.projects.get
    • storage.objects.create
    • storage.objects.get
    • storage.objects.list

You can identify this service account by an email address that begins with the Project ID and the word compute. For example, <project-id>-compute@developer.gserviceaccount.com.

Create a Citrix Cloud Service Account

To create a Citrix Cloud Service Account, follow these steps:

  1. In the Google Cloud console, navigate to IAM & Admin > Service accounts.
  2. On the Service accounts page, select CREATE SERVICE ACCOUNT.
  3. On the Create service account page, enter the required information, and then select CREATE AND CONTINUE.

  4. On the Grant this service account access to project page, click the Select a role drop-down menu and select the required roles. Click +ADD ANOTHER ROLE if you want to add more roles.

    Each account (personal or service) has various roles defining the management of the project. Grant the following roles to this service account:

    • Compute Admin
    • Storage Admin
    • Cloud Build Editor
    • Service Account User
    • Cloud Datastore User
    • Cloud KMS Crypto Operator

    The Cloud KMS Crypto Operator requires the following permissions:

    • cloudkms.cryptoKeys.get
    • cloudkms.cryptoKeys.list
    • cloudkms.keyRings.get
    • cloudkms.keyRings.list

    Note:

    Enable all the APIs to get the complete list of roles available while creating a new service account.

  5. Click CONTINUE
  6. On the Grant users access to this service account page, add users or groups to grant them access to perform actions in this service account.
  7. Click DONE.
  8. Navigate to the IAM main console.
  9. Identify the service account created.
  10. Validate the roles are assigned successfully.

Considerations:

When creating the service account, consider the following:

  • The steps Grant this service account access to project and Grant users access to this service account are optional. If you choose to skip these optional configuration steps, the newly created service account does not display in the IAM & Admin > IAM page.
  • To display roles associated with a service account, add the roles without skipping the optional steps. This process ensures that roles appear for the configured service account.

Citrix Cloud Service Account key

The Citrix Cloud Service Account key is required for creating a connection in Citrix DaaS. The key is contained in a credential file (.json). The file is automatically downloaded and saved to the Downloads folder after you create the key. When you create the key, be sure to set the key type to JSON. Otherwise, the Citrix Full Configuration interface cannot parse it.

To create a Service Account Key, navigate to IAM & Admin > Service accounts and click the email address of the Citrix Cloud Service Account. Switch to the Keys tab and select Add Key > Create new key. Make sure to select JSON as the key type.

Tip:

Create keys using the Service accounts page in the Google Cloud console. We recommend that you change keys regularly for security purposes. You can provide new keys to the Citrix Virtual Apps and Desktops application by editing an existing Google Cloud connection.

Add roles to the Citrix Cloud Service Account

To add roles to the Citrix Cloud Service Account:

  1. In the Google Cloud console, navigate to IAM & Admin > IAM.

  2. On the IAM > PERMISSIONS page, locate the service account you created, identifiable with an email address.

    For example, <my-service-account>@<project-id>.iam.gserviceaccount.com

  3. Select the pencil icon to edit the access to the principal of the service account.
  4. On the Edit access to “project-id” page for the selected principal option, select ADD ANOTHER ROLE to add the required roles to your service account one by one and then select SAVE.

Add roles to the Cloud Build Service Account

To add roles to the Cloud Build Service Account:

  1. In the Google Cloud console, navigate to IAM & Admin > IAM.

  2. On the IAM page, locate the Cloud Build service account, identifiable with an email address that begins with the Project ID and the word cloudbuild.

    For example, <project-id>@cloudbuild.gserviceaccount.com

  3. Select the pencil icon to edit the Cloud Build account roles.

  4. On the Edit access to “project-id” page for the selected principal option, select ADD ANOTHER ROLE to add the required roles to your Cloud Build service account one by one and then select SAVE.

    Note:

    Enable all the APIs to get the complete list of roles.

After April 29, 2024

Citrix Cloud uses two separate service accounts within the Google Cloud project:

  • Citrix Cloud Service Account: This service account enables Citrix Cloud to access the Google project, provision, and manage machines. This service account authenticates to Google Cloud using a key generated by Google Cloud.

    You must create this service account manually.

    You can identify this service account with an email address. For example, <my-service-account>@<project-id>.iam.gserviceaccount.com.

  • Cloud Compute Service Account: This service account is provisioned automatically after you enable all the APIs mentioned in Enable Google Cloud APIs. To view all automatically created service accounts, navigate to IAM & Admin > IAM in the Google Cloud console and select the Include Google-provided role grants checkbox. This account has the IAM basic editor role to do the operations. However, if you delete the default permission to have more granular control, you must add Storage Admin role that requires the following permissions:

    • resourcemanager.projects.get
    • storage.objects.create
    • storage.objects.get
    • storage.objects.list

    You can identify this service account by an email address that begins with the Project ID and the word compute. For example, <project-id>-compute@developer.gserviceaccount.com.

    Verify if the service account has been granted the following roles.

    • Cloud Build Service Account
    • Compute Instance Admin
    • Service Account User

Create a Citrix Cloud Service Account

To create a Citrix Cloud Service Account, follow these steps:

  1. In the Google Cloud console, navigate to IAM & Admin > Service accounts.
  2. On the Service accounts page, select CREATE SERVICE ACCOUNT.
  3. On the Create service account page, enter the required information, and then select CREATE AND CONTINUE.

  4. On the Grant this service account access to project page, click the Select a role drop-down menu and select the required roles. Click +ADD ANOTHER ROLE if you want to add more roles.

    Each account (personal or service) has various roles defining the management of the project. Grant the following roles to this service account:

    • Compute Admin
    • Storage Admin
    • Cloud Build Editor
    • Service Account User
    • Cloud Datastore User
    • Cloud KMS Crypto Operator

    The Cloud KMS Crypto Operator requires the following permissions:

    • cloudkms.cryptoKeys.get
    • cloudkms.cryptoKeys.list
    • cloudkms.keyRings.get
    • cloudkms.keyRings.list

    Note:

    Enable all the APIs to get the complete list of roles available while creating a new service account.

  5. Click CONTINUE
  6. On the Grant users access to this service account page, add users or groups to grant them access to perform actions in this service account.
  7. Click DONE.
  8. Navigate to the IAM main console.
  9. Identify the service account created.
  10. Validate the roles are assigned successfully.

Considerations:

When creating the service account, consider the following:

  • The steps Grant this service account access to project and Grant users access to this service account are optional. If you choose to skip these optional configuration steps, the newly created service account does not display in the IAM & Admin > IAM page.
  • To display roles associated with a service account, add the roles without skipping the optional steps. This process ensures that roles appear for the configured service account.

Citrix Cloud Service Account key

The Citrix Cloud Service Account key is required for creating a connection in Citrix DaaS. The key is contained in a credential file (.json). The file is automatically downloaded and saved to the Downloads folder after you create the key. When you create the key, be sure to set the key type to JSON. Otherwise, the Citrix Full Configuration interface cannot parse it.

To create a Service Account Key, navigate to IAM & Admin > Service accounts and click the email address of the Citrix Cloud Service Account. Switch to the Keys tab and select Add Key > Create new key. Make sure to select JSON as the key type.

Tip:

Create keys using the Service accounts page in the Google Cloud console. We recommend that you change keys regularly for security purposes. You can provide new keys to the Citrix Virtual Apps and Desktops application by editing an existing Google Cloud connection.

Add roles to the Citrix Cloud Service Account

To add roles to the Citrix Cloud Service Account:

  1. In the Google Cloud console, navigate to IAM & Admin > IAM.

  2. On the IAM > PERMISSIONS page, locate the service account you created, identifiable with an email address.

    For example, <my-service-account>@<project-id>.iam.gserviceaccount.com

  3. Select the pencil icon to edit the access to the principal of the service account.
  4. On the Edit access to “project-id” page for the selected principal option, select ADD ANOTHER ROLE to add the required roles to your service account one by one and then select SAVE.

Add roles to the Cloud Compute Service Account

To add roles to the Cloud Compute Service Account:

  1. In the Google Cloud console, navigate to IAM & Admin > IAM.

  2. On the IAM page, locate the Cloud Compute Service Account, identifiable with an email address that begins with the Project ID and the word compute.

    For example, <project-id>-compute@developer.gserviceaccount.com

  3. Select the pencil icon to edit the Cloud Build account roles.

  4. On the Edit access to “project-id” page for the selected principal option, select ADD ANOTHER ROLE to add the required roles to your Cloud Build service account one by one and then select SAVE.

    Note:

    Enable all the APIs to get the complete list of roles.

Storage permissions and bucket management

Citrix DaaS improves the process of reporting cloud build failures for the Google Cloud service. This service runs builds on the Google Cloud. Citrix DaaS creates a storage bucket named citrix-mcs-cloud-build-logs-{region}-{5 random characters} where the Google Cloud services captures build log information. An option is set on this bucket that deletes the contents after a period of 30 days. This process requires that the service account used for the connection has Google Cloud permissions set to storage.buckets.update. If the service account does not have this permission, Citrix DaaS ignores errors and proceeds with the catalog creation process. Without this permission, the size of the build logs increases and requires manual cleanup.

Enable private Google access

When a VM lacks an external IP address assigned to its network interface, packets are only sent to other internal IP addresses destinations. When you enable private access, the VM connects to the set of external IP addresses used by the Google API and associated services.

Note:

Whether private Google access is enabled, all VMs that are with and without public IP addresses, must be able to access Google Public APIs, especially if third-party networking appliances have been installed in the environment.

To ensure that a VM in your subnet can access the Google APIs without a public IP address for MCS provisioning:

  1. In Google Cloud, access the VPC network configuration.
  2. In the Subnet details screen, turn on Private Google access.

Private Google access

For more information, see Configuring Private Google Access.

Important:

If your network is configured to prevent VM access to the Internet, ensure that your organization assumes the risks associated with enabling Private Google access for the subnet to which the VM is connected.

Add a connection

Follow the guidance in Create a connection and resources. The following description guides you through setting up a hosting connection:

  1. From Manage > Configuration, select Hosting in the left pane.

  2. Select Add Connection and Resources in the action bar.

  3. On the Connection page, select Create a new Connection and Citrix provisioning tools, and then select Next.

    • Connection type. Select Google Cloud from the menu.
    • Connection name. Type a name for the connection.

  4. On the Region page, select a project name from the menu, select a region containing the resources you want to use, and then select Next.

  5. On the Network page, type a name for the resources, select a virtual network from the menu, select a subset, and then select Next. The resource name helps identify the region and network combination. Virtual networks with the (Shared) suffix appended to their name represent shared VPCs. If you configure a subnet-level IAM role for a shared VPC, only specific subnets of the shared VPC appear on the subnet list.

    Note:

    • The resource name can contain 1–64 characters, and cannot contain only blank spaces or the characters \ / ; : # . * ? = < > | [ ] { } " ' ( ) ' ).

  6. On the Summary page, confirm the information and then select Finish to exit the Add Connection and Resources window.

After creating the connection and resources, the connection and resources you created are listed. To configure the connection, select the connection and then select the applicable option in the action bar.

Similarly, you can delete, rename, or test the resources created under the connection. To do so, select the resource under the connection and then select the applicable option in the action bar.

Prepare a master VM instance and a persistent disk

Tip:

Persistent disk is the Google Cloud term for virtual disk.

To prepare your master VM instance, create and configure a VM instance with properties that match the configuration you want for the cloned VDA instances in your planned machine catalog. The configuration does not apply only to the instance size and type. It also includes instance attributes such as metadata, tags, GPU assignments, network tags, and service account properties.

As part of the mastering process, MCS uses your master VM instance to create the Google Cloud instance template. The instance template is then used to create the cloned VDA instances that comprise the machine catalog. Cloned instances inherit the properties (except the VPC, subnet, and persistent disk properties) of the master VM instance from which the instance template was created.

After configuring the properties of the master VM instance to your specifics, start the instance and then prepare the persistent disk for the instance.

We recommend that you manually create a snapshot of the disk. Doing so lets you use a meaningful naming convention to track versions, gives you more options to manage earlier versions of your master image, and saves time for machine catalog creation. If you do not create your own snapshot, MCS creates a temporary snapshot for you (which is deleted at the end of the provisioning process).

Create a machine catalog

Note:

Create your resources before you create a machine catalog. Use the naming conventions established by Google Cloud when configuring machine catalogs. See Bucket and object naming guidelines for more information.

Follow the guidance in Create machine catalogs. The following description is unique to Google Cloud catalogs.

  1. In the Studio navigation pane, select Machine Catalogs.

  2. Select Create Machine Catalog in the Actions bar.

  3. On the Operating System page, select Multi-session OS and then select Next.

    • Citrix Virtual Apps and Desktops also supports single-session OS.

  4. On the Machine Management page, select the Machines that are power managed and the Citrix Machine Creation Services options and then select Next. If there are multiple resources, select one from the menu.

  5. On the Master Image page, select a VM and the minimum functional level for the catalog and then select Next. If you want to use the sole tenancy functionality, be sure to select an image whose node group property is correctly configured. See Enable zone selection.

  6. On the Storage Types page, select the type of storage used to contain the operating system for this machine catalog. Each of the following storage options has unique price and performance characteristics. (An identity disk is always created using the zonal standard persistent disk.)

    • Standard persistent disk
    • Balanced persistent disk
    • SSD persistent disk

    For details about Google Cloud storage options, see https://cloud.google.com/compute/docs/disks/.

  7. On the Virtual Machines page, specify how many VMs you want to create, view the detailed specification of the VMs, and then select Next. If you use sole tenant node groups for machine catalogs, be sure to select only the zones where reserved sole tenant nodes are available. See Enable zone selection.

  8. On the Computer Accounts page, select an Active Directory account and then select Next.

    • If you select Create new Active Directory accounts, select a domain and then enter the sequence of characters representing the naming scheme for the provisioned VM computer accounts created in the Active Directory. The account naming scheme can contain 1–64 characters, and cannot contain blank spaces, or non-ASCII or special characters.
    • If you select Use existing Active Directory accounts, select Browse to navigate to the existing Active Directory computer accounts for the selected machines.

  9. On the Domain Credentials page, select Enter credentials, type the user name and password, select Save, and then select Next.

    • The credential you type must have permissions to perform Active Directory account operations.

  10. On the Summary page, confirm the information, specify a name for the catalog, and then select Finish.

    Note:

    The catalog name can contain 1–39 characters, and cannot contain only blank spaces or the characters \ / ; : # . * ? = < > | [ ] { } " ' ( ) ' ).

Machine catalog creation might take a long time to complete. To verify that the machines are created on the target node groups, go to the Google Cloud console.

Create a machine catalog using a machine profile

When you create a catalog to provision machines using Machine Creation Services (MCS), you can use a machine profile to capture the hardware properties from a virtual machine and apply them to newly provisioned VMs in the catalog. When MachineProfile parameter is not used, the hardware properties are captured from the master image VM or snapshot. Some properties you define explicitly, for example, StorageType, CatalogZones and CryptoKeyIs are ignored from machine profile.

  • To create a catalog with a machine profile, use the New-ProvScheme command. For example, New-ProvScheme –MachineProfile "path to VM". If you do not specify the MachineProfile parameter, hardware properties are captured from the master image VM.
  • To update a catalog with a new machine profile, use the Set-ProvScheme command. For example, Set-ProvScheme –MachineProfile "path to new VM". This command does not change the machine profile of the existing VMs in the catalog. Only the newly created VMs added to the catalog have the new machine profile.
  • You can also update the master image, however, when you update the master image, the hardware properties are not updated. If you want to update the hardware properties, you need to update the machine profile using Set-ProvScheme command. These changes will only apply to the new machines in the catalog. For updating the hardware properties of an existing machine, you can use Request-ProvVMUpdate command.

Manage machine catalog

To add machines to a catalog, update machines, and roll back an update, see Manage machine catalogs.

Power management

Citrix DaaS lets your power management of Google Cloud machines. Use the Search node in the navigation pane to locate the machine you want to power manage. The following power actions are available:

  • Delete
  • Start
  • Restart
  • Force Restart
  • Shut Down
  • Force Shutdown
  • Add to Delivery Group
  • Manage Tags
  • Turn On Maintenance Mode

You can also power manage Google Cloud machines by using Autoscale. To do so, add the Google Cloud machines to a Delivery Group and then enable Autoscale for that Delivery Group. For more information about Autoscale, see Autoscale.

Update provisioned machines using PowerShell

The Set-ProvScheme command changes the provisioning scheme. However, it does not affect existing machines. Using the PowerShell command Request-ProvVMUpdate command, you can now apply the current provisioning scheme to an existing persistent or non-persistent machine or set of machines. Currently, in GCP, the property update supported by this feature is machine profile.

You can update:

  • A single VM
  • A list of specific VMs or all existing VMs associated with a provisioning scheme ID
  • A list of specific VMs or all existing VMs associated with a provisioning scheme name

To update the existing VMs:

  1. Check the configuration of the existing machines. For example,

    Get-ProvScheme | select ProvisioningSchemeName, ProvisioningSchemeVersion
<!--NeedCopy-->

  2. Update the provisioning scheme. For example,

    `Set-ProvScheme –ProvisioningSchemeName "my-catalog" –MachineProfile "XDHyp:\HostingUnits\<hosting-unit>\machineprofileinstance.vm"
<!--NeedCopy-->

  3. Check if the current property of the VM matches the current provisioning scheme, and if there is any pending update action on the VM. For example,

    Get-ProvVM | select VMName, ProvisioningSchemeUpdateRequested, ProvisioningSchemeVersion
<!--NeedCopy-->

    You can also find machines with a particular version. For example,

    Get-ProvVM -Filter "ProvisioningSchemeVersion -eq 1" | select VMName, ProvisioningSchemeVersion
<!--NeedCopy-->
  4. Update existing machines.

    • To update all the existing machines:

       Request-ProvVMUpdate –ProvisioningSchemeName "my-catalog"
 <!--NeedCopy-->

    • To update a list of specific machines:

       Request-ProvVMUpdate -ProvisioningSchemeName "my-catalog" -VMName "vm1","vm2"
 <!--NeedCopy-->

    • To update machines based on the output of Get-ProvVM:

       Get-ProvVM -ProvisioningSchemeName "my-catalog" | Request-ProvVMUpdate
 <!--NeedCopy-->

  5. Find machines with an update scheduled. For example,

    Get-ProvVM -Filter "ProvisioningSchemeUpdateAfter" | select VMName, ProvisioningSchemeUpdateAfter
<!--NeedCopy-->

  6. Restart the machines. At the next power-up, property changes are applied to the existing machines. You can check the updated status using the following command:

    Get-ProvVM | select VMName, ProvisioningSchemeUpdateRequested, ProvisioningSchemeVersion
<!--NeedCopy-->

Protect accidental machine deletion

Citrix DaaS lets you protect MCS resources on the Google Cloud to prevent accidental deletion. Configure the provisioned VM by setting the deletionProtection flag to TRUE.

By default, VMs provisioned through MCS or Google Cloud plug-in are created with InstanceProtection enabled. The implementation is applicable to both persistent and non-persistent catalogs. The non-persistent catalogs are updated when the instances get re-created from the template. For existing persistent machines, you can set the flag in the Google Cloud console. For more information about setting the flag, see the Google Documentation site. New machines added to persistent catalogs are created with deletionProtection enabled.

If you attempt to delete a VM instance for which you have set the deletionProtection flag, the request fails. However, if you are granted the permission compute.instances.setDeletionProtection or assigned the IAM Compute Admin role, you can reset the flag to allow the resource to be deleted.

Import manually created Google Cloud machines

You can create a connection to Google Cloud and then create a catalog containing Google Cloud machines. Then, you can manually power cycle Google Cloud machines through Citrix DaaS. With this feature, you can:

  • Import manually created Google Cloud multi-session OS machines into a Citrix Virtual Apps and Desktops machine catalog.
  • Remove manually created Google Cloud multi-session OS machines from a Citrix Virtual Apps and Desktops catalog.
  • Use existing Citrix Virtual Apps and Desktops power management capabilities to power manage Google Cloud Windows multi-session OS machines. For example, set a restart schedule for those machines.

This functionality does not require changes to an existing Citrix Virtual Apps and Desktops provisioning workflow, nor the removal of any existing feature. We recommend that you use MCS to provision machines in Citrix DaaS’s Full Configuration interface instead of importing manually created Google Cloud machines.

Shared Virtual Private Cloud

Shared Virtual Private Clouds (VPCs) comprise a host project, from which the shared subnets are made available, and one or more service projects that use the resource. Shared VPCs are desirable options for larger installations because they provide centralized control, usage, and administration of shared corporate Google cloud resources. For more information, see the Google Documentation site.

With this feature, Machine Creation Services (MCS) supports provisioning and managing machine catalogs deployed to Shared VPCs. This support, which is functionally equivalent to the support currently provided in local VPCs, differs in two areas:

  1. You must grant extra permissions to the Service Account used to create the Host Connection. This process allows MCS to access and use Shared VPC Resources.
  2. You must create two firewall rules, one each for ingress and egress. These firewall rules are used during the image mastering process.

New permissions required

A Google Cloud service account with specific permissions is required when creating the host connection. These additional permissions must be granted to any service accounts used to create Shared VPC based host connections.

Tip:

These additional permissions are not new to Citrix DaaS. They are used to facilitate the implementation of local VPCs. With Shared VPCs, these additional permissions allow access to other shared VPC resources.

A maximum of four extra permissions must be granted to the service account associated with the host connection to support Shared VPC:

  1. compute.firewalls.list - This permission is mandatory. It allows MCS to retrieve the list of firewall rules present on the Shared VPC.
  2. compute.networks.list - This permission is mandatory. It allows MCS to identify the Shared VPC networks available to the service account.
  3. compute.subnetworks.list – This permission is optional depending on how you use VPCs. It allows MCS to identify the subnets within the visible Shared VPCs. This permission is already required when using local VPCs but must also be assigned in the Shared VPC host project.
  4. compute.subnetworks.use - This permission is optional depending on how you use VPCs. It is necessary to use subnet resources in the provisioned machine catalogs. This permission is already required for using local VPCs but must also be assigned in the Shared VPC host project.

When using these permissions, consider that there are different approaches based on the type of permission used to create the machine catalog:

  • Project-level permission:
    • Allows access to all Shared VPCs within the host project.
    • Requires the permissions #3 and #4 must be assigned to the service account.
  • Subnet-level permission:
    • Allows access to specific subnets within the Shared VPC.
    • Permissions #3 and #4 are intrinsic to the subnet level assignment and therefore do not need to be assigned directly to the service account.

Select the approach that matches your organizational needs and security standards.

Tip:

For more information about the differences between project-level and subnet-level permissions, see the Google Cloud documentation.

Firewall Rules

During the preparation of a machine catalog, a machine image is prepared to serve as the master image system disk for the catalog. When this process occurs, the disk is temporarily attached to a virtual machine. This VM must run in an isolated environment that prevents all inbound and outbound network traffic. This is accomplished through a pair of deny-all firewall rules; one for ingress and one for egress traffic. When using Google Cloud local VCPs, MCS creates this firewall in the local network and applies it to the machine for mastering. After mastering completes, the firewall rule is removed from the image.

We recommend keeping the number of new permissions required to use Shared VPCs to a minimum. Shared VPCs are higher-level corporate resources and typically have more rigid security protocols in place. For this reason, create a pair of firewall rules in the host project on the shared VPC resources, one for ingress and one for egress. Assign the highest priority to them. Apply a new target tag to each of these rules, using the following value:

citrix-provisioning-quarantine-firewall

When MCS creates or updates a machine catalog, it searches for firewall rules containing this target tag. It then examines the rules for correctness and applies them to the machine used to prepare the master image for the catalog. If the firewall rules are not found, or the rules are found but the rules or their priorities are incorrect, a message similar to the following appears:

"Unable to find valid INGRESS and EGRESS quarantine firewall rules for VPC <name> in project <project>. " Please ensure you have created 'deny all' firewall rules with the network tag 'citrix-provisioning-quarantine-firewall' and proper priority." "Refer to Citrix Documentation for details."

Configuring the shared VPC

Before adding the Shared VPC as a host connection in Citrix DaaS’s Full Configuration interface, complete the following steps to add service accounts from the project you intend to provision into:

  1. Create an IAM role.
  2. Add the service account used to create a CVAD host connection to the Shared VPC host project IAM role.
  3. Add the Cloud Build service account from the project you intend to provision into to the Shared VPC host project IAM role.
  4. Create firewall rules.

Create an IAM role

Determine the access level of the role — project level access or a more restricted model using subnet level access.

Project level access for IAM role. For the project level IAM role, include the following permissions:

  • compute.firewalls.list
  • compute.networks.list
  • compute.subnetworks.list
  • compute.subnetworks.use

To create a project level IAM role:

  1. In the Google Cloud console, navigate to IAM & Admin > Roles.
  2. On the Roles page, select CREATE ROLE.
  3. On the Create Role page, specify the role name. Select ADD PERMISSIONS.
    1. On the Add permissions page, add permissions to the role, individually. To add a permission, type the name of the permission in the Filter table field. Select the permission and then select ADD.
    2. Select CREATE.

Subnet-level IAM role. This role omits the addition of the permissions compute.subnetworks.list and compute.subnetworks.use after selecting CREATE ROLE. For this IAM access level, the permissions compute.firewalls.list and compute.networks.list must be applied to the new role.

To create a subnet level IAM role:

  1. In the Google Cloud console, navigate to VPC network > Shared VPC. The Shared VPC page appears, displaying the subnets of the Shared VPC networks that the host project contains.
  2. On the Shared VPC page, select the subnet that you want to access.
  3. In the top-right corner, select ADD MEMBER to add a service account.
  4. On the Add members page, complete these steps:
    1. In the New members field, type the name of your service account and then select your service account in the menu.
    2. Select the Select a role field and then Compute Network User.
    3. Select SAVE.
  5. In the Google Cloud console, navigate to IAM & Admin > Roles.
  6. On the Roles page, select CREATE ROLE.
  7. On the Create Role page, specify the role name. Select ADD PERMISSIONS.
    1. On the Add permissions page, add permissions to the role, individually. To add a permission, type the name of the permission in the Filter table field. Select the permission, and then select ADD.
    2. Select CREATE.

Add a service account to the host project IAM role

After creating an IAM role, do the following steps to add a service account for the host project:

  1. In the Google Cloud console, navigate to the host project and then to IAM & Admin > IAM.
  2. On the IAM page, select ADD to add a service account.
  3. On the Add members page:
    1. In the New members field, type the name of your service account and then select your service account in the menu.
    2. Select a role field, type the IAM role you created, and then select the role in the menu.
    3. Select SAVE.

The service account is now configured for the host project.

Add the cloud build service account to the shared VPC

Every Google Cloud subscription has a service account that is named after the project ID number, followed by cloudbuild.gserviceaccount. For example: 705794712345@cloudbuild.gserviceaccount.

You can determine what the project ID number is for your project by selecting Home and Dashboard in the Google Cloud console:

Google Cloud console navigation pane

Find the Project Number below the Project Info area of the screen.

Perform the following steps to add the Cloud Build service account to the Shared VPC:

  1. In the Google Cloud console, navigate to the host project and then to IAM & Admin > IAM.
  2. On the Permissions page, select ADD to add an account.
  3. On the Add members page, complete these steps:
    1. In the New members field, type the name of the Cloud Build service account and then select your service account in the menu.
    2. Select the Select a role field, type Computer Network User, and then select the role in the menu.
    3. Select SAVE.

Create firewall rules

As part of the mastering process, MCS copies the selected machine image and uses it to prepare the master image system disk for the catalog. During mastering, MCS attaches the disk to a temporary virtual machine, which then runs preparation scripts. This VM must run in an isolated environment that prohibits all inbound and outbound network traffic. To create an isolated environment, MCS requires two deny all firewall rules (an ingress rule and an egress rule). Therefore, create two firewall rules in the Host Project as follows:

  1. In the Google Cloud console, navigate to the host project and then to VPC network > Firewall.
  2. On the Firewall page, select CREATE FIREWALL RULE.
  3. On the Create a firewall rule page, complete the following:
    • Name. Type a name for the rule.
    • Network. Select the Shared VPC network to which the ingress firewall rule applies.
    • Priority. The smaller the value is, the higher the priority of the rule is. We recommend a small value (for example, 10).
    • Direction of traffic. Select Ingress.
    • Action on match. Select Deny.
    • Targets. Use the default, Specified target tags.
    • Target tags. Type citrix-provisioning-quarantine-firewall.
    • Source filter. Use the default, IP ranges.
    • Source IP ranges. Type a range that matches all traffic. Type 0.0.0.0/0.
    • Protocols and ports. Select Deny all.
  4. Select CREATE to create the rule.
  5. Repeat steps 1–4 to create another rule. For Direction of traffic, select Egress.

Add a connection

Add a connection to the Google cloud environments. See Add a connection.

Enable zone selection

Citrix Virtual Apps and Desktops supports zone selection. With zone selection, you specify the zones where you want to create VMs. With zone selection, administrators can place sole tenant nodes across zones of their choice. To configure sole tenancy, you must complete the following on Google Cloud:

  • Reserve a Google Cloud sole-tenant node
  • Create the VDA master image

Reserving a Google Cloud sole-tenant node

To reserve a sole-tenant node, refer to the Google Cloud documentation.

Important:

A node template is used to indicate performance characteristics of the system that is reserved in the node group. Those characteristics include the number of vGPUs, the amount of memory allocated to the node, and the machine type used for machines created on the node. For more information see the Google Cloud documentation.

Creating the VDA master image

To deploy machines on the sole-tenant node successfully, you need to take extra steps when creating a master VM image. Machine instances on Google Cloud have a property called node affinity labels. Instances used as master images for catalogs deployed to the sole-tenant node require a node affinity label that matches the name of the target node group. To achieve this, keep the following in mind:

Note:

If you intend to use sole tenancy with a shared VPC, see Shared Virtual Private Cloud.

Set a node affinity label when creating an instance

To set the node affinity label:

  1. In the Google Cloud console, navigate to Compute Engine > VM instances.

  2. On the VM instances page, select Create instance.

  3. On the Instance creation page, type or configure the required information and then select management, security, disks, networking, sole tenancy to open the settings panel.

  4. On the Sole tenancy tab, select Browse to view the available node groups in the current project. The Sole-tenant node page appears, displaying a list of available node groups.

  5. On the Sole-tenant node page, select the applicable node group from the list and then select Select to return to the Sole tenancy tab. The node affinity labels field populates with the information you selected. This setting ensures that machine catalogs created from the instance will be deployed to the selected node group.

  6. Select Create to create the instance.

Set a node affinity label for an existing instance

To set the node affinity label:

  1. In the Google Cloud Shell terminal window, use the gcloud compute instances command to set a node affinity label. Include the following information in the gcloud command:

    • Name of the VM. For example, use an existing VM named s*2019-vda-base.*
    • Name of the node group. Use the node group name you previously created. For example, mh-sole-tenant-node-group-1.
    • The zone where the instance resides. For example, the VM resides in the *us-east-1b* zone.

    For example, type the following command in the terminal window:

    • gcloud compute instances set-scheduling "s2019-vda-base" --node-group="mh-sole-tenant-node-group-1" --zone="us-east1-b"

    For more information about the gcloud compute instances command, see the Google Developer Tools documentation at https://cloud.google.com/sdk/gcloud/reference/beta/compute/instances/set-scheduling.

  2. Navigate to the VM instance details page of the instance and verify that the Node Affinities field populates with the label.

Create a machine catalog

After setting the node affinity label, configure the machine catalog.

Preview: Using Customer Managed Encryption Keys (CMEK)

You can use Customer Managed Encryption Keys (CMEK) for MCS catalogs. When using this functionality, you assign the Google Cloud Key Management Service CryptoKey Encrypter/Decrypter role to the Compute Engine Service Agent. Citrix DaaS account must have the correct permissions in the project where the key is stored. Refer to Helping to protect resources by using Cloud KMS keys for more information.

Your Compute Engine Service Agent is in the following form: service-<Project _Number>@compute-system.iam.gserviceaccount.com. This form is different than the default Compute Engine Service Account.

Note:

This Compute Engine Service Account might not appear in the Google Console IAM Permissions display. In such cases, use the gcloud command as described in Helping to protect resources by using Cloud KMS keys.

Assign permissions to Citrix DaaS account

Google Cloud KMS permissions can be configured in various ways. You can either provide project level KMS permissions or resource level KMS permissions. See Permissions and roles for more information.

Project level permissions

One option is to provide Citrix DaaS account with project-level permissions to browse Cloud KMS resources. To do this, create a custom role, and add the following permissions:

  • cloudkms.keyRings.list
  • cloudkms.keyRings.get
  • cloudkms.cryptokeys.list
  • cloudkms.cryptokeys.get

Assign this custom role to your Citrix DaaS account. This allows you to browse regional keys in the relevant project in the inventory.

Resource Level Permissions

For the other option, resource level permissions, in the Google Cloud console, browse to the cryptoKey you use for MCS provisioning. Add Citrix DaaS account to a key ring or a key that you use for catalog provisioning.

Tip:

With this option, you cannot browse regional keys for your project in the inventory because Citrix DaaS account does not have project-level list permissions on the Cloud KMS resources. However, you can still provision a catalog using CMEK by specifying the correct cryptoKeyId in the ProvScheme custom properties, described below.

Provisioning with CMEK using custom properties

When creating your Provisioning Scheme via PowerShell, specify a CryptoKeyId property in ProvScheme CustomProperties. For example:

'<CustomProperties xmlns="http://schemas.citrix.com/2014/xd/machinecreation" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <Property xsi:type="StringProperty" Name="CryptoKeyId" Value="<yourCryptoKeyId>" />
</CustomProperties>'
<!--NeedCopy-->

The cryptoKeyId must be specified in the following format:

projectId:location:keyRingName:cryptoKeyName

For example, if you’d like to use the key my-example-key in key ring my-example-key-ring in the region us-east1 and project with ID my-example-project-1, your ProvScheme custom settings would resemble:

'<CustomProperties xmlns="http://schemas.citrix.com/2014/xd/machinecreation" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <Property xsi:type="StringProperty" Name="CryptoKeyId" Value="my-example-project-1:us-east1:my-example-key-ring:my-example-key" />
</CustomProperties>'
<!--NeedCopy-->

All MCS provisioned disks and images related to this provisioning scheme use this customer managed encryption key.

Tip:

If you use global keys, the customer properties location must say global and not the region name, which in the example above is us-east1. For example: <Property xsi:type="StringProperty" Name="CryptoKeyId" Value="my-example-project-1:global:my-example-key-ring:my-example-key" />.

Rotating customer managed keys

Google Cloud does not support rotating keys on existing persistent disks or images. Once a machine is provisioned it is tied to the key version in use at the time it was created. However, a new version of the key can be created and that new key is used for newly provisioned machines or resources created when a catalog is updated with a new master image.

Important considerations about key rings

Key rings cannot be renamed or deleted. Also, you might incur unforeseen charges when configuring them. When deleting or removing a key ring, Google Cloud displays an error message:

Sorry, you can't delete or rename keys or key rings. We were concerned about the security implications of allowing multiple keys or key versions over time to have the same resource name, so we decided to make names immutable. (And you can't delete them, because we wouldn't be able to do a true deletion--there would still have to be a tombstone tracking that this name had been used and couldn't be reused).
We're aware that this can make things untidy, but we have no immediate plans to change this.
If you want to avoid getting billed for a key or otherwise make it unavailable, you can do so by deleting all the key versions; neither keys nor key rings are billed for, just the active key versions within the keys.
<!--NeedCopy-->

Tip:

For more information, see Editing or deleting a key ring from the console.

Uniform bucket-level access compatibility

Citrix DaaS is compatible with uniform bucket-level access control policy on Google Cloud. This functionality augments the use of IAM policy that grants permissions to a service account to allow for the manipulation of resources, including storage buckets. With uniform bucket level access control, Citrix DaaS allows you to use an access control list (ACL) to control access to storage buckets or objects stored in them. See Uniform bucket-level access for overview information about Google Cloud uniform bucket-level access. For configuration information, see Require uniform bucket-level access.

Google Cloud Marketplace

You can browse and select images offered by Citrix on Google Cloud Marketplace to create machine catalogs. Currently, MCS supports only the machine profile workflow for this feature.

To search for Citrix VDA VM product through Google Cloud Marketplace, go to https://console.cloud.google.com/marketplace.

You can use a custom image or a Citrix ready image on Google Cloud Marketplace to update an image of a machine catalog.

Note:

If the machine profile does not contain storage type information, the value is derived from custom properties.

The supported Google Cloud Marketplace images are:

  • Windows 2019 Single Session
  • Windows 2019 Multi Session
  • Ubuntu

Example of using a Citrix ready image as a source for creating a machine catalog:

New-ProvScheme -ProvisioningSchemeName GCPCatalog \
-HostingUnitName GcpHu -IdentityPoolName gcpPool -CleanOnBoot \
-MasterImageVM XDHyp:\HostingUnits\GcpHu\images.folder\citrix-daas-win2019-single-vda-v20220819.publicimage \
-MachineProfile XDHyp:\HostingUnits\GcpHu\Base.vm
<!--NeedCopy-->

Service endpoint URLs

You must have access to the following URLs:

  • https://oauth2.googleapis.com
  • https://cloudresourcemanager.googleapis.com
  • https://compute.googleapis.com
  • https://storage.googleapis.com
  • https://cloudbuild.googleapis.com

Google Cloud projects

There are basically two types of Google Cloud projects:

  • Provisioning project: In this case, the current admin account owns the provisioned machines in the project. This project is also referred to as a local project.
  • Shared VPC project: Project in which machines created in the provisioning project use the VPC from the Shared VPC project. The admin account used for provisioning project has limited permissions in this project, specifically, only permissions to use the VPC.

Required GCP permissions

This section has the complete list of GCP permissions. Use the complete set of permissions as given in the section for the functionality to work correctly.

Note:

GCP is introducing changes to Cloud Build Services’s default behavior and use of service accounts after April 29, 2024. For more information, see Cloud Build Service Account Change. Your existing Google projects with Cloud Build API enabled before April 29, 2024 are not affected by this change. However, if you want to have existing Cloud Build Service behavior after April 29, you can create or apply the organization policy to disable the constraint enforcement before you enable the API. If you set the new organization policy, you can still follow the existing permissions in this section and the items that are marked Before Cloud Build Service Account Change. If not, then follow the existing permissions and items that are marked After Cloud Build Service Account Change.

Creating a host connection

  • Minimum permissions required for Citrix Cloud Service Account in Provisioning project:

     compute.instanceTemplates.list
 compute.instances.list
 compute.networks.list
 compute.projects.get
 compute.regions.list
 compute.subnetworks.list
 compute.zones.list
 resourcemanager.projects.get
 <!--NeedCopy-->

    The following Google defined roles have the permissions as listed above:

    • Compute Admin
    • Cloud Datastore User

  • Additional permissions required for Shared VPC for Citrix Cloud Service Account in Shared VPC project:

     compute.networks.list
 compute.subnetworks.list
 resourcemanager.projects.get
 <!--NeedCopy-->

    The following Google defined roles have the permissions as listed above:

    • Compute Network User

Power management of VMs

Minimum permissions required for Citrix Cloud Service Account in Provisioning project in case of power managed only catalogs:

compute.instanceTemplates.list
compute.instances.list
compute.instances.get
compute.instances.reset
compute.instances.resume
compute.instances.start
compute.instances.stop
compute.instances.suspend
compute.networks.list
compute.projects.get
compute.regions.list
compute.subnetworks.list
compute.zones.list
resourcemanager.projects.get
compute.zoneOperations.get
<!--NeedCopy-->

The following Google defined roles have the permissions as listed above:

  • Compute Admin
  • Cloud Datastore User

Creating, updating, or deleting VMs

  • Minimum permissions required for Citrix Cloud Service Account in Provisioning project:

     cloudbuild.builds.create
 cloudbuild.builds.get
 cloudbuild.builds.list
 compute.acceleratorTypes.list
 compute.diskTypes.get
 compute.diskTypes.list
 compute.disks.create
 compute.disks.createSnapshot
 compute.disks.delete
 compute.disks.get
 compute.disks.list
 compute.disks.setLabels
 compute.disks.use
 compute.disks.useReadOnly
 compute.firewalls.create
 compute.firewalls.delete
 compute.firewalls.list
 compute.globalOperations.get
 compute.images.create
 compute.images.delete
 compute.images.get
 compute.images.list
 compute.images.setLabels
 compute.images.useReadOnly
 compute.instanceTemplates.create
 compute.instanceTemplates.delete
 compute.instanceTemplates.get
 compute.instanceTemplates.list
 compute.instanceTemplates.useReadOnly
 compute.instances.attachDisk
 compute.instances.create
 compute.instances.delete
 compute.instances.detachDisk
 compute.instances.get
 compute.instances.list
 compute.instances.reset
 compute.instances.resume
 compute.instances.setDeletionProtection
 compute.instances.setLabels
 compute.instances.setMetadata
 compute.instances.setServiceAccount
 compute.instances.setTags
 compute.instances.start
 compute.instances.stop
 compute.instances.suspend
 compute.machineTypes.get
 compute.machineTypes.list
 compute.networks.list
 compute.networks.updatePolicy
 compute.nodeGroups.list
 compute.nodeTemplates.get
 compute.projects.get
 compute.regions.list
 compute.snapshots.create
 compute.snapshots.delete
 compute.snapshots.list
 compute.snapshots.get
 compute.snapshots.setLabels
 compute.snapshots.useReadOnly
 compute.subnetworks.get
 compute.subnetworks.list
 compute.subnetworks.use
 compute.zoneOperations.get
 compute.zoneOperations.list
 compute.zones.get
 compute.zones.list
 iam.serviceAccounts.actAs
 resourcemanager.projects.get
 storage.buckets.create
 storage.buckets.delete
 storage.buckets.get
 storage.buckets.list
 storage.buckets.update
 storage.objects.create
 storage.objects.delete
 storage.objects.get
 storage.objects.list
 compute.networks.get
 compute.resourcePolicies.use

 <!--NeedCopy-->

    The following Google defined roles have the permissions as listed above:

    • Compute Admin
    • Storage Admin
    • Cloud Build Editor
    • Service Account User
    • Cloud Datastore User

  • Additional permissions required for Shared VPC for Citrix Cloud Service Account in Shared VPC project to create a hosting unit using VPC and subnetwork from Shared VPC project:

     compute.firewalls.list
 compute.networks.list
 compute.projects.get
 compute.regions.list
 compute.subnetworks.get
 compute.subnetworks.list
 compute.subnetworks.use
 compute.zones.list
 resourcemanager.projects.get
 <!--NeedCopy-->

    The following Google defined roles have the permissions as listed above:

    • Compute Network User
    • Cloud Datastore User

  • (Before Cloud Build Service Account Change): Minimum permissions required for Cloud Build Service Account in Provisioning project required by Google Cloud Build service when downloading preparation instruction disk to MCS:

  • (After Cloud Build Service Account Change): Minimum permissions required for Cloud Compute Service Account in Provisioning project required by Google Cloud Compute service when downloading preparation instruction disk to MCS:

     compute.disks.create
 compute.disks.delete
 compute.disks.get
 compute.disks.list
 compute.disks.setLabels
 compute.disks.use
 compute.disks.useReadOnly
 compute.images.get
 compute.images.list
 compute.images.useReadOnly
 compute.instances.create
 compute.instances.delete
 compute.instances.get
 compute.instances.getSerialPortOutput
 compute.instances.list
 compute.instances.setLabels
 compute.instances.setMetadata
 compute.instances.setServiceAccount
 compute.machineTypes.list
 compute.networks.get
 compute.networks.list
 compute.projects.get
 compute.subnetworks.list
 compute.subnetworks.use
 compute.subnetworks.useExternalIp
 compute.zoneOperations.get
 compute.zones.list
 iam.serviceAccounts.actAs
 logging.logEntries.create
 pubsub.topics.publish
 resourcemanager.projects.get
 source.repos.get
 source.repos.list
 storage.buckets.create
 storage.buckets.get
 storage.buckets.list
 storage.objects.create
 storage.objects.delete
 storage.objects.get
 storage.objects.list
 <!--NeedCopy-->

    The following Google defined roles have the permissions as listed above:

    • Cloud Build Service Account (After Cloud Build Service Account Change, it is Cloud Compute Service Account)
    • Compute Instance Admin
    • Service Account User

  • Minimum permissions required for Cloud Compute Service Account in Provisioning project required by Google Cloud Build service when downloading preparation instruction disk to MCS:

     resourcemanager.projects.get
 storage.objects.create
 storage.objects.get
 storage.objects.list
 <!--NeedCopy-->

    The following Google defined roles have the permissions as listed above:

    • Compute Network User
    • Storage Account User
    • Cloud Datastore User
  • (Before Cloud Build Service Account Change): Additional permissions required for Shared VPC for Cloud Build Service Account in Provisioning project required by Google Cloud Build service when downloading preparation instruction disk to MCS:

  • (After Cloud Build Service Account Change): Additional permissions required for Shared VPC for Cloud Compute Service Account in Provisioning project required by Google Cloud Compute service when downloading preparation instruction disk to MCS:

     compute.firewalls.list
 compute.networks.list
 compute.subnetworks.list
 compute.subnetworks.use
 resourcemanager.projects.get
 <!--NeedCopy-->

    The following Google defined roles have the permissions as listed above:

    • Compute Network User
    • Storage Account User
    • Cloud Datastore User

  • Additional permissions required for Cloud Key Management Service (KMS) for Citrix Cloud Service Account in Provisioning project:

     cloudkms.cryptoKeys.get
 cloudkms.cryptoKeys.list
 cloudkms.keyRings.get
 cloudkms.keyRings.list
 <!--NeedCopy-->

    The following Google defined roles have the permissions as listed above:

    • Compute KMS Viewer

General permissions

Following are the permissions for Citrix Cloud Service Account in Provisioning project for all features supported in MCS. These permissions provide the best compatibility going forward:

resourcemanager.projects.get
cloudbuild.builds.create
cloudbuild.builds.get
cloudbuild.builds.list
compute.acceleratorTypes.list
compute.diskTypes.get
compute.diskTypes.list
compute.disks.create
compute.disks.createSnapshot
compute.disks.delete
compute.disks.get
compute.disks.setLabels
compute.disks.use
compute.disks.useReadOnly
compute.firewalls.create
compute.firewalls.delete
compute.firewalls.list
compute.globalOperations.get
compute.images.create
compute.images.delete
compute.images.get
compute.images.list
compute.images.setLabels
compute.images.useReadOnly
compute.instanceTemplates.create
compute.instanceTemplates.delete
compute.instanceTemplates.get
compute.instanceTemplates.list
compute.instanceTemplates.useReadOnly
compute.instances.attachDisk
compute.instances.create
compute.instances.delete
compute.instances.detachDisk
compute.instances.get
compute.instances.list
compute.instances.reset
compute.instances.resume
compute.instances.setDeletionProtection
compute.instances.setLabels
compute.instances.setMetadata
compute.instances.setTags
compute.instances.start
compute.instances.stop
compute.instances.suspend
compute.instances.update
compute.instances.updateAccessConfig
compute.instances.updateDisplayDevice
compute.instances.updateSecurity
compute.instances.updateShieldedInstanceConfig
compute.instances.updateShieldedVmConfig
compute.machineTypes.get
compute.machineTypes.list
compute.networks.list
compute.networks.updatePolicy
compute.nodeGroups.list
compute.nodeTemplates.get
compute.projects.get
compute.regions.list
compute.snapshots.create
compute.snapshots.delete
compute.snapshots.list
compute.snapshots.get
compute.snapshots.setLabels
compute.snapshots.useReadOnly
compute.subnetworks.get
compute.subnetworks.list
compute.subnetworks.use
compute.subnetworks.useExternalIp
compute.zoneOperations.get
compute.zoneOperations.list
compute.zones.get
compute.zones.list
resourcemanager.projects.get
storage.buckets.create
storage.buckets.delete
storage.buckets.get
storage.buckets.list
storage.buckets.update
storage.objects.create
storage.objects.delete
storage.objects.get
storage.objects.list
cloudkms.cryptoKeys.get
cloudkms.cryptoKeys.list
cloudkms.keyRings.get
cloudkms.keyRings.list
compute.disks.list
compute.instances.setServiceAccount
compute.networks.get
compute.networks.use
compute.networks.useExternalIp
iam.serviceAccounts.actAs
compute.resourcePolicies.use
<!--NeedCopy-->

More information

Google Cloud environments
April 4, 2024
Contributed by: 
C L
April 4, 2024
Contributed by: 
C L

In this article

Site feedback | Your privacy choices footer linkYour Privacy Choices | Privacy and legal terms | Cookie preferences | Consent settings | docs.cloud.com
© 1999- Cloud Software Group, Inc. All rights reserved.