8 minutes reading time
Over the years I've managed a number of servers for work. Some of which connect to AWS resources (S3, EC2, Glacier, etc). Often the credentials were just strings stored in environment variables or a file the ./aws folder (with restricted permissions of course). These long-term credentials work but Amazon also provides a way to get temporary credentials.
You can use AWS Identity and Access Management Roles Anywhere to obtain temporary security credentials for workloads such as servers, containers, and applications that run outside of AWS.
These jobs an use the same IAM policies and roles as AWS applications to access resources. IAM Roles Anywhere mean you no longer need to manage long-term credentials for workloads outside of AWS.
Workloads must use x.509 certificates issued by your Certificate Authority (CA).
You establish trust between IAM Roles Anywhere and your certificate authority (CA) by creating a Trust Anchor. A trust anchor is a reference to either an AWS Private CA or an external CA certificate. There can be several trust anchors in one AWS account.
Workloads outside of AWS authenticate with your trust anchor using certificates issued by your trusted CA. This lets you get temporary credentials.
IAM roles are IAM identities that you create in your account with specific permissions. For IAM Roles Anywhere to be able to assume a role and deliver temporary AWS credentials the role must trust the IAM Roles Anywhere service principal. (aws:SourceArn must be set to the Trust Anchor's ARN )
Profiles specify the roles IAM Roles Anywhere can access and what outside Workloads can do with the temporary credentials.
So basically we need the following things:
aws_signing_helper so my Python scripts can get temporary credentials.A key part of Roles Anywhere is proving your job / workload is who you say it is. This is done with signed certificates.
As a developer and Sys-Admin I've often needed self-signed certificates for various projects. I have some notes on creating a certificate authority and signing certificates here.
Important if you want to re-issue to the same name, update text.txt.attr to look like
unique_subject = no
First setup a folder for client certificates
Make a signing request and private key in the folder
and sign it with the CA
This will create a certificate file named ggblog_clicert.pem. You will use this certificate and the private key to request temporary credentials once Roles Anywhere is setup.
If you want to set the validity period of the script instead of using the default value, use the -days flag.
You may not need to do this step. I'll depend on the permissions your AWS account has. When I setup a new mail server for a client, I had to go add a policy letting the my account create a trust anchor.
Log in to AWS Management Console with an account that has the right privileges.
Navigate to IAM: Go to the IAM dashboard.
Go to policies on the left 
Press Create Policy
Select JSON and set it to the following
and press Next to go to the next screen.
GgblogAws) and press Create Policy 
Once the policy is created or updated, make sure it shows up in your policies
You may need to wait for policy changes to propagate through the system, as there can sometimes be a short delay.
Important Make sure you're in the right region when setting up your Roles Anywhere role. If things are missing, check your region
2. Press Create a trust anchor 3. Give it a name in Trust anchor name. I went with "GGBlogAws" 4. For the source go with External certificate bundle
Paste the contents of your CA PEM file into it. 
5. I skipped the optional data and went with Create Trust Anchor
You should now see your new trust anchor in the list
If your account doesn't have the role to actually create trust anchor you'll get an error like this:
User: arn:aws:iam::000000000000:user/balarm00 is not authorized to perform: rolesanywhere:CreateTrustAnchor on resource: arn:aws:rolesanywhere:us-east-1:000000000000:trust-anchor/* because no identity-based policy allows the rolesanywhere:CreateTrustAnchor action
You or a user with permission will need to add a Policy for working with Trust Anchors to your account.
While AWS provides a policy that gives you full permissions on glacier resources, You might want to use custom policies to restrict the role to specific actions.
glacier:ListVaults and glacier:uploadArchive.
NOTE I have "Resource" set to *, which means the policy apply to all vaults. Which is OK for this blog post, but in the real-world you might want to restrict it to a specific value. You can use the ARN instead of "*" to restrict the resource
GgblogS3GlacierAfter creating the custom policy, it can be attached to the Roles Anywhere role you create.
To create the role, I navigated back back to Roles, scrolled to the bottom of the page, and pressed Manage under Roles Anywhere 
I selected Step 2. Configure roles and pressed Create a New Role 
And went with Custom trust policy. Here you'll edit the "Statement" section of the JSON 
ArnEquals ties this to the trust anchor. Your exact string will vary. You can get your Arn from the Trust Anchor page 
StringEquals ties this to the client certificate with OU == ggblog. This was set when the certificate request was generated.Press the next button to set the permissions. Since I want my roles anywhere jobs to access Glacier, I could add an existing policy 
Or use the custom policy I setup earlier by searching for it 
To finish up press Next again.
Give the new role a name. I went with "GgblogGlacierBackup" 
Then saved it by pressing Create Role.
A quick check under Roles shows it was created. 
This should now be usable
Also under Step 2 Configure roles is a Profiles section. Create a profile by pressing the Create a profile button 
I set the name to 'GgblogGlacierProfile' and set Role to 'GgblogGlacierBackup' 
press the Create a Profile button to save it.
Amazon's docs provide link to the AWS Signing Helper executable. Most of my servers are running Linux, so I downloaded the Linux helper.
Running help on it shows me the basic flags:
)
)
Which seems like a lot, but we don't need all of them.
The most important flags are the certificate flags and ARNs of the sites we just created.
You can get the ARNs from AWS console. The certificate and private key files were created earlier. You just need to copy them somewhere you jobs can use them.
To get the --role-arn value go to IAM > Rolws and search for your Role. Once found there's a link for copying it 
To get the profile and trust anchor ARNs, go to Roles > Roles Anywhere. It has a list of your trust anchors and profiles. Navigating to these lets you copy your ARNs 
Once you have your ARNs and certificates in place, you can call aws_signing_helper as follows.
If all went well, you get something that looks like this:
}
From here the temporary AccessKeyId, SecretAccessKey, and SessionToken can be used as needed with your scripts.