1. Home
  2. Training Library
  3. Amazon Web Services
  4. Courses
  5. Deploying a Highly Available Solution for Pizza Time

All about policies

Start course
Overview
DifficultyIntermediate
Duration3h 11m
Students1072

Description

In this group of lectures we run a hands on deployment of the next iteration of the Pizza Time solution. The Pizza Time business has been a success. It needs to support more customers and wants to expand to meet a global market.  

We define our new solution, then walk through a hands on deployment that extends our scalability, availability and fault tolerance. 

Transcript

Hi and welcome to this lecture.

We will dedicate this entire lecture to talk about policies, we are going to define some general rules. We are going to talk about types, then you are going to see the policy syntax of IAM policies and Bucket policies.

For the exam, you need to be able to read a policy and tell what it does, so for example, this is an IAM policy, and for the exam, you need to be able to read this policy, and tell what it does. In order to understand what it does, you need to understand each of these elements that you are seeing.

This is another example, this is a Bucket policy, it's very similar to an IAM policy, so if you do understand one, it will be very easy to understand the other one. That's why I'll talk about IAM policies and Bucket policy in a single lecture.

Talking about general rules, by default, all requests are denied. So, if you create a new IAM user and you don't attach any policy to that user, this user won't have any permissions in your AWS account. An explicit allow overrides this default, so if you explicitly allow the user to do something, that will override the default, which is deny everything.

However, an explicit deny overrides any allows. So, even if you're granting all the rights to a particular IAM user, even if you are granting him administrator access, if you also associate another policy to that user, denying something, that deny overrides any allows, so that particular action that you're denying will be denied, no matter if there is another policy allowing that.

For example, in this case, we have the effect, the effect tells what the policy does and in this case, we are denying something, we are denying an IAM action, the IAM action that we are denying is the ListRoles. Even if we attach another policy to a particular user or a group, allowing that action if we have a deny associated with that user or a group, we will still be denying the action.

We have IAM policies, IAM managers, all the services we find in AWS account and we have Bucket policies. So, let's understand how those two works, they compliment each other, but the IAM policy is a more broader policy. It talks about all the resources within a single account. And a Bucket policy will be associated with a particular Bucket.

For example, you have a user in here and you're granting this user, adding in access. Therefore, that user will have access to all these services, including the S3 service. So, this user will be able to manage everything inside your account.

But, you decide to create a Bucket and this is a very particular Bucket, you want that only one guy have access to that Bucket. So, you create another user in here, and this user is just a regular user, he doesn't have any admin permissions, he doesn't have permission in other services, he actually don't need to be any IAM permissions. Let's say that this user has no IAM permissions.

You can specify a Bucket policy to a particular Bucket, saying that this user has rights in this Bucket. And all the other users won't have access to this Bucket. So, you can put an explicitly denying to all the other users in your account and allow only access to this particular user.

Since the Bucket policy is more specific, it's directly related to a Bucket even though you have a user with admin rights, he won't be able to access that particular Bucket, but you need to pay attention to something. This user is an admin, so if you really want to have a particular Bucket, you need to make sure that this user won't be able to add in this Bucket policy because if he will be able to add this Bucket policy, he can grant access to himself to this particular policy.

We have two types of policies, we have inline policies, inline policies are directly associated with users or groups and we have managed policies. Managed policies have a special place in our AWS account, we are actually creating a policy file and we can manage better this policy. We can have versions of this policy and we can attach these policies to more than one entity.

With inline policies, if you want to have the same policy for two users, you'd have to copy and paste that policy and associate with those two users, and if you want to change the inline policy and you want that both users have the same policies, the same permission, you'd still have to add it, the policy in both users.

That's why managed policies are so handy and you have two types of managed policies. You have AWS managed policies which are the AWS default policies, all accounts have those policies and you have the customer-managed policies. Your policies, you can also create custom policy to attain to your particular needs.

IAM policies are written in JSON format, also Bucket policies are written in JSON format, nothing new in here, and let's start talking about the policy syntax. This is an IAM policy. We have a version of the policy in here and we have a list of statements. We can see that it is a list because we have a square bracket in here and we are closing the square bracket in here. Every time you have a square bracket in a JSON file, that means that you are specifying a list and you are specifying a list of statements, and each of these statements will do something. This statement will do something, this statement will do something and this statement will do something.

Let's start defining the most important pieces of a policy. The first one is the version. AWS has currently two versions and you can specify the version that you want to use. In this case, we are specifying a version, the 2012 version, but if we don't define any version, AWS will use the default version, the default version is the 2008 version. It is a good practice to always include a Version element and set it to the latest version which is the 2012 version.

We have a statement, and the statement field is actually a list, so we can define more than one statement within a single policy. We have an example in here. We are talking about this part of the policy. We covered version, statement, and now we're talking about each particular statement. So, for the next elements, each particular statement can have those elements.

The Sid, this is just an optional value that you can add to any statement and it usually means what the statement will do. Effect, that is one of the most important fields of the statement, it's where you say if you're going to allow or deny that action.

Remember, we need to have an allow in order to be able to do something, but an explicit deny will always override an allow. And we have the action, the action can either be a list, in this case we are specifying two actions, but it can also be a single action so you don't really need the square brackets, you could erase those and just define a single action.

The resource is an AWS resource, you can tell that because we need to specify an arn, arn stands for Amazon Resource Name. The resource field, we specify which resource we're talking about, so for example, we specified the sqs SendMessage and we specified the allow action. We can also specify a specific sqs queue, so in this case, we could specify in here that we are going to allow SendMessages but just to the queue1. We would have a queue inside the sqs service called queue1. I already said that Bucket policies are similar to IAM policies, we can see a Bucket policy in here and the only thing that we didn't see in IAM policy is actually the principle.

What is the principle? We have the resource, the resource in this case is the Bucket associated with the Bucket policy, that's easy. And we have a principle, the principle is the one trying to access this resource. What happens is, we're associating this policy to a Bucket, we're not associating this policy with a user, when you associate something with a user, we don't need to specify the principle because the principle is already the user, is already the group or is already the role, but since we are specifying this policy to a Bucket, the Bucket is a resource, is not a user, is not an entity. We need to specify also a principle and the principle in this case is a star, meaning that anyone can get objects, it's also known as read objects, so anyone would be able to read objects inside the example Bucket, that's what this policy does.

And to specify a particular principle, you need to use the Amazon Resource Name of that principle. That's it for policies, I will not show you anything on the AWS console right now, we are going to see how those thing work in the AWS console in the next lecture when we start talking about conditions.

About the Author

Students14569
Labs11
Courses6

Eric Magalhães has a strong background as a Systems Engineer for both Windows and Linux systems and, currently, work as a DevOps Consultant for Embratel. Lazy by nature, he is passionate about automation and anything that can make his job painless, thus his interest in topics like coding, configuration management, containers, CI/CD and cloud computing went from a hobby to an obsession. Currently, he holds multiple AWS certifications and, as a DevOps Consultant, helps clients to understand and implement the DevOps culture in their environments, besides that, he play a key role in the company developing pieces of automation using tools such as Ansible, Chef, Packer, Jenkins and Docker.