Overview
Amazon WorkSpaces Applications offers non-persistent virtual desktops as a service, including Windows and Linux based offerings. At the time of writing, WorkSpaces Applications offers RHEL 8 (Red Hat Enterprise Linux 8), Rocky 8, and Amazon Linux 2.
When logging into a Linux-based WorkSpaces Applications Fleet that is not using Active Directory, end users will be running as a local account named as2-streaming-user . This account will not have sudo privileges. There is not a built-in method to add sudo privileges to end users of WorkSpaces Applications Fleets. This article will show you how to grant sudo permissions to the as2-streaming-user .
On Linux, sudo permissions are equivalent to being a member of the Local Administrators group in Windows. With Windows-based WorkSpaces Applications instances, there are two ways for customers to easily grant local administrator permissions. On Linux-based WorkSpaces Applications instances, it is slightly more challenging to grant sudo permissions, since there is not a GUI tool. This can be challenging for some deployments, since some end user personas, especially technical ones, might require sudo for their work.
This article does not cover granting sudo rights to Active Directory groups, as this article does not cover Linux WorkSpaces Applications instances joined to Active Directory. There will be a companion article for domain joined Linux WorkSpaces Applications instances (see the Series links at the top and bottom of the article).
Important Security Consideration
CAUTION: This method will apply sudo rights to any user, at the image level. It should therefore be used with caution. When capturing an image in this configuration, be sure to note in the Description/tags that it includes the sudo permissions modification. You would not want to accidentally use this image with users you do not intend to have sudo privileges.
Prerequisites
For this walkthrough, you should have the following prerequisites:
- Pre-existing Linux WorkSpaces Applications deployment.
Getting Started
To begin, you will need to launch an image builder instance.
- If you do not already have a Linux based WorkSpaces Applications Image Builder: follow the steps at Launch an Image Builder .
- If you do have a pre-existing Linux image builder: you can simply Start it instead of launching a fresh Image Builder.
Creating the Sudoers Permissions File
As a reminder: when using WorkSpaces Applications within Chrome or Edge, copy and paste will work seamlessly. If using WorkSpaces Applications within Firefox, you will need to use the Clipboard icon in the WorkSpaces Applications toolbar to send text via copy and paste.
On Linux, sudoers membership is determined by either the account's presence in the /etc/sudoers file, or else by being defined individually as a file within /etc/sudoers.d/ . It is a best practice to add each individual user or group that requires membership to the /etc/sudoers.d/ directory as an individual file, rather than by modifying the main /etc/sudoers file.
- Open the Terminal window (select the Applications menu in the top left corner, and you will see the Terminal icon appear in the center left of the screen). You can also enter "Terminal" in the resulting text box.
- Paste the following command into the Terminal. You can use the "copy" icon in the code block to easily copy the entire block.
echo 'as2-streaming-user ALL=(ALL) NOPASSWD:ALL' | sudo tee /etc/sudoers.d/10-as2-streaming-user > /dev/null && sudo chmod 640 /etc/sudoers.d/10-as2-streaming-user && sudo chown root:root /etc/sudoers.d/10-as2-streaming-user
At this point, you have finished making the necessary changes on the Image Builder to give users sudo permissions. If your image already contains all the required customizations/applications, and they are up to date, you can now create an image from this Image Builder and use it in your Fleet.
If you need to run any updates, install applications, or make more customizations, now is a good time to do so.
Creating the Image
When you are ready to create the image, you can do so in the same Terminal window. If you need a reminder of the syntax, you can run AppStreamImageAssistant create-image --help to see the command's syntax in detail. If you would like an example of a create-image command which includes a tag showing sudo permissions:
AppStreamImageAssistant create-image --name ExampleName --use-latest-agent-version --no-enable-dynamic-app-catalog --tags Key=Sudo,Value=Yes
You do not need to use these precise arguments (for example, you may want a dynamic app catalog, required if you use Application View on your Fleet, or you might want the image pinned to the same agent version it was created on).
Placing the image into production
To use the resulting image in Production, replace it in your Fleet configuration. If you would like the changes to be rolled out as fast as possible, you will need to Stop and Start your WorkSpaces Applications Fleet. See these two documentation pages for more information:
Rollback
If you would like to remove these permissions from the image builder later, you can run sudo rm /etc/sudoers.d/10-as2-streaming-user from a terminal session on the same image builder. Then, create a new image, and replace the image in your Fleet with this new image, as before.
Conclusion
You can now use this article to grant your Linux based WorkSpaces Applications end users sudo permissions on your WorkSpaces Applications fleets. This enables users to perform actions they could not do otherwise, and is required for some highly technical user personas.
Loading article