Zoning Commission Hearing 06-04-26

[0:00]Hello, everyone. My name is Elizabeth and I'm a solutions architect here at AWS. Today, I'm going to walk you through a solution to deploy an application in your AWS account while enforcing security best practices. For the purpose of this demo, we'll consider that you are an application developer and you have a web application you'd like to deploy into an AWS account. When deploying applications, it's very easy to just go into the console and just click next, next, next, and you deploy your application. However, that is not the best way to do it. When you're deploying applications, you want to make sure you're following security best practices and applying infrastructure as code and applying the principle of lease privilege. So in this demo, I will walk you through a solution using AWS service catalog, cloud formation and other services to help you deploy your application in a secure manner. First, let's start with the problem statement. As an application developer, you want to deploy your web application into an AWS account. You want to make sure your application can interact with a database, can store files in S3 and logs to cloud watch. You also want to make sure that you're using infrastructure as code and enforcing security best practices. So that means you're not going to be deploying your application using the root account, for example. The challenges here are that the application developers should not have administrative access to the AWS account. We want to apply the principle of least privilege, meaning that we want to grant application developers access to only the necessary services and actions they need to deploy their applications. And the solution needs to enforce security best practices such as only allowing a limited set of IM actions in cloud formation. For example, we don't want to allow application developers to spin up EC2 instances without restricting the instance types. We want to make sure that they can only deploy specific type of EC2 instances, maybe T2 micro for development or T3 medium for production. We want to also make sure that we are deploying resources that are highly available and that are following best practices such as encryption at rest and in transit. So how can we do this? So in order to deliver a solution that ensures application developers can deploy their web applications while enforcing security best practices, we can use AWS Service Catalog, along with other services, to allow application developers to deploy applications without having to worry about creating IM roles, creating IM policies, or creating other resources that might be security risks. So the solution overview is that the application developer will deploy their web application using AWS Service Catalog. The AWS Service Catalog product will leverage cloud formation to provision the necessary infrastructure and the application. The cloud formation template will define the resources that are going to be deployed, along with security best practices. This means that we can have a cloud formation template that creates an EC2 instance, an S3 bucket, a database, and other resources that are needed for the application. The application developer will then access their web application and be able to use it as needed. Now, let's walk through an architectural diagram of this solution. So we have an application developer that wants to deploy a web application. They will log into the AWS console using their federated identity, and they will assume a role that grants them access to the service catalog. They will then provision the service catalog product, which will trigger a cloud formation template. The cloud formation template will use a service role that has specific permissions to deploy the resources. This means that the application developer doesn't have to have any administrative access to the account, but they can still deploy the resources because the service role has the necessary permissions. The cloud formation template will then deploy a web application in an EC2 instance, along with a security group to protect the EC2 instance, an S3 bucket to store files, an RDS database for the application to interact with, and a cloud watch log group to store the application logs. The application developer will then be able to access the web application through a web browser. Now, let's talk about the specific resources and security best practices that are enforced. So the application developer only has access to provision service catalog products, meaning they don't have access to create their own IM roles or IM policies. The cloud formation service role is created with the least privileged access, meaning that it only has access to the resources that are defined in the cloud formation template. For example, if the cloud formation template defines an EC2 instance, then the service role will only have access to create EC2 instances of specific types. The S3 bucket is created with encryption at rest and in transit, meaning that all the data that is stored in the S3 bucket is encrypted. The RDS database is also created with encryption at rest and in transit, and it's also deployed in a private subnet, meaning that it's not accessible from the internet. The EC2 instance is deployed in a private subnet, meaning that it's not accessible from the internet directly. It can only be accessed through a bastion host or through a load balancer. The cloud watch log group is created with a retention policy, meaning that the logs are automatically deleted after a certain period of time. Now, let's go into a quick demo of how this works. So I'm logged into the AWS account as an application developer, and as you can see, I only have access to the service catalog. I don't have access to create EC2 instances, S3 buckets, or other resources. I can only access the products that are provisioned through the service catalog. So I'm going to go ahead and click on the product, and I'm going to provision a new product. I'm going to give it a name, for example, my web app. And I'm going to provide a stack name. So this is going to be the name of the cloud formation stack. I'm going to say my web app stack. I'm going to provide an instance type, so I can only select T2 micro, which is what I want. I'm going to select an SSH key pair. So this is going to be used to access the EC2 instance. And then I'm going to provide the database password. This is just for demo purposes, so I'm just going to provide a simple password. And then I'm going to click on provision. So as you can see, the product is being provisioned, and it's going to take a few minutes for the cloud formation stack to complete. So I'm going to pause the video here and I'll come back once the stack is complete. So as you can see, the product has been provisioned, and the status is available. If I go to events, I can see all the events that have been created by the cloud formation stack. And if I go to outputs, I can see the outputs of the cloud formation stack, such as the public IP address of the EC2 instance and the database endpoint. Now, let's go into the EC2 console and see if the instance has been created. So as you can see, I have an instance that has been created, and it's running. And if I go into the details of the instance, I can see that it's a T2 micro instance, which is what I specified. And it's also in a private subnet, meaning that it's not accessible from the internet directly. And if I try to connect to the instance using the public IP address, it will not work because it's in a private subnet. Now, let's go into the S3 console and see if the bucket has been created. So as you can see, I have an S3 bucket that has been created, and it's encrypted. And if I go into the properties of the bucket, I can see that encryption is enabled. Now, let's go into the RDS console and see if the database has been created. So as you can see, I have a database that has been created, and it's in a private subnet. And if I go into the details of the database, I can see that it's encrypted and it's in a private subnet. Now, let's go into the cloud watch console and see if the log group has been created. So as you can see, I have a log group that has been created, and it has a retention policy of seven days. So this is how you can use AWS Service Catalog along with other services to deploy your applications while enforcing security best practices. If you have any questions or feedback, please feel free to leave a comment below. Thank you for watching, and I'll see you in the next video.