Desktop and Application Streaming

Accessing AWS resources using AWS IAM Roles Anywhere from Amazon WorkSpaces

Amazon WorkSpaces Personal provides a secure, persistent desktop computing environment in the cloud. Customers often ask if there is a method to configure WorkSpaces to use AWS Identity and Access Management (IAM) Roles to issue temporary credentials. In this blog, we explain how you can configure WorkSpaces to use AWS IAM Roles Anywhere and enable granular access to AWS resources and services. AWS IAM Roles Anywhere provide the ability to obtain temporary security credentials in IAM.

Time to read 10 minutes
Time to complete 2 hours
Cost to complete (Estimated) $50 per private CA per month for short-lived certificate mode; $0.058 per certificate issued to WorkSpaces users
Learning level 400
Services used Amazon WorkSpaces; AWS IAM Roles Anywhere; AWS Private Certificate Authority; Amazon Simple Storage Service (S3); Amazon CloudFront; AWS Directory Service

Overview of the solution

Figure 1: Architecture and end to end workflow

Figure 1: Architecture and end to end workflow

For users of Amazon WorkSpaces, the process to obtain temporary AWS credentials from the Simple Token Service (STS) involves several steps. Users use a certificate, which is automatically generated for them via group policy, to verify their identity. The certificate is exchanged for an STS token, which is used to make AWS API requests.

  1. Certificate auto-enrollment group policy is applied to WorkSpaces users via Active Directory (AD).
  2. Amazon WorkSpaces requests user certificate template information from AWS Private Certificate Authority (AWS Private CA) Connector for AD.
  3. AWS Private CA Connector for AD authenticates the request via AD connector.
  4. AWS Private CA Connector for AD sends the user certificate template information to the WorkSpaces. WorkSpaces sends the certificate signing request to the AWS Private CA Connector for AD.
  5. AWS Private CA Connector for AD requests the user certificate from AWS Private CA.
  6. AWS Private CA Connector for AD issues the user certificate to the WorkSpace.
  7. User uses aws_signing_helper tool which manages the process of creating a signature with the certificate and calling the endpoint to obtain session credentials.
  8. IAM Roles Anywhere validates the signature.
  9. User receives temporary security credentials.

Prerequisites

  • A root certificate authority running on Microsoft Active Directory Certificate Services.
  • Existing Amazon WorkSpaces (Windows) infrastructure configured with AD Connector.
  • Your WorkSpaces must reside in the same AWS Account as the AWS Private CA. We will deploy AWS Private CA in step 2 of this blog.
  • OpenSSL must be installed on the WorkSpace and path added to the Path environment variable.
  • AWS CLI or any preferred code editor installed on WorkSpaces.
  • Delegate permissions to the AD connector service account using PowerShell script.

Configure AWS IAM Roles Anywhere for Amazon WorkSpaces Personal

Step 1: Setup Certification Revocation List for AWS Private Certificate Authority

  1. Navigate to the Amazon S3 console.
  2. Create an Amazon S3 Bucket, keep ACLs disabled, and block all public access. Refer to the security best practices for Amazon S3.
  3. Navigate to the CloudFront console and choose Create distribution.
    • For Origin Domain, select the S3 Bucket created in point 2.
    • For Origin access, select Origin access control settings (recommended).
    • For Origin access control, choose Create new OAC.
    • For cache policy select Caching Disabled.
    • Under Web Application Firewall (WAF) select Do not enable security protections.
    • Choose Create distribution.
    • Note the Distribution Id for your deployment, and the distribution domain name (Domain name column) from the list of distributions. You can also find the distribution domain name on the General tab for a selected distribution.
  4. Navigate to S3 console, choose the S3 bucket you created from the list, navigate to the Permissions tab, choose Edit in the Object ownership section, and select Bucket owner preferred.
  5. On the Permissions tab, select the Bucket Policy, choose Edit. Enter the following policy. Replace the, PARTITION, S3-BUCKET-NAME, AWS-ACCOUNT-NUMBER, and CLOUDFRONT-DISTRIBUTION ID ARN and choose Save.
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "acm-pca.amazonaws.com"
            },
            "Action": [
                "s3:PutObject",
                "s3:PutObjectAcl",
                "s3:GetBucketAcl",
                "s3:GetBucketLocation"
            ],
            "Resource": [
                "arn:PARTITION:s3:::S3-BUCKET-NAME/*",
                "arn:PARTITION:s3:::S3-BUCKET-NAME"
            ],
            "Condition": {
                "StringEquals": {
                    "aws:SourceAccount": "AWS-ACCOUNT-NUMBER"
                }
            }
        },
        {
            "Sid": "PolicyForCloudFrontPrivateContent",
            "Effect": "Allow",
            "Principal": {
                "Service": "cloudfront.amazonaws.com"
            },
            "Action": "s3:GetObject",
            "Resource": "arn:PARTITION:s3:::S3-BUCKET-NAME/*",
            "Condition": {
                "StringEquals": {
                    "AWS:SourceArn": "CLOUDFRONT-DISTRIBUTION ID ARN"
                }
            }
        }
    ]
}

Step 2: Create Subordinate CA using AWS Private Certificate Authority

  1. Navigate to the AWS Private CA console.
  2. Choose Create a private CA.
  3. In the Mode option, select Short-lived certificate.
  4. In the CA type option, choose Subordinate.
  5. In the Subject distinguished name options, enter the details as required. For Common name (CN) enter for example: SubCA.<YourDomainFQDN>
  6. For Key algorithm options select RSA 2048.
  7. For Certificate revocation options,
    • Choose Activate CRL distribution.
    • Uncheck Create a new S3 bucket.
    • For S3 bucket URI, browse the S3 bucket created in Step 1 SubStep 2.
    • Under CRL settings > Custom CRL Name > Enter the CloudFront Distribution Domain Name created in Step 1 SubStep 3.
    • For Pricing, select the check box to acknowledge the pricing.
    • Choose Create CA.
  8. Follow the section “Configure Microsoft ADCS” first and “To deploy and sign the ACM PCA’s certificate” section next, in how to incorporate AWS Private CA into your existing Windows Active Directory Certificate Services blog to configure AWS Private CA further.

Step 3: Configure AWS Private CA Connector for Active Directory

With AWS Private CA Connector for Active Directory, you can issue certificates from the AWS Private CA to Active Directory objects for authentication and encryption. When you create a connector, AWS Private CA creates an endpoint in the VPC for your directory objects to request certificates.

  1. Navigate to the AWS Private CA Connector for Active Directory console.
  2. Choose Create connector.
  3. For Active Directory type, choose On-premises Active Directory with AWS AD Connector and choose your AD Connector directory from the list.
  4. Under Select security groups for VPC endpoint, choose a security group from the list or create a new one. The security group should allow TCP and UDP port 443 in the inbound rules from WorkSpaces subnets. See configure security group rules to configure the inbound rules.
  5. In the Private certificate authority, select the Private CA created in Step 2.
  6. Choose Create connector.
  7. Make a note of the Certificate enrollment policy server endpoint. We need this when we configure the Group Policy in Step 5.

Step 4: Create certificate template in AWS Private Certificate Authority

To issue certificates, you create a connector and AD-compatible certificate templates for the connector. When you create a template, you can set enrollment permissions for your AD groups. We have chosen default values for Validity and Renewal period but you can modify them per your requirements.

  1. Navigate to the AWS Private CA Connector for Active Directory console.
  2. Select the Connector for Active Directory that you created in Step 3 and choose View details.
  3. Under Templates select Create template.
  4. For Template creation method select Start from a predefined template then select User Signature from drop down.
  5. Under Template settings:
    • For Template schema version select Template version 4
    • For Client compatibility select Windows 8 & Up / Windows Server 2016 & Up
  6. Under Certificate settings:
    • For Certificate type select User.
    • For Auto-enrollment select Turn on auto-enrollment
    • For Validity period select 7 days.
    • For Renewal period select 1 day.
    • For Subject name select Common name and select Email.
    • For Subject alternative name select Email and User principal name (UPN).

Note: If the email attribute is not configured for the user in Active Directory, uncheck the email box for both Subject name and Subject alternative name.

  1. Under Certificate request handling and enrollment options:
    • For Certificate purpose select Signature.
    • Select Exportable private key.
    • For Set input and prompt requirements select No user input required.
  2. For Key usage extension settings leave defaults.
  3. For Application policies leave defaults.
  4. For Cryptography settings, leave defaults.
  5. Create or use an AD group in Active Directory which contains users who can auto-enroll for the certificates. This way you can control which users can enroll certificates and request temporary credentials from IAM Roles Anywhere.
  6. For Groups and permissions select Add new groups and permissions. Enter the following information:
    • Display name: Enter the name of the AD group you created in step 11.
    • Security identifier (SID): Enter the SID of the AD group.
    • Enroll: Select Allow.
    • Auto-enroll: Select ALLOW.
  7. Choose Create Template.

Step 5: Configure certificate auto enrollment using Group Policy Object (GPO)

  1. From a Windows machine or WorkSpace that has Group Policy Management installed, open the Group Policy Management console.
  2. Select the Organization Unit where your WorkSpaces are located.
  3. Open the context (right-click) menu for the Organization Unit. Select Create a GPO in this domain, and link it here and enter the GPO name.
  4. Open the context (right-click) menu on the GPO and select Edit.
  5. In Group Policy Management editor, navigate to Computer Configuration > Administrative Templates > System > Group Policy > Configure user Group Policy loopback processing mode.
  6. Open the context (right-click) menu for Configure user Group Policy loopback processing mode and select Edit.
  7. Select Enabled. For Mode, select Merge. Select OK.
  8. In Group Policy Management editor, navigate to User Configuration > Policies > Windows Settings > Security Settings > Public Key Policies. Follow the procedures outlined from step 7 to step 21 to configure the Public Key Policies for User Configuration in Configure AD policies.

Step 6: Create Trust Anchor

To use IAM Roles Anywhere for authentication to AWS Services from WorkSpaces, you first create a trust anchor and profile through the IAM Roles Anywhere console. You establish trust between IAM Roles Anywhere and your certificate authority by creating a trust anchor.

  1. Navigate to the IAM Roles Anywhere console.
  2. Choose Create a trust anchor.
  3. For Trust anchor name, enter a name.
  4. Select AWS Private Certificate Authority and choose the Private CA you created in Step 2.
  5. (Optional) create tags and choose Create a trust anchor.

Step 7: Create IAM Role to be assumed by WorkSpaces users

  1. Navigate to the IAM Console.
  2. Choose Create Role.
  3. Choose Custom Trust Policy, paste the below policy in the editor and choose Next. Replace the Certificate Issuer Common Name with Common Name of the AWS PCA you created in STEP 2. Replace the Trust Anchor ARN with trust anchor you created in STEP 6 in the below trust policy.
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "rolesanywhere.amazonaws.com"
            },
            "Action": [
                "sts:AssumeRole",
                "sts:TagSession",
                "sts:SetSourceIdentity"
            ],
            "Condition": {
                "StringEquals": {
                    "aws:PrincipalTag/x509Issuer/CN": "Certificate Issuer Common Name"
                },
                "ArnEquals": {
                    "aws:SourceArn": "Trust Anchor ARN"
                }
            }
        }
    ]
}
  1.  On the Add permissions page, add your desired policy. We have used AmazonS3ReadOnlyAccess policy as an example for this blog. Select the policy and choose Next.
  2.  For Role Name, enter a name and choose Create Role.

Note: By default, the maximum session duration for roles that are assumed is 1 hour. See Modifying a role maximum session duration to modify the session duration.

Step 8: Create Profile

  1. Navigate to IAM Roles Anywhere console.
  2. Choose Create a profile.
  3. Enter a Profile name.
  4. For Roles, select the role you created in Step 7. Your role will not appear in the list if it does not have IAM Roles Anywhere as a trusted entity.
  5. (Optional) You can select session policies. Session policies limit the permissions granted by the role’s permissions policy and are assigned to the role session when the role is assumed.
  6. Choose Create a profile.

Step 9: Use/Assume IAM Role from WorkSpaces

IAM Roles Anywhere provides a credential helper tool that can be used with the process credentials functionality that all current AWS SDKs support. This simplifies the signing process for the applications. See the IAM Roles Anywhere documentation to learn how to get the credential helper tool. You can use the PowerShell script to automate the credential configuration on the WorkSpaces. This script configures the %userprofile%\.aws\config file in user’s profile which allows you to assume role with temporary credentials to make the API calls. To run the script, run the below command from the directory where you downloaded the script. Make sure to replace the Profile ARN, Role ARN and Trust Anchor ARN in the command.

.\assume-role.ps1 -ProfileARN "Profile ARN" -RoleARN "Role ARN" -TrustAnchorARN "Trust Anchor ARN"

Note: As a security best practice, it is your responsibility to secure the certificate’s private key used to request the temporary credentials from IAM Roles Anywhere. In the PowerShell script we have secured the private key by setting the ACL (NTFS permission) for WorkSpaces user only and disabling the inheritance.

Step 10: Test the setup

To verify that the config works as expected, run theaws sts get-caller-identity --profile iamrolesanywhere AWS CLI command and confirm that the assumed role is what you configured in IAM Roles Anywhere. You should also see that the role session name contains the Serial Number of the certificate that was used to authenticate. Finally, you should have read permissions for S3.

Revoke a certificate

A certificate may need to be revoked if its private key has been compromised. You can revoke the certificate using AWS CLI or API. See Revoking a private certificate.

Revoke IAM role temporary security credentials

If a user’s temporary credentials have been compromised, that party has access to AWS resources for the duration of the session. You can revoke the temporary credentials before a specific duration. See Revoking IAM role temporary security credentials.

Cleaning Up

To avoid incurring additional charges in your AWS Account, delete any resources that you created as part of this blog post.

  1. In the AWS Private CA Console, delete the Private CA if you created one for this exercise.
  2. In the CloudFront Console, delete the CloudFront Distribution if you created one for this exercise.
  3. In the AWS Private CA Connector for AD Console, delete the Connector for AD if you created one for this exercise.
  4. In the Amazon S3 console, delete the S3 bucket if you created one for this exercise.

Conclusion

In this post, you learned how to configure AWS IAM Roles Anywhere with Amazon WorkSpaces to enable granular access management of AWS resources and services from within Amazon WorkSpaces. The key goal of configuring IAM Roles Anywhere is to provide secure, granular access to AWS resources from Amazon WorkSpaces without storing IAM user credentials on the WorkSpace. Using temporary credentials, you can provide access to your AWS resources to users without having to define an AWS identity for them. The temporary security credentials have a limited lifetime, so you do not have to update them or explicitly revoke them when they’re no longer needed. We outlined the IAM Roles Anywhere credential request workflow. By combining IAM Roles Anywhere with AWS Private CA, and short-lived certificate mode you reduce reliance on storing IAM user credentials on device and streamline the end user experience. Get started with Amazon WorkSpaces today.

Nityanand Singh is a Senior Specialist Solutions Architect based in London. He has been working with AWS for more than seven years and enjoys collaborating with customers to help build optimal EUC solutions on AWS.
Mayank Jain is a Cloud Support Engineer in AWS Support Engineering who specializes in End User Computing Services. He is SME for Amazon Workspaces and Appstream 2.0 services and loves helping customers on all things EUC.