AWS IAM

In this, course we will look at how Identity and Access Management (IAM) works and write policies to control access in an Amazon Web Services (AWS) account. Having well-thought-out access control policies is the cornerstone of a secure account and is imperative, regardless of whether we are running a massive serverless architecture or just a few Elastic Compute Cloud (EC2) servers.

Cloud security

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 we, 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 us the tools to secure our part of the infrastructure but we 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 has Administrator access.

Blast radius

In cloud security, the blast radius is an important concept. It is a measure of the possible consequences in case of a security incident. For example, if 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 cannot read from a specific Simple Storage Service (S3) bucket either directly or indirectly then that bucket is not in the blast radius.

Least privilege

Finally, the principle of least privilege is a set of permissions that allows normal operations but nothing else. It is a mostly theoretical point in access control where the user has just enough access to complete their tasks and any less would lead to operational problems, such as the application being unable to write to the database.

For an illustration, let’s say a system needs access to an S3 bucket to read some objects. We can choose to give full access to the account, in which case we won’t see any access denied errors. However, it also means the system has a lot more permissions than it needs. Alternatively, we can grant the system access to the S3 service. These restrictions can take many forms, such as restricting access to that specific bucket, or giving the system read-only permissions. Going even further, if the system is located in the corporate network, we 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 the least privilege permissions minimizes the damage from cyber attacks.

The IAM service is the security center in an AWS account. As the name suggests, IAM manages identities who can access the account, and access which determines who can do what. Whenever we need to give or restrict access to a resource in the account, IAM is the place to go.

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

This course does not attempt to cover all these edge cases but instead focuses on the underlying logic of access control in AWS. We’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 course, you’ll have a good understanding of how IAM decides access in different cases, how to write policies that allow and restrict access to an account, have a solid foundation to evaluate IAM policies.

Structure of the course

In the Access control basics chapter, we’ll start with how AWS APIs work and what happens when a request hits them. We’ll look into the different parts of the request, as this the information IAM has when it determines access.

Then in the IAM policies chapter, we’ll look into how to configure access inside AWS. First, you’ll get familiar with the policy structure and its elements. Policies are used throughout AWS. In the Policy types lessons, we’ll learn about the 5 policy types AWS supports.

The Request evaluation flow and examples chapter is about how request and policy elements — fit together and determine whether the operation is allowed or denied. We’ll then learn how IAM reaches a decision even when multiple policies of different types are present. Then, we’ll bring it all together into several step-by-step realistic examples that show the concepts in action. These examples will allow us to see exactly how IAM evaluates access, and we’ll have templates for how to apply these protections to our AWS environments.

Finally, the How to secure an AWS account chapter offers practical tips to secure an account both as an administrator and a developer. We’ll learn about the best practices and the usual pitfalls of AWS security.