Authentication vs Authorization Explained in AWS Terms
Authentication is the process by which a software checks the credentials of a certain entity if it exists and is valid for use.
Authorization is the process by which a software checks if the logged in profile of a certain entity has enough permission to access specific resources on the system.
In AWS there are two ways of authentication and authorization depending on where the request came from. From here on out, we will refer to these two ways of authentication and authorization as tracks that the AWS API follows whenever authentication and authorization are required. The first track of authentication and authorization does not only apply to AWS EC2 but also to other AWS Full Managed Services which authenticates against the AWS IAM
Overall, these two tracks complements each other having different methods this ultimately adds security to your AWS Account. The first track is easier than the second track and relatively more secure since the credentials are not sent over the internet only through the AWS network. The second track is more convenient since it allows the user to use different authentication credentials compared to the single instance profile attached in the first track having these however makes the second track less secure since this method usually requires the credentials to be sent over the internet. The second track’s authorization process is easier to track compared to the first track’s authorization however in terms of authentication they are both straightforward.
The first track for authentication is straightforward. The AWS API starts with checking if the instance or another AWS Service has an instance profile (or something equivalent) attached to it. Then it uses the the AKID (AWS_Access_Key_ID) and ASAKID (AWS_Secret_Access_Key_ID) attached to the instance, usually this is found at 169.254.169.254/latest/meta-data/iam/info and 169.254.169.254/latest/meta-data/iam/security-credentials/ respectively. This is checked against the available credentials on AWS IAM. The checking of authentication is usually trivial since the authentication is done only against a single Instance Profile because there can only be a single instance profile attached to an EC2 instance that also makes more secure since during an audit the API call can easily be traced to a single instance profile.
The first track for authorization is done using attached IAM role holding the attached IAM role, the instance profile acts as the bridge between the IAM role and the EC2 instance. The statements which are inside the attached IAM role dictates whether an Instance can do a certain action to a specific AWS resource. From the console it seems like the IAM Role is attached directly to the instance however this is a porcelain-ish feature of AWS which simplifies the view for the user. Since these checks are done between AWS Resources, the credentials do not leave the AWS network which makes it more secure however the fact that an instance can only have one attached instance profile can sometimes be an inconvenience.
The second track for authentication is done either through a AKID, ASAKID validation or Username Password validation. This is usually sent over the internet except in the case that your datacenter has a direct connection to the AWS data center making it relatively less secure. Most of the time. these credentials are sent over using https which mitigates risk but it does not protect against MITM (man in the middle attacks) i.e. If an attacker has access to your browser and installs his own certificate in your browser.
The authorization for the second track is complicated, it can either be done through an AWS Assume Role API call or using an attached permission for the AWS User. The AWS Assume Role call uses a trust relationship between the AWS IAM role and the IAM User to check the validity of the call. Calling back the trust relationship means that the authentication layer is doubled. After assuming the role, the IAM user then have the privileges that the IAM role has this is convenient since it means that the IAM user can assume many roles and do many different AWS operations while only authenticating twice. The downside of this is it could be cumbersome to maintain and figure out which IAM roles a specific IAM users can use. The attached permission of the IAM User is considered to be the default permission that the IAM user can use without assuming any other IAM role. This is attached to the IAM User either by group inheritance or direct IAM policy attachment
Originally published at gist.github.com.
