Introduction

This book is to show you how IAM works and to give you a mental model of how to write policies to control access in an AWS account. Having well-thought-out access control policies is the cornerstone of a secure account and it is needed no matter whether you are running a massive serverless architecture or just a few EC2 servers.

Security in the cloud follows the so-called shared responsibility model. The cloud provider, AWS in this case, is responsible for the security of the cloud, but you, the consumer, are responsible for the security in the cloud. It's often misinterpreted to say that the cloud is inherently secure, but it says nothing like it. AWS gives you the tools to secure your part of the infrastructure but you need to use them right to get any benefits. It's not enough to have all sorts of security services protect the resources in the account if everybody is using users with Administrator access.

In cloud security, the blast radius is an important concept. It is the measure of if there is a security incident, what are the possible consequences. For example, when a web server has access to a database then a hacker can potentially get access to the data, so the database is inside the web server's blast radius. On the other hand, if it can not read from a specific S3 bucket either directly or indirectly then that bucket is not in the blast radius.

Finally, least privilege is the set of permissions that allows normal operations but nothing else. It is a mostly theoretical point in access control where any less would lead to operational problems (such as the application can not write to the database).

For an illustration, let's say a system needs access to an S3 bucket to read some objects. You can choose to give it full access to the account, in which case you won't see any access denied errors, but it also means the system has a lot more permissions than it needs. As a second step, you can grant only access to the S3 service. Going further, restrict access to that specific bucket, and only to read permissions. Going even further, if the system is located in the corporate network, you can also restrict the IP address. In this case, if a hacker gains control of the system's credentials then it's a lot less useful compared to leaked Administrator access keys. Implementing least privilege minimizes the blast radius. As a next step, you might decide to restrict the access to the office hours, but IAM does not provide this functionality. Least privilege is dependent on the service.

The IAM service is the security center in an AWS account. Its name (Identity and Access Management) indicates its purpose: it manages identities (who can access the account) and access (who can do what). Whenever you need to give or restrict access to a resource in the account, this is the place to go. And to implement least privilege, you need to know how it works.

Unfortunately, IAM is not straightforward to configure. While its policy language is logical, there are a ton of service-specific exceptions. This makes it hard to have a full picture of how to configure policies and it requires reading the documentation and experimenting with different configurations to see how they work.

For example, it's all over the IAM documentation that an explicit Deny statement denies everything. But it turns out that the root user can still access an S3 bucket even if its bucket policy denies it. But it's not the case for KMS key policies, a construct that should work similarly, where you can lock yourself out and need to contact AWS support to get back control over the key.

Or you might think that an SCP (Service Control Policy) can deny everything happening in an account. Well, the documentation shows 11 exceptions to this, and these do not even include things that can not be restricted by IAM.

This book does not attempt to cover all these edge cases but focuses on the underlying logic of access control in AWS. You'll learn how to write policies to control access, what kind of policies are available, and how IAM looks at each of them to determine if a request is allowed or denied.

By the end of this book, you'll have a mental model of how IAM decides access in different cases. You'll know how to write policies that allow and restrict access in an account exactly the way you want. Using the tools described in this book you'll have a solid foundation to reason about IAM policies.