Hyper-V and its sub-features.\n ![\"\"](\"https://static.achrinza.com/media/articles/running-bosh-lite-on-windows-11/windows-feature-on-off-hyper-v.png\")
Cloud Foundry BOSH is a powerful tool that provides a\nstandard for packaging software, deploying it, and especially for managing\nday-2 operations (including health checks, gradual rollouts, self-healing, and\nmetrics!).
\n\nGetting started with BOSH can seem quite daunting as production setups assume\nyou’re using it to manage a bunch of virtual machines on a platform like AWS\nor vSphere. But don’t fret! For local development, there’s BOSH Lite, a\nlightweight setup crammed into a single VM.
\n\n \n \n *** BOSH (Typical) *** \n \n ┌───────────────────────────────────────────┐\n ┌──────────────┼────────┐ ┌───────────┐ │\n┌──────┼─────┐ │┌───────┼──┼────┐┌─────┼──────────────────┐│\n│ ┌────┴───┐ │ ││┌──────▼──▼───┐││┌────▼─────┐┌──────────┐││\n│ │BOSH CLI├─┼─┐ ┌───┼┼┤BOSH Director││││BOSH Agent││Deployment│││\n│ └────────┘ │ │ │ ││└─────────────┘││└──────────┘└──────────┘││\n│Dev Machine │ │ │ ││Virtual Machine││ Virtual Machine ││\n└────────────┘ │ │ │└───────────────┘└────────────────────────┘│\n │ └───► │\n └──────► Platform │\n └───────────────────────────────────────────┘\n \n \n *** BOSH Lite *** \n \n ┌────────────────────────────────────────────┐\n ┌─────────────┼────────┐ │\n │ │┌───────┼──────────────────────────────────┐│\n │ ││ │ ┌───────────┐ ││\n┌──────┼─────┐ ││ │ │ ┌─────┼──────────────────┐││\n│ ┌────┴───┐ │ ││┌──────▼──▼───┐ │┌────▼─────┐┌──────────┐│││\n│ │BOSH CLI├─┼──┐ │││BOSH Director│ ││BOSH Agent││Deployment││││\n│ └────────┘ │ │ ││└──────┬──────┘ │└──────────┘└──────────┘│││\n│Dev Machine │ │ ││ └────────► Garden Container │││\n└────────────┘ │ ││ └────────────────────────┘││\n │ ││ Virtual Machine ││\n │ │└──────────────────────────────────────────┘│\n └────► Platform │\n └────────────────────────────────────────────┘\n\nCompared to a typical setup, BOSH Lite swaps the BOSH Director’s Cloud\nProvider Interface’s (CPI) Provider - the abstraction code that enables BOSH\nto interact with platforms - for Warden (used to interact with Cloud Foundry’s\nown container runtime, Warden ahem,\nGuardian) while the\nephemeral Bootstrap BOSH (that’s bosh create-env) retains the original\nplatform’s CPI Provider. This creates a split-CPI Provider setup which can\nseem confusing at first. But as the diagram above shows, it’s actually not too\ndifferent!
BOSH Lite can used on top of any BOSH-supported platforms, but more likely\nthan not it’s used on either VirtualBox or Docker. Although Docker is the\nnow-preferred\nplatform for local BOSH development, the VirtualBox support is more\nfeature-complete,\nbetter-documented, and mature.
\n\nThis guide will provide steps for spinning up a Windows 11 VirtualBox BOSH\nenvironment with the BOSH CLI via Windows Subsystem for Linux 2 (WSL 2).
\n\nUnlike prior\nguides,\nthis also works with the newer WSL 2 mirrored networking\nmode\nand limits changes to within WSL 2 and one Hyper-V vSwitch and vEthernet\nadapter pair.
\n\nMost BOSH CPIs (including VirtualBox), and by extension the bosh create-env\n command, do not support\n Windows. Therefore,\n it’s recommended to run the command under WSL 2. However:
VBoxManage CLI and passes untransformed\n Linux paths for stemcell uploadsbosh CLI on the WSL 2 environment\n\n\nA word of caution
\n\nFollowing this guide will necessarily alter the security model such that\nthe BOSH Director becomes routable to and from other virtual machines on\nthe host machine rather than just the host operating system. For typical\ndevelopment machines where running VMs are trusted, this should not be an\nissue.
\n
This is needed to leverage Hyper-V’s vSwitch to expose a network adapter with\na routable IP address. Our VirtualBox VMs will attach to this network adapter\ninstead of VirtualBox’s host-only network.
\n\nHyper-V and its sub-features.\n Go to “Action” > “Virtual Switch Manager”
\n\n![\"\"](\"https://static.achrinza.com/media/articles/running-bosh-lite-on-windows-11/hyper-v-open-virtual-switch-manager.png\")
Click OK
\n\n![\"\"](\"https://static.achrinza.com/media/articles/running-bosh-lite-on-windows-11/hyper-v-internal-network-config.png\")
\n\n\nTip
\n\nWhen creating a vSwitch in the previous section, a network adapter managed\nby Hyper-V (called “vEthernet”) is also created. Here, we’ll configure\nthis adapter to be routable.
\n
Right-click on the newly-created network adapter and click “Properties”. It\ncan be identified by the vSwitch name from the previous section:\nvEthernet (<vSwitch Name>).
![\"\"](\"https://static.achrinza.com/media/articles/running-bosh-lite-on-windows-11/windows-network-connection.png\")
Note down the network adapter’s name listed under “Connect using”.
\n\n![\"\"](\"https://static.achrinza.com/media/articles/running-bosh-lite-on-windows-11/windows-network-connection-properties.png\")
\n\nNote
\n\nYour network adapter name may differ from the example.
\n
Set the IP address and subnet mask.
\n\n\n\n\nNote
\n\nThis example uses the subnet
\n10.150.250.0/24, though it can be\nconfigured to any unused subnet.192.168.56.0/24is not used to avoid\nconflict with the default VirtualBox host-only network.
![\"\"](\"https://static.achrinza.com/media/articles/running-bosh-lite-on-windows-11/windows-network-connection-ipv4-properties.png\")
VBoxManage CLI to WSL 2In the WSL 2 environment, add the VBoxManage WSL 2\nwrapper:
\n\ncurl -LO https://git.sr.ht/~achrinza/vboxmanage-wsl2-wrapper/blob/main/VBoxManage.sh\nchmod +x VBoxManage.sh\nsudo mv VBoxManage.sh /usr/local/bin/VBoxManage\nBecause the networking stack differs from what bosh-deployment covers,\nwe’ll need to create a new Ops File:
# ./virtualbox-wsl2.yml\n- name: /networks/name=default/subnets/0/cloud_properties?\n type: replace\n value:\n type: bridged\n # Replace this with your network adapter name:\n name: \"Hyper-V Virtual Ethernet Adapter #4\"\n\n\n\nNote
\n\nDo not confuse this with the vSwitch name. The network adapter name is\nautogenerated and should start with
\nHyper-V Virtual Ethernet Adapter #.
From there, we can follow the standard VirtualBox\ndeployment, appending\nour new Ops File and altering the internal network variables:
bosh create-env ~/workspace/bosh-deployment/bosh.yml \\\n --state ./state.json \\\n -o ~/workspace/bosh-deployment/virtualbox/cpi.yml \\\n -o ~/workspace/bosh-deployment/virtualbox/outbound-network.yml \\\n -o ~/workspace/bosh-deployment/bosh-lite.yml \\\n -o ~/workspace/bosh-deployment/bosh-lite-runc.yml \\\n -o ~/workspace/bosh-deployment/uaa.yml \\\n -o ~/workspace/bosh-deployment/credhub.yml \\\n -o ~/workspace/bosh-deployment/jumpbox-user.yml \\\n+ -o ./virtualbox-wsl2.yml \\\n --vars-store ./creds.yml \\\n -v director_name=bosh-lite \\\n- -v internal_ip=192.168.56.6 \\\n- -v internal_gw=192.168.56.1 \\\n- -v internal_cidr=192.168.56.0/24 \\\n+ -v internal_ip=10.150.250.6 \\\n+ -v internal_gw=10.150.250.1 \\\n+ -v internal_cidr=10.150.250.0/24 \\\n -v outbound_network_name=NatNetwork\nThen, we can alias the BOSH environment:
\n\nexport BOSH_CLIENT=admin\nexport BOSH_CLIENT_SECRET=\"$(bosh int ./creds.yml --path /admin_password)\"\nbosh alias-env vbox -e 10.150.250.6 --ca-cert <(bosh int ./creds.yml --path /director_ssl/ca)\nNow we have a functioning BOSH environment! To start testing out BOSH, we can\ntry the classic ZooKeeper deployment (with some\nmodifications):
\n\nbosh -e vbox update-cloud-config ~/workspace/bosh-deployment/warden/cloud-config.yml\n# Get the latest `upload-stemcell` command from: https://bosh.io/stemcells/bosh-warden-boshlite-ubuntu-noble\nbosh upload-stemcell --sha1 cda735071b3d91349b90ee3309ef8d16cfe2dc74 \\\n \"https://bosh.io/d/stemcells/bosh-warden-boshlite-ubuntu-noble?v=1.460\"\nbosh -e vbox -d zookeeper deploy <(curl -L https://github.com/achrinzafork/zookeeper-release/raw/b9a3df6abefb2a853738c99c200eaa93892f8f55/manifests/zookeeper.yml)\nbosh -e vbox -d zookeeper run-errand smoke-tests\nBOSH is an underrated, mature tool for managing VMs, but getting started on\nWindows is more confusing than it needs to be. For me, this meant more time\nspent trying to set up BOSH before being able to actually learn it. The setup\ndescribed above is what I use today for local BOSH development on Windows - A\nquick way to get started with minimal fuss. That’s why I wrote this article\nwith a BOSH Lite explainer and a networking guide; It’s what I wish I knew\nwhen first starting with BOSH, and I hope it comes in handy for those who want\nto get started quickly.
\n", "date_published": "Fri, 17 Jul 2026 00:00:00 +0000" }, { "id": "https://www.achrinza.com/blog/2024/08/05/protecting-against-malicious-dependencies-with-flatpak", "url": "https://www.achrinza.com/blog/2024/08/05/protecting-against-malicious-dependencies-with-flatpak", "title": "Protecting against malicious dependencies with Flatpak", "content_html": "Flatpak is a great tool for installing user applications in a self contained environment without polluting the host machine. This mitigates a range of issues, notably dependency hell. There’s even packages for popular code editors such as VSCode/VSCodium and Emacs.
\n\nIn fact, I code in Emacs purely through Flatpak. Not for the above reasons per-se, but for something more valuable - to contain the blast radius.
\n\nAn issue that plagues vitually every software development project nowadays is the abundant use of third-party dependencies. This issue is more prevalent in some ecosystems such as Node.js where many small packages tend to be preferred over larger, batteries-included packages. This means more code written by many different people.
\n\nIt’s impossible to vet every single dependency and the intentions of their maintainers. Hence it becomes an exercise of trust that the maintainers protect their publishing credentials from compromise or to not go rogue. But every now and then, it happens.
\n\nThese malicious packages can be quickly authored and easily compromise a developer’s machine and privileged credentials. Hence, we need a broad, defensive approach towards mitigating the impact of such a compromise.
\n\nThis is where Flatpak sandboxing comes in. It restricts an application’s ability to access certain resources such as network, dbus, devices, and filesystem - the last one’s what we’ll talk about.
\n\nIn a perfect world, Flatpak apps would be configured to use Flatpak Portals - A mechanism to give granular, just-in-time access to a certain directory or file in the host file system with explicit user consent. However, anecdotally most apps don’t support Portals. Furthermore, the subtle incompatibilities with certain tools and the inability to auto-revoke the access at the end of each session makes the experience feel especially clunky.
\n\nAs a compromise, it is by convention, that most Flatpak developer-centric apps are pre-configured with broad filesystem access. This provides out-of-the-box usability without the need for Portals. This does mean that the app environment can interact with most of the host filesystem.
\n\nWe can see the permissions with flatpak info --show-permissions <app-id>:
$ flatpak info --user --show-permissions org.gnu.emacs\n[Context]\nshared=network;ipc;\nsockets=x11;pulseaudio;\nfilesystems=/var/tmp;/tmp;host;\n\n[Session Bus Policy]\norg.freedesktop.Flatpak=talk\nAs we can see, my Flatpak-installed Emacs has access to the entire host filesystem. If you’d like to learn more about these permissions, the Flatpak docs is a great reference.
Also note that I’m using the --user flag as I did not install Emacs system-wide. If your app is installed system-wide, omit this flag.
As the name suggests, Flatpak overrides allow us to override the default permissions. If we want to block host filesystem access, we simply counter it with its negative:
$ flatpak override --user --nofilesystem=host org.gnu.emacs\nRunning the same flatpak info command as above, we can see the host filesystem is no longer there:
$ flatpak info --user --show-permissions org.gnu.emacs\n[Context]\nshared=network;ipc;\nsockets=x11;pulseaudio;\nfilesystems=/var/tmp;/tmp;\n\n[Session Bus Policy]\norg.freedesktop.Flatpak=talk\n\n\n\nNote: When performing
\nflatpak override, double-check that the app name is spelled correctly. Flatpak does not verify if the app actually exists! To fix this, simply re-run the command with the correct app name. Though there’s still a stray override config that we might want to delete - I’ll explain how to find and delete it below.
If we now create a new file in Flatpak Emacs, the file does not appear in the host filesystem. Instead, it’s saved in an ephemeral filesystem that gets wiped when this instance of Emacs is closed.
\n\nTo give granular access to the filesystem, we need to decide what that granularity is. For me, access is given on a per-project basis (i.e. per-Git repository). This is a good compromise as it prevent unwanted access and alteration of other projects whilst allowing the tools in the active project to function correctly.
\n\nWith this setup, whenever we want to work on a project we can simply run these commands:
\n\n$ cd <project directory>\n$ flatpak run --user --filesystem=\"$(pwd)\" org.gnu.emacs\nThe main difference is the addition of --filesystem=\"$(pwd)\" which gets the current working directory (via pwd), and tells Flatpak to perform a one-time override to allow filesystem access. This override only applies to that instance of the app, and we can open multiple projects on separate instances with access to different parts of filesystem - no cross-mingling of permissions.
We can even package this into a wrapper called emc (my shorthand for Emacs):
$ sudo su -c 'cat <<EOF >>/usr/local/bin/emc\n#!/bin/sh\nflatpak run --user --filesystem=\"$(pwd)\" org.gnu.emacs @\nEOF'\n\n$ sudo chmod +x /usr/local/bin/emc\nNow we can give just-in-time, granular access just as easily as starting any other programme:
\n\n$ cd <project directory>\n$ emc\nflatpak override is quite rudementary, and it’s easy to make mistakes like typos in the app name. This can lead to stray or cluttered override files. Their location depends if the override was done with the --user or --system flag (no flag defaults to --system).
/var/lib/flatpak/overrides/<app-id>~/.local/share/flatpak/overrides/<app-id>If we inspect the file, we can see that it contains our overrides, and has the same syntax as the output of flatpak info --show-permissions:
$ cat ~/.local/share/flatpak/overrides/org.gnu.emacs\n[Context]\nfilesystems=!host;\nWe can modify this file by hand, or even delete it entirely if we want to get back the default permissions.
\n\nThere are some limitations that I’ve personally stumbled into:
\n\nflatpak document-unexport. Automating this is left as an exercise for the reader.Flatpak can be a simple but powerful tool to protect yourself from the impact of running malicious code. It’s not a full replacement for a true-sandboxed virtual machine environment nor for a proper antivirus solution, but it can signficantly mitigate the reach of the malware. When you get compromised, killing the Flatpak instance, then re-cloning the project should be enough for trivial cases.
\n\nThis just-in-time approach to filesystem sandboxing is something I use daily, and its ease of use has made it an easy habit to adopt with little downsides. If you’re just starting out on your Flatpak journey, or have already used it for a while, I hope this guide help you learn how you can control Flatpak to improve your security posture.
\n", "date_published": "Mon, 05 Aug 2024 00:00:00 +0000" }, { "id": "https://www.achrinza.com/blog/2024/08/02/a-site-refresh", "url": "https://www.achrinza.com/blog/2024/08/02/a-site-refresh", "title": "A site refresh", "content_html": "\n\nIt’s been a while, and that means it’s time for a website refresh!
\n\nThe previous iteration of my personal website served its needs well - It was simple, a single page, and contained my a breif introducer, and how to reach out to me.
\n\nSince then, I’ve continued to grow professionally and personally - I got my Diploma, took up my certifications, and had been on the job a bit longer. In addition, I wanted to share my knowledge and personal experiences - many of which are kept in my personal notes - for others to read.
\n\nThe old website was no longer feasible - It was a plain HTML file crafted by hand, and did not have any blogging capabilities.
\n\nHence, the website you’re reading this on was born.
\n\nI wanted the design to be personal, yet easy to manage. Thus a content-first style was created.
\n\nIt retains the same simplicity as my previous website with few distractions and content right in the center. This works with the content-heavy nature of the website and is one I hope people can appreciate.
\n\nIf I were a website designer, it may have had more bling, but designer I am not. Though admittedly it’s still quite… empty. Nonetheless, it’s a starting point so that I can start publishing new content sooner than later, and I do plan to make minor tweaks and give it more personality over time.
\n\nI wanted the most control over the generated HTML, without the bloat of unecessary JavaScript that comes with front-end frameworks. Naturally, a static site generator was a good fit - Most include a blogging feature, and don’t inject unecessary stuffs.
\n\nAs to why Jekyll? It was what’s most familiar. I may consider switching to Eleventy, but for now this’ll suffice.
\n\nI intend to start pubishing on this blog with some frequency, maybe once a week or so. Whether its technical guides, personal experiences, or just some random topic, I hope this would encourage me to write, and learn how to better express my thoughts into something more engaging and readable over time.
\n\nOr at least, that’s the intended goal. We’ll see how it goes.
\n", "date_published": "Fri, 02 Aug 2024 00:00:00 +0000" } ] }