This is an attempt to explain AWS IAM principles.

Why do we need this?

AWS Documentation is a little too complex and formal, perhaps unhelpful to tyros who want to understand the basics, quickly.

(We will start by assuming nothing, and use analogies to explain concepts).

Explaining IAM using Analogies

Someone wants to access your money (i.e. a valuable “resource”).

AWS security has to ask these questions:

The questions do have some terminology behind them:

Every time you want to do something in AWS, you gotta answer the above questions. These questions are known, inside AWS, as the PARC Model:

• Principal
• Action
• Resource
• Condition

Great! We’ve got the answers to our questions. What do we do with them?

We can specify some rules as to when and how the money can be withdrawn - these are called: “Policies”.

If somebody gives us answers which do not meet these “policies”, or if they do not give us acceptable answers - then we simply deny access.

Remember this: unless we explicitly allow, our default answer is to deny access (there is one slightly complex “exception” to this rule (permission boundaries and SCPs)), which we will elaborate on further.

Here is one example:

ALLOW:

• (Who?) The Fuhrer
• (Resources?) Access to our money
• (Action?) To Spend on Public Infrastructure Projects Only
• (Conditions?) Only between 9 am -5 pm

Let’s try working out whether we should allow the Fuhrer’s request, given the above.

In this particular case, we deny because we are only allowed to spend the money on public infrastructure, and not to help out your union mates or to buy votes etc.

How does AWS security go about “assessing policies”?

Summary: For any request to be approved it must be both: (i) must not be explicitly denied, and (ii) must be explicitly allowed.

Look at the cop in the cartoon above. How does the cop make his decisions? He asks questions and presumes things in the following order.

1. When anyone asks for permission, his initial presumption is a blanket: “no!”. We start off with a default position of “deny”. Then we start evaluating all applicable policies - there are various types: more on this later.

2. Is there an explicit deny?

   If yes - if there is an explicit deny: then it’s game over. We deny access and we don’t ask any further questions..

3. Is there an allow?

   If yes, then we allow.

4. If none of the above applies, then we simply deny and that’s it. Game over.

Here’s a flow-chart which summarises it (shamelessly elided from Johnson’s lecture.) (¹).

Different Types of Policies

We’re going to introduce different types of policies. Don’t let the terminology scare you - I will go through each one by one with a little story, to help you remember.

1. Service Control Policies (SCPs) - AWS Organisations
2. Permission policies (IAM) - AWS identity and Access Management a. Inline policies b. Managed policies
3. Permission Boundaries (IAM) - AWS identity and Access Management
4. AWS Security Toekn SErvices (AWS STS)
5. Resource Based Policies (Specific AWS Services)
6. End point policies - VPC End Points

Service Control Policies

They don’t grant access. They simply limit what people can do.

IAM Users, IAM Roles

What’s the difference.

You can think of IAM users are people.

You can think of IAM roles as hats. They can be shared around. Let’s use an everyday analogy.

Koshy Koshy. His role is the CEO of a construction company. The “CEO” role has the following policy attached:

Effect: “Allow” Action: “Visit” Resource: “Construction site on Swantson street.”

Koshy cannot do anything himself - to adopt the AWS paradigm: he needs more: he needs a policy to be attached to his IAM user account. In this case, he has the “CEO” role - a “hat” which he wears. This hat allows him to access his own construction site. But occassionally, he might want outsiders to gain access to his construction site too: they can’t just walk in there (they are not allowed to) - they must put on the CEO’s construction hard-hat and then go.

What would make sense would be to give them the CEO’s hat - the construction worker role - which would consequently enable the foreigner to access the construction site.

Resource Based Policies

This is attached on the specific object. You might have a car for example. Within the glove box of the car, there might be a list of: (i) who can access it, and (ii) what they can do with it. For example, Freddie might be able to drive the car, while Johnny might only be able to park it.

This is to be contrasted with identify based policies. These attach to an identity. For example: Johnny is allowed to drive this particular car.

In the end, it probably doesn’t make a whole lot of difference conceptually. There are difference in nuance, though. For example, resource based policies are not “managed”. They must be ‘in-line’. That means you gotta manually specific/create them. You can’t just get one off the shelf, as with a “managed” policy.

// Here is the mermaid based flow chart
// https://mermaid.live/edit
graph TD
    A[1. Deny Access] -->|2. Evaluate All Applicable Policies| B{3. Is there are explicit deny?}
    B -->|Yes| DENY[Deny!]
    B -->|No| C{Is there an explicit allow?}
    C -->|No| DENY[Deny!]
    C -->|Yes| ALLOW[Alow!]