2
Apr, 2021
Technology Short Take 139
CloudWelcome to Technology Short Take #139! This Technology Short Take is a bit heavy on cloud, OS, and programming topics, but there should be enough other interesting links to be useful to plenty of folks. (At least, I hope that’s the case!) Now, let’s get on to the content!
Networking
- Tony Mackay has a tutorial showing how to use Traefik to rate-limit requests to a WordPress instance.
- Ali Al Idrees has a post on using NSX ALB (formerly Avi Networks) with Kubernetes clusters in a vSphere with Tanzu environment.
- This post provides some examples of shared control planes (and thus shared failure domains) within networking.
- In this post, Jakub Sitnicki digs way deep into the Linux kernel to uncover the answer to the question, “Why are there no entries in the conntrack table for SYN packets dropped by the firewall?” Get ready to get nerdy!
- This article on eBPF and Isovalent (the company behind the Cilium CNI plugin for Kubernetes) has some statements with which I agree, and some that don’t make sense to me. For example, I agree with the statement that the “impact eBPF will have on networking, security and observability will be widespread”. However, I don’t understand how eBPF will “reduce reliance on legacy network overlays”. I could see how eBPF will change how network overlays are implemented, sure, but reduce the reliance on network overlays? I’m not sure about that. If you have strong feelings about this, hit me on Twitter and let’s discuss.
Servers/Hardware
- Dominic Hopton shares a sordid tale of getting three monitors to work with a 13” MacBook Pro.
Security
- Linux malware is getting more sophisticated.
- A browser-based side-channel attack? Even worse, this isn’t just limited to Intel chips, but may also affect ARM-based systems like Apple’s M1 CPUs. Further, turning off JavaScript doesn’t help. Ugh.
- Given the prevalence of VMware’s ESXi hypervisor, I suppose it was only a matter of time before the bad guys really started targeting it in a major way. This time, they’re exploiting a weakness that VMware can’t patch: people.
- A while ago I chatted with the folks at Indeni about Cloudrail, a security solution for infrastructure-as-code environments.
Cloud Computing/Cloud Management
- Patrick Kremer writes about using vRealize Log Insight Cloud to monitor for firewall changes in a VMware Cloud on AWS environment.
- Aye aye, Popeye!
- Daniel Mangum’s post on Crossplane as the infrastructure LLVM is (in my opinion) a great read, particularly so if you’re interested in the intersection of Kubernetes and infrastructure as code.
- Here’s a post on installing and configuring containerd as a Kubernetes container runtime.
- If you’re a DynamoDB user, check out this list of 29 DynamoDB best practices compiled by Rafal Wilinski.
- Marcin Cuber discusses process and considerations for upgrading EKS to version 1.19.
- Need to list assets across multiple cloud providers? Check out
cloudlist.
Operating Systems/Applications
- This announcement of the Scarf Gateway popped into my Twitter timeline recently, and after taking a look at how the Scarf Gateway is described I can see how this is an important addition to companies’ secure software supply chain efforts, especially in the beginning. Why in the beginning? Because that’s when you’re struggling to understand the dependencies of your software supply chain, and the Scarf Gateway provides that sort of visibility (as I understand it).
- This is handy.
- Ben Kehoe shares his favorite Zoom tips.
- How about an OCI runtime for FreeBSD Jails?
xhappears to be an as-yet-incomplete reimplementation of HTTPie in Rust. Check out the GitHub repository.- Jan Grzegorowski shares how to remap a single Mac keyboard key using
hidutil. - I just recently learned about
sox, which I think of as the audio file equivalent of ImageMagick.
Programming
- A fair amount of this article was over my head, but I still enjoyed reading about how Tailscale built a new IP address type for Go.
- Francisco Trindade launches a series of posts that tackle the prevalent use of pull requests (PRs) in software development with the statement that PRs are considered harmful.
- Here’s a list of 10 advanced Git tips to help improve your developer workflow (be aware this appears to be an HTTP-only site).
- Some of these repositories may be worth checking out.
Storage
- This post from Enterprise Storage Forum attempts to provide a comparison of cloud storage between AWS and Google Cloud. Frankly, though, I found the article to be a bit unfocused, also discussing other cloud services instead of really concentrating on being the best comparison of cloud storage services. Maybe that’s just me, though.
Virtualization
- Mike Foley shares details on a new feature in vSphere 7 Update 2 that leverages AMD-specific functionality to create what are called “Confidential Containers.”
Happy reading and learning! If you have any questions, comments, suggestions for improvement, or other feedback, I’m always happy to hear from you. Contact me on Twitter and let’s chat!
…
1
Apr, 2021
Using WireGuard on macOS
CloudA short while ago I published a post on setting up WireGuard for AWS VPC access. In that post, I focused on the use of Linux on both the server side (on an EC2 instance in your AWS VPC) as well as on the client side (using the GNOME Network Manager interface). However, WireGuard is not limited to Linux, and I recently configured one of my macOS systems to take advantage of this WireGuard infrastructure for access to the private subnets in my AWS VPC. In this post, I’ll walk readers through configuring macOS to use WireGuard.
The first step is installing WireGuard on macOS. This is remarkably easy; just go to the App Store and install the WireGuard app for macOS. (Hopefully this link will take you directly there if you’re on a macOS-based system.)
Once the app is installed, the next step is to configure the WireGuard tunnels. I found this to be a bit confusing at first, but only because I wasn’t clear on the relationship between the WireGuard app and the Network pane in System Preferences. In this case, you need to use the WireGuard app to create the tunnels, which will show up as connections (interfaces) in the Network pane of System Preferences.
Running the WireGuard app will put an icon on your menu bar, and should bring up the “Manage WireGuard Tunnels” window. If not, select “Manage Tunnels” from the WireGuard menu icon; this will open the “Manage WireGuard Tunnels” window. From there, you can select the small plus in the lower left corner and select “Add Empty Tunnel…” from the menu. This displays a dialog box something like this:
This will automatically create a new set of public and private keys, and auto-populate the start of a new WireGuard interface configuration. (Don’t worry; these keys aren’t valid for any interfaces/connections.) It’s up to you to finish the configuration by adding directives such as Endpoint, AllowedIPs, and Address. It’s an interesting sort of mismatch to have such a well-designed graphical application, but not provide any guidance or structure to the user on how to configure the interface/tunnel.
Ultimately, you’d need the configuration to look something like this:
[Interface]
PrivateKey = <some private key here>
Address = <IP address of WireGuard interface> [Peer]
PublicKey = <public key of WireGuard peer interface>
AllowedIPs = <IP addresses or CIDR ranges to be routed across the tunnel>
Endpoint = <peer endpoint IP and port>
If you’re behind a NAT, you may also want to add the PersistentKeepalive = 25 value to the configuration as well (see the “NAT and Firewall Traversal Persistence” section of this page). Next you’ll need to configure the peer with the appropriate configuration. If the peer is Linux-based, you can use the information in my earlier blog post; if the peer is macOS, then use the instructions in this post. For anything else, refer to the WireGuard web site.
Once both sides of the connection are configured, then you should be able to activate the tunnel and start passing traffic. If traffic won’t pass successfully, then check the interface configuration on both sides, and make sure any firewalls along the path allow the traffic. The WireGuard connection will look like this in the Network pane of the System Preferences app (IP addresses have been blacked out):
Repeat this process to add more tunnels/connections; each of them will show up as a menu item in the WireGuard menu icon, and you can select them to activate/deactivate the connection. Also note that selecting the “On-Demand” option when creating the tunnel will let WireGuard automatically establish the tunnel when you start passing traffic (assuming both ends are configured).
I hope this information helps. I found the interface to be a bit unintuitive, but after working with it for a little while it doesn’t feel so awkward now. Hopefully this walkthrough will make getting WireGuard set up and configured on macOS a bit easier for others. Thanks for reading, and hit me on Twitter if you have any questions, comments, or other feedback!
…
1
Apr, 2021
Using WireGuard on macOS
CloudA short while ago I published a post on setting up WireGuard for AWS VPC access. In that post, I focused on the use of Linux on both the server side (on an EC2 instance in your AWS VPC) as well as on the client side (using the GNOME Network Manager interface). However, WireGuard is not limited to Linux, and I recently configured one of my macOS systems to take advantage of this WireGuard infrastructure for access to the private subnets in my AWS VPC. In this post, I’ll walk readers through configuring macOS to use WireGuard.
The first step is installing WireGuard on macOS. This is remarkably easy; just go to the App Store and install the WireGuard app for macOS. (Hopefully this link will take you directly there if you’re on a macOS-based system.)
Once the app is installed, the next step is to configure the WireGuard tunnels. I found this to be a bit confusing at first, but only because I wasn’t clear on the relationship between the WireGuard app and the Network pane in System Preferences. In this case, you need to use the WireGuard app to create the tunnels, which will show up as connections (interfaces) in the Network pane of System Preferences.
Running the WireGuard app will put an icon on your menu bar, and should bring up the “Manage WireGuard Tunnels” window. If not, select “Manage Tunnels” from the WireGuard menu icon; this will open the “Manage WireGuard Tunnels” window. From there, you can select the small plus in the lower left corner and select “Add Empty Tunnel…” from the menu. This displays a dialog box something like this:
This will automatically create a new set of public and private keys, and auto-populate the start of a new WireGuard interface configuration. (Don’t worry; these keys aren’t valid for any interfaces/connections.) It’s up to you to finish the configuration by adding directives such as Endpoint, AllowedIPs, and Address. It’s an interesting sort of mismatch to have such a well-designed graphical application, but not provide any guidance or structure to the user on how to configure the interface/tunnel.
Ultimately, you’d need the configuration to look something like this:
[Interface]
PrivateKey = <some private key here>
Address = <IP address of WireGuard interface> [Peer]
PublicKey = <public key of WireGuard peer interface>
AllowedIPs = <IP addresses or CIDR ranges to be routed across the tunnel>
Endpoint = <peer endpoint IP and port>
If you’re behind a NAT, you may also want to add the PersistentKeepalive = 25 value to the configuration as well (see the “NAT and Firewall Traversal Persistence” section of this page). Next you’ll need to configure the peer with the appropriate configuration. If the peer is Linux-based, you can use the information in my earlier blog post; if the peer is macOS, then use the instructions in this post. For anything else, refer to the WireGuard web site.
Once both sides of the connection are configured, then you should be able to activate the tunnel and start passing traffic. If traffic won’t pass successfully, then check the interface configuration on both sides, and make sure any firewalls along the path allow the traffic. The WireGuard connection will look like this in the Network pane of the System Preferences app (IP addresses have been blacked out):
Repeat this process to add more tunnels/connections; each of them will show up as a menu item in the WireGuard menu icon, and you can select them to activate/deactivate the connection. Also note that selecting the “On-Demand” option when creating the tunnel will let WireGuard automatically establish the tunnel when you start passing traffic (assuming both ends are configured).
I hope this information helps. I found the interface to be a bit unintuitive, but after working with it for a little while it doesn’t feel so awkward now. Hopefully this walkthrough will make getting WireGuard set up and configured on macOS a bit easier for others. Thanks for reading, and hit me on Twitter if you have any questions, comments, or other feedback!
…
