Managing Amazon Linux 2 Amazon WorkSpaces with AWS OpsWorks for Puppet Enterprise

Important note:
AWS OpsWorks for Puppet Enterprise is not accepting new customers. Existing customers will be unaffected until March 31, 2024 at which time the service will become unavailable. We recommend that existing customers migrate to other solutions as soon as possible. For information about how to migrate your existing Puppet Enterprise servers, see How to migrate an OpsWorks for Puppet Enterprise server to Amazon Elastic Compute Cloud (Amazon EC2).

Overview

In this post, I demonstrate how to use OpsWorks for Puppet Enterprise to achieve the same level of control with WorkSpaces for Amazon Linux.

In Puppet, a module consists of a collection of resources, classes, files, definition, and templates. For this post, I created a sample Puppet module for configuration options you would expect for Linux WorkSpaces management. The module allows administrators to control access to their WorkSpaces and PCoIP settings. The source is available from https://github.com/aws-samples/amazon-workspaces-linux-puppet-sample.

Walkthrough

You need three Puppet modules for this procedure. Now that you have a sample Linux WorkSpaces module, you also need the stdlib and saz-sudo modules:

The stdlib module provides a standard library of resources for Puppet modules and can be found at https://forge.puppet.com/puppetlabs/stdlib .
The saz-sudo module allows administrators to configure sudo permissions with Puppet. It can be found on at https://forge.puppet.com/saz/sudo .

Prerequisites

To follow the steps in this post, you need the following:

An AWS environment with Amazon WorkSpaces configured
An Amazon Linux 2 WorkSpace to use as your Gold Image
AWS OpsWorks for Puppet Enterprise
WorkSpaces connectivity to your Puppet Enterprise servers
Internet connectivity from your Puppet Enterprise servers
System connectivity to your OpsWorks instance, along with the necessary management tools (for example, Git, the AWS CLI, Puppet tools)

Step 1: Modify your Puppetfile

To use the modules, add them to your local Puppetfile and push the change to your OpsWorks instance. For the modules on the Puppet Forge, specify the module name and desired version. Because the sample module is not on the Forge, specify the Git repo.

Navigate to the local clone of your control repository.
Open Puppetfile in your text editor of choice.

Add the following after the existing mod statements:

mod 'puppetlabs-stdlib', '5.1.0'
mod 'saz-sudo', '5.0.0'
mod 'amazon-linuxws',
    :git => 'https://github.com/aws-samples/amazon-workspaces-linux-puppet-sample'

Save the file.

Push the change to your OpsWorks control repo, by running the following command:

git add Puppetfile
git commit -m “Added amazon-linuxws, saz-sudo and stdlib”
git push origin production

Step 2: Deploy the changes to your Puppet Enterprise master

Change to the root of your OpsWorks Starter Kit.

Request an access token by running the following command:

puppet-access login --config-file .config/puppetlabs/client-tools/puppet-access.conf --lifetime 8h

Deploy the code changes by running the following command:

puppet-code deploy --all --wait --config-file .config/puppet-code.conf

Step 3. Configure your Puppet Enterprise master to allow agent installation without the AWS CLI

By default, OpsWorks enables administrators to install Puppet agents using the AWS CLI. This alleviates the need for administrators to approve certificates and instead uses IAM instance roles. As a managed service, WorkSpaces do not have IAM instance roles.

The following steps show how to pull down and install the agent automatically. The procedure requires that you re-enable the traditional, certificate-based, method. To do this:

Log in to the Puppet Enterprise console.
Under CONFIGURE, choose Classification.
Under PE infrastructure, choose PE master.
On the Configuration tab, look for class puppet_enterprise::profile::master. Under Parameters, add a parameter with the parameter name allow_unauthenticated_ca and value set to true.
Commit the change.

Step 4. Set up a collection for your Linux WorkSpace in the Puppet Enterprise console

Puppet uses criteria -based collections to target and apply policies to your systems. To use Puppet to manage your Amazon Linux 2 WorkSpaces, create a collection for them. The policy that you define should only apply to those instances. To do this:

Log in to the Puppet Enterprise console.
Under CONFIGURE, choose Classification, Add group….
Specify values for Parent name, Group name, and Environment, and then choose Add, as shown in the following screenshot.
Browse to the group that you just created.
On the Rules tab, choose Nodes must match all rules, and specify the rules to identify the WorkSpaces that this collection must contain, as shown in the following screenshot.
Commit the changes.

Note: In my test environment, I deploy WorkSpaces in subnets based on their use case. So, I use operating system, kernel, and IP address to identify the WorkSpaces that this collection should contain. Because my WorkSpaces are in either 10.10.100.0/24 or 10.10.101.0/24, I use a regular expression to match addresses in that range. Then, to ensure that I only target Linux WorkSpaces, I specified that the OS must be Amazon and the kernel must be Linux. By restricting the target, I make sure not to apply the policy in unwanted ways—for example, to the Windows WorkSpaces that I manage with OpsWorks. Finally, I note an exception to the collection. This exception is designed to ensure the test system at 10.10.100.134 and is not affected by any configurations I apply.

Step 5: Configure the collection settings

Now that you have defined your collection, specify the policies to apply to that collection. In this case, use the linuxws class in your sample module.

On the Configuration tab, in the Add new class field, select linuxws, and then choose Add class.
Under the newly added linuxws class, set the desired parameters, as shown in the following screenshot. Choose Add parameter after each addition.

wsloglevel – This can be set from 0 to 3 and dictates the log verbosity, with 0 being no logs and 3 being the most verbose. Set this parameter in Options. Parameter defaults to 1 if unset.

clipboard – This dictates the clipboard-sharing behavior. It is optional and defaults to 0 (Disabled in both directions) if left unset. The options are:

0 – Disabled in both directions

1 – Enabled in both directions

2 – Enabled client to agent only

3 – Enabled agent to client only

domainname – This is the short name for the Active Directory Domain where your users are located.

userlist – This is an array of users and groups you want to have sudo and ssh access to the system. The format is [“user1”,”group1”].

3. Choose Commit 4 changes.

Step 6: Create a new image to automatically connect to OpsWorks

Connect to your golden image WorkSpace and open a terminal window.
To automatically run the install script, modify the rc.local file by running the following command:
```
$ sudo vi /etc/rc.d/rc.local
```
Make rc.local executable by running the following command:
```
$ chmod +x /etc/rc.d/rc.local
```
Add the line /bin/puppetinst.sh & and press Esc.
Type :wq and press Enter.
Create the deployment script by running the following command:
```
$ sudo vi /bin/puppetinst.sh
```

Enter the following code in the script:

#!/bin/bash
# Wait 5 minutes before triggering the install
sleep 600
#Download and install agent from OpsWorks Server
curl -k https://<INSERT THE URL OF YOUR PM HERE>/packages/current/install.bash | bash
#Remove cron job after 1 run
sed -i '/\/bin\/puppetinst.sh/d' /etc/rc.d/rc.local
#reset permissions on /etc/rc.d/rc.local
chmod -x /etc/rc.d/rc.local
# Remove file after 1 run
rm $0

Make puppetinst.sh executable by running the following command:
```
$ chmod +x /bin/puppetinst.sh
```
Disconnect from your reference WorkSpace and return to the WorkSpaces console by browsing to https://console.thinkwithwp.com/workspaces/.
In the left navigation pane, select WorkSpaces.
Check the box next to your reference system, and choose Actions.
Choose Create Image, and provide an image name and description.
Choose Create Image. This step takes several minutes.

Step 7: Create and deploy your new bundle

After your image has completed capturing, create a bundle:

In the left navigation pane, choose Images.
Check the box corresponding to your new image.
Choose Actions, Create Bundle.
Provide an image name and description, and set the bundle defaults.
Choose Create Bundle.

Using this bundle, deploy WorkSpaces:

In the left navigation pane, choose WorkSpaces, Launch WorkSpaces.
Select a directory. Make sure that the WorkSpaces in the corresponding subnets and security group can access your OpsWorks server.
Use Search to find the users to add, select the target users, and then choose Add Selected.
Choose Next Step.
Select your new bundle, and choose Next Step.
Make any desired changes to the Running Mode and Encryption settings, and choose Next Step.
Verify your settings, and choose Launch WorkSpaces.

Step 8: Approve access to your Puppet master in the Puppet Enterprise console

To ensure that only approved systems can communicate with your Puppet master, Puppet uses certificate approvals. Each time that Puppet presents a new system for certification, you can choose to approve or deny the connection.

Browse to your Puppet Enterprise console, and log in.
From the left menu, under SETUP, choose Unsigned certs.
If all the certificates correspond to systems to add, choose Approve All, otherwise, approve only the ones you want.

Summary

In this post, I showed you how you can use AWS OpsWorks for Puppet Enterprise to manage Amazon Linux 2 WorkSpaces at scale. Using this approach gives Linux WorkSpace administrators the same level of control they are used to with their Windows WorkSpaces.

Desktop and Application Streaming