11 April 2024

March - Free Lambda Bastion

Intro

I’m going to try a new format. I like coding more than writing blogs, but I can see the advantage of blogging. I’ve been working tirelessly over the past year researching emerging technologies and putting together some infrastructure for a startup I have planned later this year. I’m checking these litting things off my todo-list which actually turned into an immense adventure so I’m going to document them here instead of simply deleting forever. Who knowns, maybe this will become a monthly blog?

I’ve been prepping a mobile app. It needs connectivity to a device in a datacenter, but I was worried about the security implications this might bring. A lot of times with application security, it becomes popular to decide, “Well, lots of people use this in production so deploying it against the internet will probably be fine.” Since this is my datacenter, I figured I may as well treat this project with the utmost professionalism. It’s not hard to batten the hatches of an API. For instance basic auth is simple (ugly) and works great. It doesn’t scale well though, so I figured I wouldn’t go that route with it (yet). Instead I wanted to implement a bastion pattern, where traffic is allowed into the network only if it comes from a particular IP address or subnet. My first exposure to this pattern came from working in healthcare. An AWS consultant showed me how it worked. I was kind of puzzled when I first saw it and asked, “and that makes it secure?” He shrugged and said “it’s pretty secure, I guess.” And it is. The idea is that in order for an attacker to harm your system, they would need to know both where the bastion network is and where the datacenter is. Further, the bastion network must be compermised before the datacenter can even be pentested explicitly. But how do we implment this in a cost effective way?

Free Lambda Bastion

So it turns out you can create a Lambda in AWS and have it act as a proxy to your actual API which is hidden in your data center. When you create a lambda, you can associate it with a subnet, and associate that subnet with a VPC thereby (assuming your configurations are correct) establishing an IPv6 subnet which you can allow-list on your datacenter’s ingress firewall. and your first million requests each month are actually free. It’s very rare that I find resources in AWS where there’s no catches where you wind up paying $30/mo for basically nothing. Actually, if you try to implement a lambda-based bastion the naive way using IPv4, you do wind up paying something like $36 which isn’t going to break the bank for anyone, but it is basically $36 per month for nothing so if you ask me, it’s too much.

IPv6 Upgrades

Remember being a kid and brimming with anticipation around IPv6 which was a technology destined to solve all your life’s problems? And then it came out and your ISP didn’t support it so you just kinda forgot about it? Well the day has finally come for IPv6 to come back into my life. By 2024, I had already forgotten that ISPs will issue a 56-bit IPv6 prefix (if you ask them over DHCPv6). So something like 2001:1001:1001:1100::. The 56 refers to the bits, i.e. the significant figures of that example IP (those last two 00s aren’t a part of it). With that prefix, your router will create a subnet, say 2001:1001:1001:1101/64 and will sit at the IP 2001:1001:1001:1100::1. Maybe the first DHCP client to come online will be given the IP 2001:1001:1001:1100::2. That’s neat, although in practice, my router was granting IPs based on mac address (something that I ordinarily like to configure in my IPv4 networks actually).

The real downside of migrating to a dual-stack network was the fact that Virtualbox gets a little weird when you try to use IPv6. I wound up needing to apply various workarounds to get everything building fine again.

Kubernetes and GPUs

This post is running a bit long, but I can not believe how easy it is to hook GPUs into kubernetes. I really have to hand it to the Nvidia people, they had a rough start in the linux world, but they sure have their act together in 2024. This coming week I hope I get time to design a PVC-based artifact versioning system to go along with some new hardware I’ve been excited to put to use.

Smart Light Debacle

I’m so plagued by bad smart switches. I recently flashed Tasmota to a relay because I needed to use some high-performance consumer hardware remotely. I had a great experience using a SparkFun Serial Basic Breakout - CH340G to clean out all the presumed malware in a store-bought board. I thought I could get away with the same thing with a smart light switch motion sensor, but as it would turn out, they changed platforms to a chip I can’t write to. I bought another switch and again found that they had changed designs. The board I have to work with is going to take a microscope to solder RX/TX leads to.

Apple and iO$

So everyone knew this from the beginning, but I finally found the time to do some iOS development and now realize, it’s not as bad as it was before, but it’s still super annoying. In order for me, an innocent technologist, to install an iOS app on my own iPhone, I need to either pay $300 a year, or put up with some Apple nag-ware that forces me to re-deploy it to my phone ~once a week~ every week for the rest of my life. I already have a cell phone plan, what is this extra $300 for? Anyway, shame on me for adopting iPhone after I fell in love with not having to deal with the linux distro world’s issues.

Upcoming Technology Ambitions

Categories: private-cloud