AWS API¶
There are multiple ways of using the AWS API directly from your application or as a human user:
- from AWS itself -> start a server with an appropriate IAM role (with a policy allowing the API calls)
- as a human user -> use Mai to generate a temporary access key
- from external systems -> use either a AWS “proxy” system (see 1.) or create an robot IAM user with access keys and key rotation
- from another AWS account -> use cross-account trust relationship with IAM roles and access the AWS API of account B from account A
From AWS itself¶
Every Amazon SDK (Java SDK, Python SDK, etc) is able to automatically use temporary access credentials on EC2 instances.
You simply have to start the EC2 instance with the appropriate IAM role (via EC2 instance profile).
Our Senza deployment tool supports the IamRoles
property on the Senza::TaupageAutoScalingGroup directly.
Important
Sadly many web pages and tutorials still write about using access keys with Amazon SDKs on AWS. Please always use EC2 instance profiles for your application if it needs to call AWS APIs.
You should never need to handle access keys on AWS! You should not even mention something like ‘access keys’ in your code, else you’re doing it wrong.
As a Human User¶
Temporary access credentials for SAML users can be generated by Mai. Mai will store the credentials in the default ~/.aws/credentials
location which
is automatically used by any of the Amazon SDKs.
If you run a tool from your desktop and it should use your credentials, then use mai
to get API access keys.
From External Systems¶
The preferred way is to create a well defined REST API microservice and deploy it on AWS with instance profile (see Senza::TaupageAutoScalingGroup) and secure it via OAuth. Thus your external system (e.g. own data center) can access it without any AWS knowledge at all. This is a possible way for 90% of the use cases.
Only if this is not feasible you should consider creating IAM users with an access key rotation process.
From Another AWS Account¶
IAM roles can be used across accounts by defining a trust relationship policy.
Policy configuration:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::ACCOUNT_ID:root"
},
"Action": "sts:AssumeRole"
}
]
}
if the role is also used by an application, to retrieve via Instance Profile the credentials, then you should also add the ec2 service:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"Service": "ec2.amazonaws.com",
"AWS": "arn:aws:iam::ACCOUNT_ID:root"
},
"Action": "sts:AssumeRole"
}
]
}
As result you will have one Trusted Entity for the first option and two for the second one.
Trusted Entities:
- The account ACCOUNT_ID
and for the second option also
- The identity provider(s) ec2.amazonaws.com
This will let you retrive credentials from the Instance Profile.