Citrix DaaS (formerly Citrix Virtual Apps and Desktops service) 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. Show
Requirements
Enable Google Cloud APIsTo use the Google Cloud functionality through the Citrix Virtual Apps and Desktops Full Configuration interface, enable these APIs in your Google Cloud project:
From the Google Cloud console, complete these steps:
Configure the Google Cloud service accountA Google Cloud service account lets you create and manage resources inside Google Cloud projects. A Google Cloud service account is required to provision and manage machines, as described in this article. The Google Cloud account authenticates to Citrix Cloud using a key generated by Google Cloud. Each account (personal or service) has various roles defining the management of the project. We recommend that you create a service account. To do so, follow these steps:
When creating the service account, consider the following:
When creating a service account, there is an option to create a key for the account. You need this key when 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.
Also, you need to grant your service account the necessary permissions to access your Google Cloud project:
Storage permissions and bucket managementCitrix 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 accessWhen 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.
To ensure that a VM in your subnet can access the Google APIs without a public IP address for MCS provisioning:
For more information, see Configuring Private Google Access.
Add a connectionIn the Full Configuration interface, follow the guidance in Create a connection and resources. The following description guides you through setting up a hosting connection:
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
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
Follow the guidance in Create machine catalogs. The following description is unique to Google Cloud catalogs.
Machine catalog creation might take a long time to complete. When it completes, the catalog is listed. You can verify that the machines are created on the target node groups in the Google Cloud console. Add machines to a catalogTo add machines to a catalog, follow these steps:
This feature can be useful in cases where you want to update your master image or the minimum functional level. To update machines, follow these steps:
To roll back a machine update, follow these steps:
Power managementCitrix 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:
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. Protect accidental machine deletionCitrix 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 machinesYou 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:
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 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:
New permissions requiredA 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.
A maximum of four extra permissions must be granted to the service account associated with the host connection to support Shared VPC:
When using these permissions, consider that there are different approaches based on the type of permission used to create the machine catalog:
Select the approach that matches your organizational needs and security standards.
Firewall RulesDuring 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." 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:
Create an IAM roleDetermine 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:
To create a project level IAM role:
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:
Add a service account to the host project IAM roleAfter creating an IAM role, do the following steps to add a service account for the host project:
The service account is now configured for the host project. Every Google Cloud subscription has a service account that is named after the project ID number, followed by cloudbuild.gserviceaccount. For example: . You can determine what the project ID number is for your project by selecting Home and Dashboard in the Google Cloud console: 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:
Create firewall rulesAs 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:
Add a connectionAfter adding the network interfaces to the Cloud Connector instance, add a connection. Enable zone selectionCitrix DaaS 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:
Reserving a Google Cloud sole-tenant nodeTo reserve a sole-tenant node, refer to the Google Cloud documentation.
Creating the VDA master imageTo 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:
Set a node affinity label when creating an instanceTo set the node affinity label:
Set a node affinity label for an existing instanceTo set the node affinity label:
Create a machine catalogAfter 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.
Assign permissions to Citrix DaaS accountGoogle 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 permissionsOne 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:
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 PermissionsFor 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.
Provisioning with CMEK using custom propertiesWhen 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.
Rotating customer managed keysGoogle 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. 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-->
Uniform bucket-level access compatibilityCitrix 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.
|