AWS IAM in a layman's terms (1) -- Identities in IAM
Users, Groups, Roles and STS
Prologue: engineers need to know security in the serverless paradigm development era
Security is boring, but I believe that security knowledge is necessary to engineers when we develop services in the serverless paradigm. Here is why.
We probably heard of Jeff Bezos’ “two pizza team rule”:
We try to create teams that are no larger than can be fed by two pizzas
And that means the security design needs to be well-solved inside that team (the job title ‘DevSecOps’ 😃?)
For teams shifting toward serverless paradigm, a lot of security design responsibility, if not all, will / and should be taken by the serverless service development team. Why?
The reason is simple: because the infrastructure definition has already become part of serverless development team’s code-base (“infrastructure as code, or IaC” is part of the serverless paradigm developer’s code base), as we have illustrated this point in our previous post “Does Serverless make DevOps jobs less relevant in the long run?”
We talked about some network concepts along with network security for AWS cloud in a layman’s words, such as “AWS VPC networking in plain English”.
Other than network security, resource access control is another security topic we have to take care of to build a (micro) service or a product.
Why we need to understand AWS IAM a little bit (we don’t need to become an IAM Ninja)?
AWS made it clear that AWS IAM is the foundation of solving the access control problem:
AWS Identity and Access Management (IAM) is a web service that helps you securely control access to AWS resources.
“Why does it matter to application developers? Isn’t all these security things the business of our security team, who manage my access to our AWS account?” Not necessarily, all these could be and will be part of your code base if you adopt the serverless paradigm.
For example, we talked about why developers may want to understand AWS Cognito for authentication / authorization mechanism in a previous post “What I wish I could have learned before starting using AWS Cognito” — when we use Cognito Identity Pool, the authenticated users will assume a role defined in the IAM under the hood.
IAM Identities in a layman’s terms
The above diagram is a very busy one, but we will focus on the top left corner of it. This portion of the IAM defines the “who”.
An IAM user is “an entity that you create in AWS to represent the person”, it has the similar concept as “users” in an LDAP directory;
an IAM user has key_pair(s) associated to it (see the key associated with them in the diagram below)
though you could, but typically, we don’t assign IAM policy directly to a user; instead, we assign IAM policy to groups (see the policy document associated with group in the diagram below **)
“An IAM Group is a collection of IAM users”, it has the similar concept as “group” in an LDAP directory;
an IAM group can group a list of users together, so that user management becomes manageable and maintainable (see the user grouping relationship in the diagram below)
we typically specify the IAM policy at the group level **;
An IAM role is similar to an IAM user… However, instead of being uniquely associated with one person, a role is intended to be assumable by anyone who needs it.
a role does not have standard long-term credentials such as a password or access keys associated with it (see the diagram: there is not any key associated with a role)
when you assume a role, it provides you with temporary security credentials for your role session, though AWS STS (Security Token Service)
we typically define and associate the IAM policy to a role.
Summary:
AWS IAM is the foundation of AWS resource access control. Services like Cognito Identity Pool and Secure Token Service (STS) are built to facilitate the application layer access control logics around it.
In this post, we only touched upon the identity side of the equation. Stay tuned, and we will touch other interesting details such as IAM policy evaluation. Please subscribe if you are interested this kind of topics.