A recent change in my life has required me to update my resume. As such I figured it would be a fun time to use what I’ve learned to create something for myself that I can use now and in the future. I’ve completed a couple of iterations and am comfortable where it’s at right now. I plan future revisions and features that will be completed as time permits.
It’s been great fun so far and I have learned quite a bit! A small list of tools I used:
Windows 10 Home (no native virtualization required me to use Vagrant instead of native Docker)
Vagrant (created Vagrant files to rapidly create local build and deployment enviroments)
VirtualBox (provider for Vagrant)
Ubuntu 18.04 (used as base build image)
Microk8s (used for local testing)
Terraform (used for AWS resource creation)
Ruby using Sinatra framework and Thin webserver (used for application frontend)
RubyMine with remote interpreter (used for code quality)
AWS Resources (defined by Terraform)
You can activate the application by running the following command from a terminal:
Remember that there is no guarantee what action will be run when you run the above command. The logic flips between apply and destroy after successful runs. Please run the command again to destroy the resources after you create them!
If you contact me with your hexadecimal namespace I can also tell you exactly how much your infrastructure cost me!
Please visit the GitHub link above to read the code and see upcoming features I plan!
I have completed the respondinator project to my liking, which is rare. I have been able to squash all issues that have come up, protect it against specific types of attacks, and clean up the code to my liking. I added integration tests to make sure I don’t break anything, and I have pushed the changes to a public GitHub repository. You can find the code base at the following location:
Below will be the final instructions moving foward until any changes are made:
Adding routes (POST)
String response route:
JSON response route:
Updating routes (PUT)
Use the key that was provided in the POST or PUT
Retrieving route (GET)
Additional NGINX update
This issue was brought to my attention by a specially crafted Go application that my associate built specifically to take down my application. I was able to prevent further attacks by this application by modifying my base NGINX configuration to rate limit requests. Due to the fact that I use CloudFront in front of my origin, I had one of two choices. Use the binary representation of the IP address in NGINX to block the requests (less memory usage), or block based on X-Forwarded-For address (more memory usage). I chose the former, due to the fact that these applications are running in memory constricted containers.
What happened before adding the set_real_ip_from options was that it was rate limiting each CloudFront edge IP address instead of the true client IP. After setting these options, I no longer see the CloudFront IP address, and all IPs are replaced with the true client IP. I’m still not sure that I want to keep it this way, as it may be useful at some point to know the CloudFront edge IP that’s hitting the site.
In an effort to learn more about Ruby and APIs I came up with the idea of an API that dynamically adds routes to itself, and will respond with a payload that is specified by the user. The use case for this that I thought of was in the event you are going to interact with a 3rd party API, you would be able to build a quick request/response mockup to test against without actually hitting the 3rd party. You can create invalid responses to test your error handling, or mess with the data, whatever your heart desires.
The current iteration consumes a JSON payload with up to three keys:
You will receive a response similar to:
You can then update the route using the key provided.
I only currently respond with a string. The idea is to be able to consume an entire JSON response as well as allowing a POST with a response. It’s almost entirely useless right now.