EnglishThe following is an excerpt from the chapter on “Managing Permissions with IAM” from the eBook “Stratospheric – From Zero to Production with Spring Boot and AWS” I’m currently writing together with Tom Hombergs and Philip Riecks.
You can get the eBook over at Leanpub.
Managing Permissions with IAM
When deploying applications to a cloud service such as AWS, reliable security concepts are key. After all, we not only want to protect our users’ data but also make sure that security within our organization isn’t compromised.
With AWS Identity and Access Management (IAM) we’re able to address these concerns for our cloud applications and in the larger context of security and access management within an organization.
Using AWS services requires both authentication and the appropriate permissions (or: privileges) for accessing a particular resource.
In this chapter, we’ll have a look at basic access management concepts and how those are implemented with IAM. We’ll give an overview of IAM terminology, tools, and techniques. We’ll also outline best practices for managing permissions with AWS IAM. Finally, we’ll delve into our sample application again and see how IAM works in the context of deploying and running a web application.
As we continue to develop our sample Todo application through the course of this book we’ll occasionally need to add new permissions for accessing specific AWS resources or services. This chapter will equip you with the knowledge to do so.
Users, Groups, and Roles
Access-control lists (ACLs) are a tried-and-true approach for granting and managing access to resources. ACLs essentially answer the question “Who is allowed to access a specific resource – and to what extent – at a specific point in time?”. This answer can be given in many ways, the simplest one being a single user with specific permissions for accessing a specific resource.
However, solely basing access control on specific users is neither particularly scalable nor is it maintainable because sooner or later such an approach is bound to create plenty of duplication. If, for example, we grant read permissions to a file on a per-user basis but later on decide we want to withdraw those permissions again we have to do so for each user individually. Not only does this entail additional work but it’s also an error-prone process because the odd user or two might have been omitted and therefore still have the outdated permission.
In order to alleviate this problem, we can grant privileges based on a group a user belongs to or the role they assume at a given moment. While groups represent a set of users, roles combine a set of permissions that are necessary for fulfilling a certain function.
In computer security, an abstract entity that can be authenticated is often referred to as a principal.
This diagram gives an overview of how the main entities within IAM relate to each other:
In the context of AWS and IAM, a principal can be a person or an application identified by either user credentials or an associated role. Users are individuals with an identity and credentials (usually username and password) whereas roles don’t have credentials but are usually assumed temporarily by either applications or already authenticated users. Roles therefore allow us to assign permissions without storing AWS user credentials with an application. Roles also allow already authenticated AWS users to switch between different sets of permissions based on their current task or context (think of a system administrator working for several departments within an organization, for example).
Allowing or restricting access to a resource is a two-part process consisting of authentication and subsequent authorization. First, a principal needs to identify through authentication. The most common way of doing so is via providing both username and password. Keep in mind though that with IAM both users and roles can be principals so a valid username / password combination is just one method of authentication. Once successfully authenticated, a principal can access the resources they are authorized for. For each request, AWS will check if the principal is permitted to perform the request action on the requested resource, as given by the resource’s Amazon Resource Name (ARN).
Again, if you like what you’ve read so far you can get the eBook over at Leanpub.
With each version of the book the price will go up. If you decide to buy the eBook now you’ll get all future updates for free.
If you join the mailing list you’ll get an additional 50% discount on the current price.