Deployment and Provisioning
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.
Hi, and welcome to this lecture.
In this lecture we'll talk about reinforcing policies with conditions. I will show you the syntax of conditions, and we will quickly talk about usage.
So I could have showed you conditions in the last lecture, but condition is a topic of its own, and the truth is you don't really need to master conditions to take this exam, so I decided to separate conditions from the main policies lecture.
So conditions, putting conditions in your policies is a way to reinforce some security parameters. For example in this case, we are saying that we are going to only allow requests that will come after this date and time, so we will take the current time here, and we will evaluate if it's greater than this date. And if it's greater, it means that we allowed that request. But we have a lot of things inside a condition, we have the condition itself, but we also have condition operators. All these entries are conditions operators, you can have DateGreaterThan, DateLessThan, you can have IpAddress, you can have a string operators, we can have a lot of operators as we can see in this slide. We can have string, numerics, date and time, Boolean, binary, IP address, Amazon Resource Name, IfExists, and we can also test the existence of condition keys. We will talk about condition keys in a few, but just know that we can test if the keys exist inside the condition.
And just a quick example, all these operators, they are main operators, we actually have more specific operators inside these main categories. So for example for the string operator, we have StringEquals, StringNotEquals, a StringEqualsIgnoreCase which you ignore the case in a string, and so on.
So after talking about operators, we also have keys. All these values are keys. In this case they are global values, they are values that will be available across all surfaces, we can tell that because they start with aws, so we can take for example the CurrentTime, we can take the SourceIp, and we can take a lot of other types of keys, and each service has its own type of keys.
So for example if we are applying a policy to an action related to cognito, so we can specify a few cognito keys. We have this key, and this key, therefore it's a lot of things to know, it's a lot of things to memorize, if you really want to master conditions. Thankfully for the exam, you only need to know what you can achieve with conditions.
So for example, you can ensure that all data inside the bucket will be encrypted with server-side encryption. Let's take this policy for example, we are denying the PutObject action to all principals, to everybody. So everybody will be denied if they match this condition, and this condition says that if the string will not be equal to that, then AWS will deny the request, and what that string means, we have the encryption key for S3 in this case, and we are specifying here the type of encryption.
Remember that we can have two types of encryption, we can have client-side encryption, and we can have server-side encryption. For the server-side encryption, this is the type of encryption that we use, so therefore every time we send a request with a server-side encryption, we should specify this value in this header inside the request. And we also have another action being denied in here, we are denying this same action to everybody, but this time this operator knew we are actually checking if this header exists. If this header doesn't exist, it will return the value true, so we know that we are not sending a request with an encryption header, so this request will be denied, and the first one we have, the encryption header, but we are checking if it's server-side encryption, and not client-side encryption.
We can also restrict access to a specific IP addresses, in this case this is another bucket policy, we can tell that because we are specifying a Principal in here, and we are going to allow all actions on s3 on the examplebucket, but the connection must come from this IP range. You can see that it's 24 in the end, so we are talking about this whole range of IP, and we will not allow if it's in this IP address.
If it's in this specific IP address, we can see that's final 32, so it's a specific IP address, we will not allow connections from that specific IP address. And you might ask, why put two evaluations inside this single condition. Well, in this case since it's a range, this specific IP address is part of this range, and what we are telling is, we will allow access to all addresses in this range, but this one.
About the Author
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.