Introducing AWS Toolkit for Visual Studio support for AWS SSO and Assume Role with MFA
The AWS Toolkit for Visual Studio uses locally stored credentials to help you develop, debug, and deploy .NET applications that use Amazon Web Services. These credentials inform the Toolkit which AWS account it is working with, and gate whether or not the Toolkit is allowed to perform actions against an account.
It is common for developers to locally store an IAM User’s access key ID and secret key in a credentials file. Some organizations have security postures that restrict developers from storing these keys locally, particularly if those credentials provide broad Administrator access to an AWS account. Developers in this situation haven’t been able to utilize the Toolkit while building on AWS. Version 126.96.36.199 of the Toolkit adds support for both Multi-factor Authentication (MFA) based credentials and AWS Single Sign-On (AWS SSO) based credentials. While these credentials types aren’t new, adding support for them in the Toolkit is. By using MFA and AWS SSO, you can improve the security around how the Toolkit accesses your AWS account.
In this article, I will set up two sets of credentials: one that makes use of MFA, and another that uses AWS SSO. Then, I show how to configure the Toolkit to use these credentials. The two credentials types are not related, so feel free to follow through either section separately.
Credentials that assume a role and require MFA have a stronger security posture than an access key ID + secret key pair. Part of the handshake process requires you to enter a unique code that is generated by an authentication device or app that you register with your account.
I’m going to walk through a basic MFA setup to show the basics, but this is not the only way to configure MFA. You’ll want to look through the documentation (listed later on) to make an IAM configuration that best suits your needs.
I’m going to create:
- An IAM Role that requires MFA access. This Role will not work without MFA, and will be configured with policies that allow me to perform my development work from the Toolkit, such as uploading a Lambda function and listing S3 buckets.
- An IAM User that is only permitted to assume the IAM Role mentioned above.
First, I will create an IAM Role with permissions for actions that I’d like to perform within the Toolkit.
I open the IAM Console, click Roles in the navigation bar, and click Create role. I click Another AWS account. I enter my account ID into the Account ID field (making sure I use my account ID — to look up your account ID, see Your AWS account ID and its alias). I check Require MFA to ensure this Role cannot be used without MFA.
I proceed to the Permissions page. Here you will select policies that match your needs. For this walk through, I would like to use the Toolkit to deploy Lambda functions, so I need access to Lambda, CloudFormation, S3, and IAM. At the time of writing, the policies that fit my needs were
AmazonS3FullAccess, so I clicked to add a check beside these policies. I click Next until I arrive at the Review page.
I name my role toolkit-role (you do not have to use this name, this name will be referenced in later steps), give it a description, confirm that the trusted entity is my account ID, and that my chosen policies appear. I click Create role.
The Role is created and I click to open it up. I copy the Role ARN for later use. I click on Trust relationships and can see that this Role will only be accessible by my account (under Trusted entities), and only with MFA (under Conditions).
Next I will make an IAM User that has permission to use this newly created Role.
I open the IAM Console, click Users in the navigation bar, and click Add user. I name my user toolkit-assumer (you do not need to use this name, it will be referenced in later steps), and check Programmatic access. I click Next to proceed to the permissions page.
The only action this IAM User should be allowed to perform is to assume our IAM Role. I click Attach existing policies directly and Create policy. I choose the STS service and only check the AssumeRole action. In the Resources section, I add the ARN of my toolkit-role IAM Role. In the Request conditions section, I check MFA required.
I click Next until I get to the Review policy page. I enter a name and description, and click Create policy.
Back on the page where I am creating my IAM User, I refresh the policy list, and see that it shows the policy that was just created. I click Next until I arrive at the review user page, and click Create user.
After the IAM user is created, I’m shown my access key ID and secret key. I copy these for use in a later step. Then I click Close.
We need to assign an MFA device to this user, so that it meets the conditions and policies where we have indicated that MFA is required. See Multi-factor Authentication for a list of supported authenticator apps under the Virtual MFA Applications section.
On the IAM Users page, I click into my newly created User. I click on Security credentials, find Assigned MFA device and click the Manage link next to it. I choose Virtual MFA device and press Continue. I set up the virtual MFA device by scanning the QR code into my authenticator app, enter the next two token codes produced by my app, then click Assign MFA. My IAM User is now set up with an MFA device.
Back where I clicked the “Manage” link, I copy the ARN of my assigned MFA device (it looks something like
arn:aws:iam::MY-ACCOUNT-ID:mfa/toolkit-assumer) for use in a later step.
I have now set up an IAM User and Role that I can use with the Toolkit. I am finished with the AWS console and close it.
I open my shared AWS credentials file (located at
%USERPROFILE%\.aws\credentials), and I type in a profile for my toolkit-assumer user and another one for my toolkit-role role. It looks like this (The profile names are for illustrative purposes only and could be called something else):
[toolkit-assumer] aws_access_key_id = AKIAIOSFODNN7EXAMPLE aws_secret_access_key = wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY [toolkit-role] source_profile = toolkit-assumer role_arn = arn:aws:iam::MY-ACCOUNT-ID:role/toolkit-role mfa_serial = arn:aws:iam::MY-ACCOUNT-ID:mfa/toolkit-assumer
My toolkit-assumer profile is configured with the access key ID and secret key from my new user (which also happens to be called toolkit-assumer). This IAM User only has the ability to assume the specific role that we created, and it can only do so with a valid code from the user’s MFA device. As a result, we’ve greatly reduced the risk associated with locally storing these keys.
My toolkit-role profile is configured as follows:
- I want to assume my IAM Role toolkit-role, so I assign that role’s ARN to the
- I want the toolkit-assumer profile to perform the assume role action, so I put that profile name in the
- I want to use the MFA device associated with the toolkit-assumer IAM User, so I assign the MFA Device ARN to the
Now in Visual Studio, I select the toolkit-role credentials from the Toolkit’s AWS Explorer. I am prompted for an MFA code, which I look up in my authenticator app and type in. I then have access to my account’s resources the same as I do when using basic credentials.
If you’re interested in reading more about IAM Roles, MFA, and configuration, the following may come in handy:
- Creating a role to delegate permissions to an IAM user
- Using an IAM role in the AWS CLI
- Configuring MFA-protected API access
AWS SSO based credentials have a stronger security posture than an access key ID + secret key pair. Part of the handshake process requires you to log in through a browser to an SSO portal, and permit applications to access these credentials.
There are a variety of ways to configure SSO. In my AWS account, I’m going to create a simple identity source and SSO login. This will allow me to perform SSO based logins to obtain AWS credentials from the AWS Toolkit (and from other applications that support AWS SSO based credentials).
To start, I open the AWS Single Sign-On console. I set my region to us-west-2, where I want this SSO configuration to be based (later on when we configure credentials, this will be the
sso_region field). I haven’t set up SSO before in this account, so I click Enable AWS SSO. I set up an identity source by clicking Choose your identity source, and see that “AWS SSO” is already the identity source. I copy the User portal URL so that I can use it later when I configure my credentials (this will be the
sso_start_url field). This URL looks something like
I need to set up a user that can log in to the SSO portal url, so I click Users in the side navigation, then Add user. I fill in the Username, Email address, and name fields, and check Generate a one-time password. I click Next to the groups page. For this simple set up, I skip setting up a group and click Add user. I take note of my Username and password, which I will use whenever I log into the portal shown in User portal URL. I click Close.
This newly created SSO login can be used to log into the SSO portal, but does not have access to anything in my AWS account. To configure this access, I click AWS accounts in the side navigation. I need to define what permissions this login can have, so I click Permission sets , then Create permission set. At this point, you would configure a permission set to suit your needs without being overly permissive. For this example, I am setting up my login to enable general development, so I click Use an existing job function policy and Next. On the policy page, I click SystemAdministrator and then Next until I reach the Review page. I click Create. Now I have a SystemAdministrator permission set defined that I can associate with my login. I make note of this permission set name for use when I configure my credentials (this will be the
From the AWS Accounts page, I click AWS organization, where I can associate my SSO login with my AWS Account. I click the checkbox next to my name, then Assign users. I click the checkbox next to the SSO login I recently created, then click Next. On the permission sets page, I click the checkbox beside my permission set (SystemAdministrator), then Finish. I’m shown a summary page, which indicates that my login is associated with my permission set and my AWS account. I copy down the account ID shown here for when I configure my credentials (this will be the
sso_account_id field). I click Proceed to AWS accounts to return to the AWS SSO console.
I have now set up an AWS SSO login that I can use with the Toolkit. I am finished with the AWS console and close it.
I open my shared AWS credentials file (located at
%USERPROFILE%\.aws\credentials), and I type in a profile that allows me to log into my SSO portal and request SystemAdministrator access. It looks like this (The profile name is for illustrative purposes only and could be called something else):
[toolkit-sso] sso_account_id = MY-ACCOUNT-ID sso_region = us-west-2 sso_role_name = SystemAdministrator sso_start_url = https://d-xxxxxxxxxx.awsapps.com/start
My toolkit-sso profile is configured as follows:
sso_account_idis the AWS account ID of the account I have associated an SSO login with
sso_regionis the region my SSO portal was created in
sso_role_nameis the SSO role (permission set) that this credentials profile will request when logging in
sso_start_urlis my account’s AWS SSO portal that I will be prompted to log into when the Toolkit wants to get credentials for this profile
Now in Visual Studio, I select the toolkit-sso credentials from the Toolkit’s AWS Explorer. I am prompted to start the SSO login procedure.
I could go to the indicated URL myself, and enter the provided code when prompted, but the Toolkit will do this for me automatically. This URL and Code combination represents the Toolkit’s request for credentials from AWS SSO based on the profile I created. I click OK, and the Toolkit opens a browser to my SSO portal URL. I log in with the SSO user and password that I created earlier. The SSO portal asks me to allow or deny whether the Toolkit can connect to this account (at the time of writing, the SSO portal identifies these login requests as “AWS CLI”).
I click Sign in to AWS CLI, and my Toolkit is allowed to obtain credentials. I close this browser tab. I now have access to my account’s resources.
To learn more about AWS SSO, check out the following pages:
The AWS Toolkit for Visual Studio has added support for credentials types that avoid the use of locally stored credentials secrets. In this article, we’ve seen how you can connect the Toolkit to your AWS account using MFA and SSO based credentials. If you have feedback on the AWS Toolkit, we would love to hear from you over on our GitHub repo at https://github.com/aws/aws-toolkit-visual-studio.