Since the very early days of AWS (around 2006), if you’ve wanted to interact with one of the services through an API you’ve needed to authenticate yourself. This over the years has been achieved using a couple of methods of request signing even before the days prior to the Identity and Access Management (IAM) service.
IAM was introducted in 2011 as a way to manage user and group identitys within AWS and assign those identities permissions for interacting with services. In late 2011, AWS added a method to federate identities using external identity providers, as well as introduce the Security Token Service (STS) allowing short term temporary credentials.
Prior to STS, and until recently, if you wanted to access temporary credentials for a role (and you’re not a human user), you’ve needed to statically configure a pair of Access Key and Secret Access Key, connected to an IAM user and then call AssumeRole to get temporary role credentials. There have been many instances of people having their credentials compromised by leaving them in code or accidentally checking them in, and in general having to manually rotate and manage those credentials is a big operational pain.
Recently, AWS has been extending the cloud on-premise though services like EKS Anywhere (a service that lets you manage an on-premise Kubernetes clusters using the EKS console) and as such we’ve found ever increasing needs to have persistent machine identities acquire AWS credentials. More machines to manage, meaning more credentials to rotate and pain and risk. There are some solutions like having a local OIDC provider and ferating that with IAM aws/amazon-eks-pod-identity-webhook but they are unweildly to set up.
Enter IAM Roles Anywhere.
IAM Roles Anywhere is a new service from AWS, that allows on-premises workloads (or more accurately, workload not on AWS) to authenticate with IAM using public key infrastructure (PKI) using certificates. The service allows your certificate authority (CA) to establish trust with your AWS account, and acquire temorary role-based credentials by exchanging the certificate for STS issued credentials.
To get started, you'll need an AWS account as well as a Certificate Authority (CA) capable of issuing certificates. AWS have a service for this with AWS Private CA (although it's not cheap at ~ USD $400/mth), or you can provide your own existing CA certificate trust chain if you have one already (say from AD Certificate Services etc).
For my home lab, I use SmallStep's DevOps offering because it's free and very easy to set up! I won't detail the setup here, but once I had a CA root certificate and issued a certificate to my laptop in this case, getting credentials was trivial. Following along with the instuctions, I was able to create a Trust Anchor and Profile, and associate those with a role. I downloaded the signing helper and away I went!
So what does this really mean?
This service certainly isn't a silver bullet for doing away with having to rotate credentials. Does IAM roles anywhere deliver on it's promise to allow short term credentials for AWS from anywhere; sure! But remember, you've still got to deal with rotating the certificate you've used to claim those credentials. If you don't have infrastructure to handle that process, you are only marginally better off. Why? Because you're using PKI trust chains to establish trust between your CA, but the static credentials (that is the private key/cert pair) on the client still need managing. At the moment I'd suggest it's trading problems if you're looking to not manage IAM user access keys.
I see this as an excellent option for use cases like the following: * Connecting applications in enterprise on-premises environments (think AD CS machine certificates) * Connecting IoT Devices or other things to AWS * Obviously EKS anywhere * Connecting other cloud environments to AWS (think Azure Enterprise Apps)
Beyond that, right now - I think the use is limited as it is a reasonably niche service. If you've got interesting or novel use cases I'd love to hear about them! I should also say, I'm not being critical of the service. It's very exciting to see AWS finally provide more sensible ways to interact with the APIs beyond IAM users. I look forward to seeing where the IAM team are going with this direction!