This is the first of 3 blogs we are going to publish explaining how to implement security in a Continuous Deployment (CD) process.
Across 3 blog posts, we will explain how to implement the following set of automated security tests during a CD process.
- Configuring and testing AWS security group settings (explained in this blog post)
- Configuring and validating SSH bastion host as the only gateway to access all underlying instances
- Configuring database permissions for the application and users and validating those settings during the CD process
In this blog, we explain how to check (during the deployment process) if best practices have been followed while configuring security groups within your AWS environment.
We will use a Jenkins based deployer to check for optimal settings on the target AWS environment before proceeding with the deployment. If the optimal settings are not in place, then the deployer will block the deployment.
Figure 1 below shows the overall architecture of the application. The web server (3) is accessible to the client via a LoadBalancer (2) on port 80. The security groups isolate the application web server, load balancer and database (4) in a way that only the webserver has access to the database and the client has access to the webserver only via the LoadBalancer.
To maintain and update the application, only the administrator can directly access the webserver on port 22. This setup makes sure that the application running in the web server is accessible to the client (1) through the Load Balancer (2) via ports 80 and 8080 without exposing the SSH port to users from the Internet.
Figure 1: Overall architecture of the application
The purpose of the deployer is to check whether best practices with respect to the configuration are in place on the target environment before the CD. If the target environment is not configured with best practices, then the deployer will block the deployment else it will proceed with the deployment.
We use Jenkins to implement our deployer.
Figure 2: Deployer workflow
Configuring and testing security group settings
Steps 1-3 show the creation of security groups for webserver and database. Step 4 shows the configuration file used to check the security groups using pineapple.
We add a non-permissible route in the rules and verify the security groups in step 5 and finally, we remove the non-permissible rule and the scan is successful in step 6.
Step 1: To create a SecurityGroup for Public Webserver and Private DB, select VPC Dashboard, select Security Groups, and then select Create security group.
Step 2: Create a Security Group for the webserver with values:
- Security Group Name: devsecops
- Description: WebServer security group
- VPC: Choose the VPC created earlier (Devsecops)
- Inbound rules:
- Type SSH, Source 0.0.0.0/0
- Type HTTP, Source 0.0.0.0/0
Step 3: Create a Security Group for the database with values:
- Security Group Name: devsecops DB
- Description: DB Security Group
- VPC: Choose the VPC created earlier
- Inbound rules:
- Type MySQL/Aurora, Source The identifier of the Devsecops SG
Step 4: Write security check rules using pineapple (https://github.com/jvehent/pineapple)
PineApple (Policy Inspector for NEtwork Accesses, PeoPLE!) is a prototype to assert the content of security groups between AWS components. Pineapple uses tags to locate components in a given region, then pulls the security groups of these components and compares their content against rules. We include pineapple in our use case to ensure that the instances inside the security groups are only communicating to a predefined set and no unauthorized communication is happening.
We input the legit communication from source IP/port to the destination as rules to PineApple and let the tool check for its authenticity. We can give a source-destination rule to PineApple and if the check fails, that means such communication is not possible with the enforced security groups.
Step 5: During every deployment, run the script in the Deployer by adding an extra rule as a test (to fail). As expected, the build fails, which is the expected result as we have added a route in the service groups that is not permissible.
Step 6: Run the script in the Deployer by removing the extra rule, then build Succeeds