Identity & Access Management
Trust
The basis of every single security aspect of AWS is trusting their security model.
Policy
IAM is one of the fundamentals that is present in nearly every single aspect of AWS.
IAM aims to provide a very sophisticated and extensible system that can grow with AWS.
On a simple level IAM is applied in two different ways.
The first is as a Policy that is defined and associated with a Role or User.
The other is a Resource policy that is bound to a resource itself.
There are countless documents and tutorials written to cover IAM in great depth and detail.
This article is here to provide a general idea what you can do with IAM and what you cannot.
AWS comes with many ManagedPolicy which are updated and maintained by AWS.
You of course can create your own from scratch or customize an existing policy to fit your needs.
There are many who probably completely avoid dealing with the Policy directly.
A Role can have a Policy (a self-contained entity) attached to it.
For expedience, a Role (or User) can have an InlineRole which is kind of a one-time use Policy.
Typically I recommend avoiding InlinePolicy and trying to create specific Policy that can be reused.
This is very helpful if you need to make a change to this Policy and it should apply to a number of scenarios.
If you noticed I began with the Policy and the Role.
The rationale behind that is because the User should be avoided for most enterprise organizations.
Typically you would want to have many specific Roles that a given user may Assume.
There are several different method of providing user’s with access.
The simplest is through using SAML Identity Provider. This completely separates the identity from the roles.
AWS now has their own SSO or Single Sign On solution. This can connect to an Active Directory server.