Security in depth / zero trust is a 100% (awesome) PITA
Today I spent upwards of half my day deploying a single service into a client's cluster. Here's why I consider this to be a win...
Today I spent upwards of half my day deploying a single service into a client's cluster. Here's why I consider this to be a win...
Has your wife been wishing for a way to consume her DRM-stripped audiobooks on her phone, without having to resort to side-loading apps or media? Fear not, for this new recipe has received 10/10 WAF (wife-acceptance-factor)...
When setting up my Mastodon instance, I jumped directly to storing all media in object storage (Backblaze B2, in my case), because I didn't want to allocate / estimate local storage requirements.
This turned out to be a great decision, as my media bucket quickly grew to over 100GB, but as a result, all of my media was served behind URLs like https://f007.backblaze.com/file/something/something-else/another-something.jpg
, and could technically be scraped without using my Mastodon URL.
Here's how to improve this, and also serve your Mastodon instance from behind a CloudFlare proxy...
I work on several large clusters, administered using FluxCD, which in which we carefully manage the update of Helm releases using Flux's HelmRelease
CR.
Recently, we've started using Renovate to alert us to pending upgrades, by creating PRs when a helm update or an image update in the associated helm values.yaml is available (I like to put the upstream chart's values in to the HelmRelease
so that changes can be tracked in one place)
The problem is, it's likely that the images in a chart's values.yaml
will be updated when the chart is updated, but I don't need a separate PR for each image! (imagine a helm chart with 10 image references!)
The first time I tried this, I ended up with 98 separate PRs, so I made some changes to Renovate to try to "bundle" associated helmrelease / helm values together...
I'm approaching the end of the journey of applying Velero to a client's "hardened" Kubernetes cluster, and along the way I stubbed my toes on several issues, which I intend to lay out below...
Prior to v0.13, MetalLB was configured using a ConfigMap. This has all changed now, and CRDs are required to perform configuration (which improves syntax checking, abong other things)
There are plenty of tutorials out there about how to run a highly-available kubernetes api-server behind haproxy. Without exception however, these tutorials configure haproxy to "check" the health of the backends with a simple TCP connection. These can produce a false sense of security though...
After spending hours debugging why a particular pod can't properly communicate with another pod via Istio's service mesh, I stumbled into the answer..
New recipe - Pixelfed, like Instagram on the Fediverse. Check it out here.
Immich is a promising self-hosted alternative to Google Photos. Its UI and features are clearly heavily inspired by Google Photos, and like Photoprism, Immich uses tensorflow-based machine learning to auto-tag your photos!