Chapter 6: I am Sam? AWS IAM! (Identity and Access Management, shouldn't that be IAAM?)

Finally got around to chapter 6 (again), IAM (sam? What sort of animal was that?!)

Also a bit heavily overloaded on the theological overtones??? (Intentionally?) see John 8:58 (Bible):

58Jesus answered, “I tell you the truth, before Abraham was even born, I AM!^k” 59At that point they picked up stones to throw at him. But Jesus was hidden from them and left the Temple. [A pretty obvious claim to Deity - i.e. God of the Old Testament]

Makes more sense 2 time around (maybe).

Who uses IAM? When and why?

AWS Identity and Access Management (IAM) is a web service that helps you securely control access to AWS resources for your users. You use IAM to control who can use your AWS resources (authentication) and what resources they can use and in what ways (authorization).

The 1st thing to note is that this for AWS resources ONLY. I.e. not O/S or Application access.  Doesn't this add an extra level of complexity to managing the security of your system in the cloud?
Who is this service designed for? I guess systems/security administrators, I've never had to deal with this level of a system before.  Actually, maybe I have.

1 I worked for a UNIX start-up in the 1990s developing a UNIX resource sharing systems, Share. This worked by allowing users to have different permissions and monitored and enforced resource limits for different types of resources. Until then UNIX was pretty open/flat. You could use as many resources as you liked (until someone came and knocked on your office door to complain).

2 I worked on a Grid OGSA project at UCL, London in 2004. One of the issues we encountered was that the security process wasn't scalable and there wasn't any way of delegating security credentials, so everyone involved had to have "1st order" users and security credentials which required a heavy weight identification process (and took months). One guy even couldn't get registered as his surname was too short (2 letters, chinese gentleman). 

I also wonder why you need multiple users per account rather than multiple accounts? (1 per user?) Isn't this easier to manage, particularly the financial control aspects? Everyone has their own credit card and account?  Also, if you only have have 1 user, how do you manage identification and registration of other users?   How many accounts should you have? One account to "rule them all", or lots of accounts?

A few things written about this. This one says:

While there is no one-size-fits-all answer for how many AWS accounts a particular customer should have, most companies will want to create more than one AWS account because multiple accounts provide the highest level of resource and security isolation.

This one suggests 2 accounts, production and non-production.

And this AWS Account Best Practices.

Principals

The book next introduces "Principals".

Funny, according to the dictionary it's normally:

The head of a school, college, or other educational institution.
E.g. I put the theatrical smoke generator into the principal's office and filled it with smoke when I was at high school (I actually did!)

Or legally either:

Law.

1. a person who authorizes another, as an agent, to represent him orher.
2. a person directly responsible for a crime, either as an actual perpetrator or as an abettor present at its commission.
   Compare accessory (def 3).

I guess the 1st meaning is the intended one! 

A principal is an IAM entity that can interact with with AWS resources. There are 3 types:

Root user: (think UNIX, i.e. god). Best practice is not to use this for everyday activities.

IAM Users: persistent identities for people or applications.

Roles/temporary security tokens: Roles grant privileges to specific "actors" for a set duration of time. What's an actor? When an actor assumes a role AWS provides the actor with a temporary security token from AWS Security Token Service (STS). I don't recall this one?!

[Really need to remember these for the exam!!! Remember: The 3 principals that can authenticate and interact with AWS resources are: The root user (god), IAM users (demi-gods?), and roles (heroes!)

There are 3 use cases:

EC2 Roles, granting permission to applications on EC2.

Cross-account access, granting permission to users from other AWS accounts.

Federation, granting permission to users authenticated by a trusted external system (i.e. IdP: Facebook, Google, Amazon, and SAML 2.0).

Principals don't seem to have a prominent place in the current online AWS IAM documentation, so I'm not sure why they do in the book?

Authentication

IAM authenticates a principal by:

User name/password
Access Key
Access Key/Session Token

Remember Authentication is all about "identity" - who are you.
Again the AWS IAM documentation is a bit sparse for this.

Authorization

This is about what actions a principal can and cannot perform.
Again, tricky to find in the docs.

Policies

Easier to find  in the docs.

A policy is  a JSON document that defines a set of permissions to access and manipulate AWS resources. Contain one or more permissions:

Effect (Allow or Deny

Service

Resource, the resource the permission applies to, as a Amazon Resource Name (ARN).

Action

Condition: optional conditions

A policy can be associated with one principal directly (User Policy), or be reusable across multiple principals (Managed Policies).

Groups

Groups seem important but don't get their own heading.  If a policy is assigned to a group then anyone in the group gets the permissions.

Roles

An actor can be associated with a policy by assuming a role. The actor is provided with a temporary security token. 

It would be nice if there was a simple diagram and lifecycle to explain all this?

Simply users can be member of zero or more groups, and each group can have 0 (?) or more policies.

More about users, groups, roles.

Other key features

Multi-factor Authentication (MFA)

Authentication with extra one-time passwords. A good idea in theory.

Rotating keys

Are these like whirling dervishes? No, seems to be a way of replacing one key with another (by having two briefly active at a time).



https://aws.amazon.com/blogs/security/how-to-rotate-access-keys-for-iam-users/


I think the enigma code worked like this? It's surprisingly difficult to find the history and any academic analysis of rotating keys.   Possibly this is the same as Key scheduling, a paper from 1990. Oh, probably not the same. But this paper from 1984 seems to be talking about key rotation. So the idea has some academic credentials.

And a "trick" question from the practice tests:

Qn: Which of the following are benefits of EC2 roles? 2 answers were:

Credentials do not need to be stored on EC2 instances, and
Key rotation is not necessary - that's the one I got wrong. Why???

The answer is obvious if you think about it, roles use temporary keys:

From the docs:

Retrieving Security Credentials from Instance Metadata

An application on the instance retrieves the security credentials provided by the role from the instance metadata itemiam/security-credentials/role-name. The application is granted the permissions for the actions and resources that you've defined for the role through the security credentials associated with the role. These security credentials are temporary and we rotate them automatically. We make new credentials available at least five minutes prior to the expiration of the old credentials.

I also got caught out by this qn. Which use temporary security tokens?

EC2 Roles and Federation are correct. MFA isn't. Why? Isn't the code generated by the device temporary?

The device generates a six digit numeric code based upon a time-synchronized one-time password algorithm.

???
Finally, this seems to be what all/really what you need to know:

1. IAM Best Practices (avoid places with lots of rocks?)
2. The guide also looks useful.
3. And these slides (which only mentions Principals once, the other best practices don't mention it at all).

Finally (again) there's some complexity if there are multiple permissions that clash.

PS
I found another book with an "I AM" theme, from my childhood (my favourite from memory), called "I AM a Bunny", a Golden Pleasure Book illustrated by Richard Scarry, 1963, "So High Books" (similar cover to mine, but not the same edition).