Before reading this article, it would be useful to understand:
You can always read tons of nitty gritty AWS documentation here.
- AWS IAM (as discussed in the previous episode)
My adventure from last episode is continuing here by tying broad IAM concepts into some specific use cases with resources. As discussed in the previous episode, IAM (Identity Access Management) is an AWS service that, basically, allows us to manage access to our AWS resources. This includes controlling whether and which users can access any of our resources, as well as what can be done with those resources, all with fine granularity.
Recall that the relationship between a user and a resource is not direct. What we are really doing in AWS IAM is creating policies that govern access to resources. These policies can then be applied to users via roles, thus granting those users access to perform specified actions against specified AWS resources.
Following is a way of thinking that has been useful for me in understanding the IAM paradigm. When we create a user in IAM, that user can log into our AWS account console using login credentials, in a way that we are used to dealing with user accounts. But this user does not inherently have permission to do anything! According to the AWS way of doing things, we do not provide any permissions directly to this user. By its nature, a user can't do anything, or access anything... until we give them a role.
A role is simply a collection of policies. For example, we might create an S3 admin role that has related policies; such as a policy to create and delete S3 buckets, a policy to add and remove files to our buckets, and a policy to read files from our S3 buckets. We might then create a more restricted S3 dev role, that only has a policy to add, remove, and read files, but not to mess with buckets. Finally, we might create an S3 read role, that only has a policy to enable reading of files from S3. (In this simple case, it would be silly to create these roles, since AWS provides them, among many others, as common, prepackaged roles; but this will serve as an example.)
What it boils down to is that policies are what actually allow permission to access resources. Policies are reusable and can be applied to any number of roles. Roles are then handed out to users, like an access badge. The roles are also reusable, and can be handed out to many users, and a user can likewise carry multiple roles. These roles can also be handed out to external users (e.g. AWS users who belong to other organizations), and AWS services that are not humans but need to interact with each other in safe, restricted manners, and others. As you can see, this is a complex system; and we haven't even begun to dive into the granularity AWS gives us to manage access to our resources! But this is a start.
The final thing I'll mention this episode is the ARN, or Amazon Resource Name, because this is the concept that gave me the greatest amount of headaches in my past run-ins with AWS resource management. Everything in AWS has an ARN, which is a "globally unique identifier" for anything that exists in the AWS ecosystem - including users! When we are designing or assigning policies (to attach to roles to grant to actors in our application architecture), we need to know the ARN, because that is the name by which we refer to resources in our ecosystem.