Hey there Enterprise Administrator!

Avoid storing AWS API keys by using Windows authentication instead[/caption]

• Are you an Enterprise investigating AWS?
• Don’t want to become a security news story like these guys? https://www.google.co.uk/search?q=news+aws+secret+access+key+hack
• Are you used to multiple levels of physical and logical security for access to your equipment? https://www.youtube.com/watch?v=_qc5TG2ulx8
• Is access to your VPC config shielded by nothing but some AWS API credentials? (which are probably stored in plain text..)
• Can your AWS credentials be used from the public internet (instead of only from the Office)?

Then here’s what you do: Go into AWS IAM and delete all those risky IAM accounts and their API keys.  Instead, reuse your internal directory for access to the AWS web console and AWS API! Use temporary AWS sessions and keys that are created on demand! It takes a little setting up, but I think its worth it. I described configuring AD authentication for AWS console  in my last post.  Since then we’ve got AD authentication for AWS API working too. We’re now able to remove our IAM accounts, save for one for a billing reporting service and a break glass account (secured by gemalto token) in case we need to fix AD authentication in future.

AD authentication for AWS API

So how to get hold of the AWS access key and secret access key required to sign AWS API calls? The process for gaining a temporary session with API keys is as follows. Follow through with the diagram in this post:

1. AWS account is configured to trust ADFS server for authentication. See AD authentication for AWS console.
2. AWS IAM roles are configured with trust policies entitling users in specific AD groups to assume IAM roles
3. IT or development staff use an “enterprise PC”. This machine is a member of the active directory domain. They’re logged in using their domain ID and password.
4. Fetch the latest version of your AWS authentication PowerShell module from source control and import it.
5. PowerShell is configured to reuse current logged on user’s credentials with internet proxy and reuse current logged on user’s credentials with intranet sites. No credentials are stored in configuration files.
6. Enterprise PC auto discovers internet proxy via Web Proxy Auto detection protocol (WPAD). No need to hardcode proxy address and port in AWS scripts. See WPAD tag for my other posts on this topic.
7. PowerShell requests a SAML response from ADFS server. PowerShell automatically authenticates with ADFS web service using current logged in user’s credentials
8. SAML response (XML document) is examined to extract IAM role Amazon Resource Names (ARNs)
9. AWS PowerShell SDK uses SAML response and ARNs with Use-STSRoleWithSAML command to request a temporary session from AWS STS (this API call is unsigned and does not require AWS API keys).
10. A temporary session is received. By default the session is valid for 60 minutes.
11. Temporary AWS keys are collected from the temporary session and used with the set-awscredentails command
12. PowerShell can now interact with Amazon API until the session expires

The magic happens when you run the Use-STSRoleWithSAML command.

See the attached AssumeRolewithSAML

 PowerShell example script which will help you get started. Snippet from the example script below:

$session= Use-STSRoleWithSAML -RoleArn $AWSRoleARN -PrincipalArn $AWSRolePrincipalARN `
    -SAMLAssertion $SAMLResponse -AccessKey "RequiredButNotUsed" -SecretKey "NotUsedEither" 

Set-AWSCredentials -Verbose -AccessKey $session.Credentials.AccessKeyId -SecretKey $session.Credentials.SecretAccessKey `
    -SessionToken $session.Credentials.SessionToken 

Find more IT Infrastructure tips at blog.alexmags.com