VDI is a popular way to implement remote access solutions for workers, partners and administrators, and cloud-based Virtual Desktops offer unique advantages in terms of their ability to scale dynamically and on-demand. For any VDI environment, the ability to implement consistent security is critical. This includes consistent visiblity into user behavior, and enhanced control around network access. Cisco Secure Workload provides:
While these capabilities often support security across all datacenter and cloud workloads, there are some unique considerations when deploying Cisco Secure Workload in VDI. Such as:
Code from this respository is designed to syncronize AWS WorkSpace context and tags to solve (#2), and automatically clean agent records when a WorkSpace is terminated (#3). By running these functions in AWS Lambda, Cisco Secure Workload can provide highly automated security for Amazon WorkSpaces.
There are 2 Lambda Functions
labels_lambda/handler.py
- This syncronizes AWS tags and context (including UserName) with Cisco Secure Workload.cleanup_lambda/handler.py
- This cleans up Cisco Secure Workload records when a WorkSpace is terminated.No code modification should be required. The following environment variables need to be provisioned to run the lambda function.
ADD_TAGS
-- Applicable only for "labels_lambda". Set to 'true' if you want tags attached to WorkSpaces to sync as labels in Cisco Secure Workload. This can increase the time it takes the Lambda to run especially if there are a lot of workspaces. Can be left blank.ATTRIBUTES_LIST
-- Required. These are additional fields to sync as Cisco Secure Workload labels. Comma separated format. Recommended value is "UserName". A full list of default attributes (not tags) can be found here: https://docs.aws.amazon.com/workspaces/latest/api/API_Workspace.htmlDELETE_SENSORS
-- Applicable only for "cleanup_lambda". Set to 'true' if you want sensor records to be removed when a WorkSpace is terminated (recommended).SECURE_WORKLOAD_URL
-- Cisco Secure Workload URLSECURE_WORKLOAD_API_KEY
-- Cisco Secure Workload API key with User data upload and sensor management capabilities.SECURE_WORKLOAD_API_SECRET
-- Cisco Secure Workload API secret with User data upload and sensor management capabilities.SECURE_WORKLOAD_TENANT
-- Cisco Secure Workload Root Scope/Tenant name.AWS_REGION
-- Example "us-east-1"The scripts are optimized for Python3. It will also require additional dependent packages. To build a package that can then be uploaded to lambda you will need to:
cd secure-workload-aws-workspaces cd labels_lambda
pip3 install tetpyclient -t .
. This will download all of the additional python dependency code required. Boto3 is included in the AWS Lambda runtime, so it does not need to be installed locally unless the function is being tested locally.There are three things that need to be done to prep a golden image for cloning with the Cisco Secure Workload agent in-place:
The agent can be installed as normal. It is recommended to leverage the PowerShell "Easy Installer".
Each agent installation has a unique certificate and UUID that is generated on install. If a golden image were cloned, and passes on its UUID, the clone will fail to register. Thus, when preparing the image, you must anonymize the install before converting it to a template.
C:\Program Files\Cisco Tetration\sensor_uuid
C:\Program Files\Cisco Tetration\cert\client.cert
C:\Program Files\Cisco Tetration\cert\client.key
It's very common in AWS WorkSpaces for an image to go into hibernation. In order to ensure that the latest policy is applied immediatly when the image resumes, a scheduled task should be created to re-start the agent service and reset the connection as soon as the image wakes up. The following files provide examples:
workspace_scheduled_task/RestartTetrationOnResume.xml
- This is a template for a scheduled task. Note the following...
-NoLogo -NonInteractive -WindowStyle Hidden -File "C:\start_enforcement_agent.ps1"
workspace_scheduled_task/start_enforcement_agent.ps1
- This is the powershell script that is executed. Note that it loops checking connectivity to "www.tetrationcloud.com" before restarting the services. For an on-premises deployment, this should be changed to one of the pingable Cisco Secure Workload cluster IP addresses. The services in the restart script are "TetSensor" and "TetEnforcer". These are the service names as of Cisco Secure Workload version 3.5, but service names are subject to change with future releases.Owner
Contributors
Categories
Products
Secure WorkloadProgramming Languages
PythonLicense
Code Exchange Community
Get help, share code, and collaborate with other developers in the Code Exchange community.View Community