Marco Lazzarotto

Mitigating the 'Copy Fail' Vulnerability (CVE-2026-31431) with a Simple Ansible Playbook

postmaster@mlazzarotto.it (Marco Lazzarotto) — Fri, 01 May 2026 00:00:00 +0100

In a nutshell: there’s a new critical Linux bug going around

‘Copy Fail’ is a new and nasty local privilege escalation bug, CVE-2026-31431, discovered by the analyst team at Xint Code.

This bug essentially allows an attacker to gain root privileges on many Linux operating systems (Ubuntu, Debian, RHEL, Suse, Alma, Amazon Linux) using a Python script of just 732 bytes.

‘Copy Fail’ only requires a local unprivileged user account: no network access, no kernel debug capabilities, no pre-installed libraries. The kernel’s cryptographic API (AF_ALG) is enabled by default on virtually all major distributions, meaning the entire patch range from 2017 onward is vulnerable.

Understanding the ‘Copy Fail’ vulnerability

In simple terms, imagine the Linux kernel keeping a copy of files in memory to avoid reading from disk every time — the so-called page cache. This cache is normally used to speed up certain kernel operations. All good.

Then, however, algif_aead comes into play — one of the Linux kernel modules that exposes the cryptographic subsystem to userspace via the AF_ALG interface. In plain English? An API for cryptographic services, used for example in protocols like IPsec.

Back in 2017, this kernel module was modified to make it more “efficient.” It was essentially told: “Instead of making a copy of the document (the file) you need to work on, write directly onto the original that the kernel passes you in the page cache” — thanks to a system call named splice() that passes data by reference instead of copying it.

This in-place optimization is the root of the problem, because it allowed a user to write data where they absolutely should not have been able to.

And what data can an attacker write? They can overwrite a small portion of /usr/bin/su to make it possible to run su and become the root user.

The ‘ghost’ aspect

One of the most insidious things about this vulnerability is that the modification only happens in RAM. The file on disk remains untouched.

This means all classic file integrity monitoring systems (such as Tripwire, AIDE, Wazuh, etc.) see nothing unusual. This is extremely dangerous because it leaves no traces on disk.

Container escape

Earlier we mentioned the page cache — that portion of memory used to speed up kernel operations. Well, the page cache is shared across all containers on the same host (Podman, Docker, Kubernetes, etc.).

This means that a vulnerable container, or one infected through a supply chain attack, can perform container escape in a frighteningly simple way.

The Ansible playbook for immediate mitigation

Drawing inspiration from the Morrolinux KB and this Github gist by user m3nu, I created an Ansible playbook available at copy-fail-CVE-2026-31431-mitigation-ansible-playbook that allows you to apply the mitigation and roll it back after a kernel update.

tasks:
 - name: Apply Mitigation
 tags: [mitigation]
 when: not (rollback | bool)
 block:
 # --- Debian family modprobe blacklist + unload ---
 - name: Apply modprobe blacklist (Debian family)
 when: ansible_facts['os_family'] == 'Debian'
 block:
 - name: Create modprobe blacklist for {{ target_module }}
 ansible.builtin.copy:
 dest: "{{ modprobe_conf_path }}"
 content: |
 # Generated by Ansible — CVE-2026-31431 mitigation
 install {{ target_module }} /bin/false
 owner: root
 group: root
 mode: "0644"

 - name: Unload module {{ target_module }} if currently loaded
 community.general.modprobe:
 name: "{{ target_module }}"
 state: absent
 register: rmmod_result
 failed_when:
 - rmmod_result is failed
 - >-
 'not currently loaded' not in (rmmod_result.msg | default(''))
 and 'not currently loaded' not in (rmmod_result.stderr | default(''))
 - >-
 'is in use' not in (rmmod_result.msg | default(''))
 and 'is in use' not in (rmmod_result.stderr | default(''))

 - name: Remind operator to reboot if module was in use (Debian)
 when: >-
 'is in use' in (rmmod_result.msg | default(''))
 or 'is in use' in (rmmod_result.stderr | default(''))
 ansible.builtin.debug:
 msg: "REMINDER: Module was in use and could not be unloaded. Reboot required to complete mitigation."

 # --- kernel initcall blacklist (RHEL/Alma 9 and 10 only) ---
 - name: Apply kernel initcall blacklist (Red Hat family)
 when:
 - ansible_facts['os_family'] == 'RedHat'
 - ansible_facts['distribution_major_version'] in ['9', '10']
 block:
 - name: Check current grubby kernel args (pre-change)
 ansible.builtin.command: "grubby --info=ALL"
 register: grubby_info_pre
 changed_when: false
 check_mode: false

 - name: Add '{{ target_kernel_arg }}' to all kernels via grubby
 ansible.builtin.command:
 cmd: "grubby --update-kernel=ALL --args='{{ target_kernel_arg }}'"
 register: grubby_add_result
 changed_when: target_kernel_arg not in grubby_info_pre.stdout

 - name: Remind operator to reboot (RHEL)
 when: grubby_add_result.changed
 ansible.builtin.debug:
 msg: "REMINDER: Kernel args changed. Reboot required to activate mitigation."

Breaking down the playbook

The playbook is compatible with RHEL-based (CentOS, Rocky, Alma) and Debian-based (Ubuntu and Mint) operating systems. By default, it uses the serial function to run the playbook on a limited number of hosts at a time — 25% by default. For example, with 100 hosts in the inventory, the mitigation will be applied to 25 hosts in the first batch, 25 in the second, and so on.

The max_fail_percentage function tolerates an error rate of 20%. For example, if there are 25 hosts in a batch and 6 or more fail, the job will be aborted.

The Pre Task displays some information about the operating system and kernel for each host and collects data about the system’s current state.

The Task for Debian-based distributions disables the kernel module and blacklists it; if the module is in use, it reminds the user to reboot the system. For RHEL-based distributions, it uses the grubby command to disable the module and always reminds the user to reboot.

The Post Task collects additional information and presents the user with a summary of the actions performed.

How to run it

First, you need to prepare the Ansible configuration file and inventory as you would for any Ansible playbook. Then run a ping to check server reachability. Finally, use ansible-playbook mitigation-playbook.yaml to run the mitigation on all servers, or use the --limit webservers option to restrict the playbook to a specific group of hosts. For rollback, same as above, but use the --tags rollback option to run only the rollback tasks.

Verifying that the mitigation works

After running the playbook, you need to verify that the mitigation took effect. To do so, use these two methods depending on your hosts’ distribution:

On Debian-based distributions, use lsmod | grep algif_aead.
On RHEL-based distributions, use grep initcall_blacklist /proc/cmdline.

My take: one more step for containers

Personally, my opinion is that stopping at host-level configuration is not enough if you’re running containers. Since containers share the host machine’s kernel, a reboot or a configuration error that accidentally reloads the vulnerable module would leave your workloads exposed again.

We know this exploit needs to open an AF_ALG family socket in order to communicate with the kernel’s Crypto API. For this reason, I strongly recommend implementing a “defense in depth” approach using seccomp. If you configure a custom profile for your container runtime, you can tell the system to block socket syscalls targeting AF_ALG altogether. This way, even if the algif_aead module were to magically reactivate on the host, the kernel will cut off any attempt by the container to exploit it.

An example seccomp policy:

{
 "defaultAction": "SCMP_ACT_ALLOW",
 "syscalls": [
 {
 "names": ["socket"],
 "action": "SCMP_ACT_ERRNO",
 "args": [
 {
 "index": 0,
 "value": 38,
 "op": "SCMP_CMP_EQ"
 }
 ],
 "comment": "Block AF_ALG sockets (family 38) to mitigate Copy Fail"
 }
 ]
}

Stay vigilant!

And that brings us to the end. There’s one fundamental point I want to make clear: the Ansible and modprobe-based solution we just covered is an excellent short-term fix to protect yourself immediately, but remember that it is not a permanent cure.

My personal opinion is that security workarounds should never be left sitting forgotten on servers collecting dust. Keep an eye on the security bulletins from your vendors (whether that’s Canonical, Red Hat, SUSE, or others). As soon as they release updated kernel packages with the official patch for CVE-2026-31431, schedule the installation and a proper reboot of your machines. Once your systems have the patched kernel, you can clean up and remove the files created by this playbook.

I hope this guide saved you a few headaches! If you have any doubts, questions, or want to share how you’re handling this CVE in your environments, feel free to reach out on LinkedIn or, if you need personalized consulting, you can book a call in the footer of this page.

Wall Street Relies on AI, Europe Builds Its Digital Fortress: Two Futures Compared

postmaster@mlazzarotto.it (Marco Lazzarotto) — Tue, 14 Apr 2026 00:00:00 +0100

The news is era-defining: the White House is pushing the world’s largest investment banks [1] — we’re talking about giants like Goldman Sachs, Bank of America, and Citigroup — to use Anthropic’s AI (Claude Mythos) for their cybersecurity. An alliance between government, finance, and big tech that feels like a trailer for a sci-fi movie.

But behind the spotlight of this seemingly futuristic move, two fundamental questions hide that concern us all, from Trento to San Francisco:

Is AI about to make cybersecurity experts obsolete?
While the US ties itself to a single “black box,” what is Europe doing to avoid being left behind?

Spoiler: the answers are much more complex and interesting than a simple “yes” or “no.”

The myth of “job-stealing” AI: the data says otherwise

The first instinctive reaction is fear. If an AI can perform red teaming and find vulnerabilities, what will happen to the tens of thousands of professionals who do this for a living today? [1]

Fortunately, the data comes to our rescue and paints a completely different picture. Let’s start with a striking number: according to the 2025 Fortinet Global Cybersecurity Skills Gap Report [1], 4.7 million cybersecurity professionals are missing globally. That’s not a typo. In Italy, the gap is equally serious, with about 136,000 job postings per year in the ICT sector against only 73,000 new talents entering the field [1].

AI isn’t entering a saturated market to steal jobs; it’s arriving in a sector in full emergency where human forces are no longer enough.

The real game: US Monopoly vs. European Sovereignty

According to Gartner [1], by 2026, 50% of Security Operations Centers (SOCs) will use AI as decision support. The goal is not to replace the analyst, but to give them a “superpower”: automating repetitive tasks, analyzing amounts of data unmanageable for a human, and flagging only the anomalies that require intuition and creativity. AI becomes an ally, a force multiplier that allows understaffed and stressed teams to focus on strategy instead of routine.

In my opinion, the security professional’s profile will evolve from a hyper-specialized technician to a strategist and supervisor of intelligent systems. Their task will no longer be finding the needle in the haystack, but teaching the AI how to search for the needle and, above all, understanding if what it found is actually a needle.

USA vs. Europe, Monopoly vs. Sovereignty

And here we get to the geopolitical heart of the matter.

Act One: The American bet on “everything, now”

On one side, we have Team USA. The government acts as a sponsor, and Wall Street adopts a proprietary and powerful solution en masse. Fast, efficient, centralized. The quintessence of the American approach. Even Jamie Dimon of JPMorgan, a known skeptic, was invited to the table [1] (though he did not participate). The risk? A frightening vendor lock-in. Entrusting the security of the planet’s most critical financial infrastructure to a single private provider creates a single point of failure with unimaginable consequences. And, let’s not forget, a historical precedent that teaches us to be cautious when government agencies (like the NSA) and tech giants dialogue too closely.

Act Two: The European marathon for autonomy

On the other side is Team Europe, playing a completely different game. Slower, more fragmented, but with a very clear objective: digital sovereignty. Europe has understood that technological dependence is the new energy dependence. And it’s moving. [1]

Contrary to what people think, these are not just words. The network of European Digital Innovation Hubs (EDIH), with over 200 active hubs, is helping SMEs digitize by choosing European technological solutions. It’s not just about innovating, but doing so while building an autonomous ecosystem. Furthermore, national initiatives like the “Fondo per la Repubblica Digitale” in Italy (with about 220 million euros) demonstrate an investment in closing the skills gap [1].

Two philosophies, one choice: what digital future do we want?

What we are witnessing is not just a technical debate, but a clash between two philosophies. The American approach privileges speed and power, even at the cost of centralizing power in the hands of a few giants. The European approach is more cautious, aiming to build a resilient, open, and distributed alternative, even if it requires more time and coordination.

For those working in the sector, the lesson is twofold. First: AI is not a threat, but the tool that will define the next decade. Ignoring it is not an option. Second: the choice of tools we use is never neutral. Behind software lies a business model, an ideology, and a geopolitical strategy.

The real question, then, isn’t whether we will use AI for our security, but which AI we will choose: the closed and centralized one or the open and federated one? [1]

The answer to this question will decide who controls the keys to our digital future.

Why I moved my blog from Cloudflare Pages to Kubernetes: a story of sub-directories and freedom

postmaster@mlazzarotto.it (Marco Lazzarotto) — Mon, 13 Apr 2026 00:00:00 +0100

The initial idyll: why Cloudflare Pages seemed like the perfect choice

July 25, 2022—this was the first commit on my blog’s Github repo. Previously, I used WordPress with satisfaction, but I realized I was using less than 10% of the CMS’s features for my blog, which required continuous maintenance to avoid security risks. I started looking for different tools that could give me the possibility to write a blog in a simple format (Markdown), without the need for a backend or a database, and with minimal maintenance.

It was during that search that I discovered Hugo and was immediately very satisfied from several points of view, so I decided to save my articles on Github and host the site on Cloudflare Pages, since my domain was already configured there.

The integration was perfect: a push of a new article to the master branch (back then the default branch still had that name, later replaced by main) gave the signal to Cloudflare Pages (now called Workers & Pages) that it was time to use Hugo to regenerate the static content of the site and publish it.

It was perfect; it never missed a beat, and once set up, it was the most convenient and simplest thing in the world.

A slight detour: unifying domains to attract more traffic to the portfolio

Years pass, we arrive in 2026, and I start my career as a freelancer in the networking and DevOps field. I need to bring more traffic to my portfolio site lazzarotto.dev to attract potential clients.

One of the best suggestions I received was to move the blog from mlazzarotto.it (which brought 1,000 visits in the last 90 days) and merge it with the lazzarotto.dev domain to unify the branding.

The reason was quite simple: in Google’s eyes, I had two distinct websites competing with each other:

mlazzarotto.it (the blog)
lazzarotto.dev (the portfolio)

Here I had two paths:

move the blog to the subdomain blog.lazzarotto.dev
move the blog to the path lazzarotto.dev/blog

Doing some research online, I realized that the second option was the one recommended by all the “pros” in web design and SEO.

The unexpected obstacle: the problem of mydomain.dev/blog

Cloudflare Workers & Pages works great when the static site to be published is exposed at the root of the domain (or subdomain) like https://mlazzarotto.it/, but it quickly becomes a nightmare trying to publish the website on the subpath https://lazzarotto.dev/blog due to Cloudflare’s logic.

I won’t deny that I spent several hours trying to get the workers to work to publish the site correctly, and I even got close, but there was always some issue with resources (CSS and JS) not being referenced correctly by Hugo. Therefore, the site was visible but without styling and without dynamic components.

The moment of decision: evaluating alternatives

Even though my professional focus isn’t primarily on hosting services for static sites, I explored the most common alternatives for my case.

One of the first alternatives I discarded was GitHub Pages, mainly due to an uptime that isn’t always impeccable for my standards. Added to this is my personal preference to distance myself from the Microsoft ecosystem and its current direction.

The image below was taken from https://mrshu.github.io/github-statuses/ on April 11, 2026, and objectively, it doesn’t thrill me, even though my blog doesn’t require 99.9999% uptime.

There are other solutions like Netlify and Vercel, but the problem of using a subpath to make this blog available at https://lazzarotto.dev/blog remained. Therefore, since I am already hosting my portfolio on Kubernetes using Traefik as a reverse proxy, I decided to keep the blog in my homelab as well.

The new architecture: a look at the new setup

The new architecture involves using Gitea for the repository and Continuous Integration, Kubernetes for the blog deployment, and ArgoCD for Continuous Delivery.

With these three tools, I managed to replicate the combination I used previously—Github + Cloudflare Pages—in a fairly simple (relatively) way that still allows me to have a new post published in less than 5 minutes.

Below, I will illustrate how the pipeline works.

Gitea: controlling my code

I’ve been using Gitea for a while to keep my personal projects locally, including the code for my portfolio site. I also use it as Continuous Integration software thanks to the Gitea Actions feature, which is essentially a copy of Github Actions.

In the blog repo, I created a workflow that builds a Docker image, uploads it to the Docker registry (also on Gitea), and then modifies the Kubernetes manifest so that ArgoCD updates the deployment.

The workflow configuration is quite simple and uses some external packages from Github.

Kubernetes: the orchestrator of everything

While Gitea handles the source code, Kubernetes has the task of orchestrating the pods (2 replicas) and ensuring the application is always working thanks to the implementation of health checks.

The deployment happens automatically thanks to the integration of ArgoCD, which deploys the new replicaSet as soon as Gitea modifies the manifest.

Everything happens while maintaining high reliability and without downtime.

The big picture

Below you can see the diagram of how my workflow and the pipeline between Gitea, ArgoCD, and Kubernetes work.

Final thoughts: was it the right move?

So, was it the right move? Absolutely, yes. I traded the simplicity of a managed service for the total flexibility of my own solution, solving my specific problem and building a platform I can experiment on for a long time. For me, it’s a win on all fronts.

Now let’s compare the pros and cons of this solution.

Pros

Complete control over the workflow
Private source code in my homelab, meaning it won’t be used by Github for Copilot training
No costs (obviously, I’m not counting the biggest cost here: my time; but since the goal was also to practice with new tools, I consider it a training investment in all respects)
Ability to test different types of workflows and practice with the tools

Cons

Uptime not at the same level as Cloudflare (SPOF everywhere—after all, it’s my lab and I have no redundancy)
Speed might be slightly lower (but I still use Cloudflare for caching)
More elements that can break and therefore potentially more time wasted fixing what breaks.

Coming soon: how I automated everything with ArgoCD

In the next article on this blog, I will analyze in detail how I implemented the automatic deployment via ArgoCD.

Attack on LiteLLM: Why pip install betrayed you and requirements.txt saved you

postmaster@mlazzarotto.it (Marco Lazzarotto) — Wed, 25 Mar 2026 00:00:00 +0100

Introduction: The Illusion of Security in an Innocent Command

Who doesn’t know the pip command? It’s one of the most used commands for anyone developing in Python or regularly using open-source software distributed on the PyPi repository. pip is that command that (at least in my experience) never disappoints and is practically essential (though it’s recently been giving way to other tools like Poetry and uv) for anyone needing to install libraries for Python development. But sometimes, this sense of security can lead us into a nasty trap.

But what happens when this trust is betrayed? That’s exactly what happened on March 24, 2026. A carefully laid trap by a hacker group known as TeamPCP turned pip install into a weapon to harvest secrets (like system variables, SSH keys, cloud provider credentials) and attempt lateral movement through Kubernetes clusters.

Anatomy of a Foretold Disaster: What Happened to LiteLLM?

The injected payload was no joke: it was a credential stealer designed to scour the environment for env vars, SSH keys, AWS/GCP/Azure credentials, and Kubernetes tokens, then exfiltrate everything to a malicious domain (models.litellm.cloud).

The team behind LiteLLM has CI/CD workflows to take their software from source code to a package on the PyPi repo. One of these workflows is responsible for scanning their code and dependencies (using Trivy) before distributing the package.

And it was precisely Trivy (apparently) that allowed the TeamPCP group to bypass this security workflow to upload the two vulnerable versions of LiteLLM to PyPi.

The Betrayal of `pip install <package>`

As I wrote above, the pip command is that one command you usually have blind faith in, entrusting it with the task of updating or installing the various necessary libraries. By using it, however, we hand over “control” to it.

Leaving control to pip, at least in this case, led to the entry of vulnerable LiteLLM versions into thousands of systems, which became insecure and potentially compromised. This happened simply because the decision was made to update libraries without caring which version was being installed.

And this isn’t just theory. The LiteLLM team confirmed that those who used their official Docker image were not affected. Why? Simple: that image used a requirements.txt file with pinned versions! It’s concrete proof that this practice, on its own, acted as a shield for who knows how many companies.

Example of an Insecure Dockerfile

# VULNERABLE Dockerfile
FROM python:3.11-slim
WORKDIR /app
RUN pip install litellm fastapi uvicorn
...

A build based on a Dockerfile like this, executed during the attack’s time window, would have installed version 1.82.7 without batting an eye, opening a huge security hole in the infrastructure.

The Unexpected Hero: `requirements.txt` and the Power of Pinning

With pinning, we’re telling pip, “install this version and never, ever update it.” In practice, we’re virtually fixing a specific version with a thumbtack. This is not just a best practice (in Python, as well as in Docker or other package management software) to avoid breaking changes introduced in new packages, but it also prevents the reckless installation of new versions with potential problems.

One of those problems it prevents, in fact, (though in a relative sense) is the installation of new, untested versions that are potentially affected by major bugs or vulnerabilities.

Leveling Up: From a Quick Fix to a Supply-Chain Security Strategy

Supply-chain security is one of the most critical challenges for modern companies that distribute software. Part of the challenge is that there is no single, functional definition of supply-chain security, and it’s a challenge that spans an extremely broad area, including everything from physical threats to cyber threats (as in this case).

If we take, for example, a piece of software like LiteLLM, whose requirements.txt file contains about 80 lines of dependencies, and if we consider that each dependency will likely use other dependencies, it creates a chain of opportunity for an attacker to potentially infiltrate tens or hundreds of thousands of different hosts.

So what actions should be taken to prevent an attack of this type?

Vendor and Library Assessment: it’s necessary to carefully evaluate every library (whether open-source or commercial) before integration, checking the maintainer’s reputation;
Secure Development Practices: adopt the NIST SSDF framework to define security requirements and automatic scans with tools like Dependabot or Snyk, and integrate code signing tools to ensure the distributed software has not been tampered with during the build or distribution;
Immediate Practical Solutions: use Sigstore and Cosign for code signing in CI/CD pipelines to sign containers and binaries.

Conclusions: Trust is Good, Control is Better

Trust in the open-source world is certainly fundamental, but it must be paired with robust security practices, like pinning or tools like Dependabot that verify the dependencies used.

In your opinion, will attacks like this become the new normal in the open-source world?

Protecting the software supply chain isn’t an option, it’s a necessity. If the security of your CI/CD pipelines is a priority and you want to understand how to implement robust strategies like those described in this article, visit my portfolio to discover how I can help you.

Kubernetes, Longhorn, and Non-Root Images: A Permissions Fix Chronicle

postmaster@mlazzarotto.it (Marco Lazzarotto) — Sun, 08 Feb 2026 00:00:00 +0000

Intro

For my new venture as a freelance DevOps Engineer, I decided to build a website using Flask as the backend and a template (named “Simone - Personal Portfolio Template”), purchased from ThemeForest, as the frontend.
Nothing too complicated; HTML, CSS, and Javascript do 90% of the work, and the remaining 10% consists of the Flask backend, which handles internal functionalities like the contact form with Captcha, page routing, the endpoint for Kubernetes livenessProbe, and all the search engine optimization bits (robots.txt and sitemap).

For a couple of months now, I’ve been hosting this website lazzarotto.dev on my homelab using Kubernetes on my 3-node K3s cluster, with two replicas for HA (definitely overkill) and Longhorn for storage (actually only used for Flask’s log files). Until last week, I was using the most common image for a Flask website, which is python:3.14-slim; it’s a Docker image based on the well-known Linux distro Debian Trixie.

Non-Root and Distroless Image

The website was working fine with the previously mentioned Docker image, but for a while now, I had been hearing about these distroless and non-root images on Reddit (and elsewhere), which offered a higher level of security compared to traditional Docker images.
For this reason, and because I wanted to “get my hands dirty” and learn, I decided to convert my Dockerfile to have a root-less and distro-less Docker image for my website.

So, I still used the python:3.14-slim image as the builder stage in my Dockerfile, but I used gcr.io/distroless/python3-debian13:nonroot as the release stage.
So, I built the image, deployed it to Kubernetes with the new image, and the pod started, but it would crash after a few seconds. Looking at the pod’s logs, I discovered that loguru (the logging library) couldn’t write the log file to the folder that was supposed to be mounted by the Longhorn PVC.

Troubleshooting a Distroless Container

If you’ve ever worked with a distroless container, you’ll surely know how complicated it is to troubleshoot an app inside one. For those who don’t know, a distroless image is a Docker image that is missing any basic Linux programs, including: apt/yum, ls, tar, sh, or bash. And so, it’s impossible to use docker exec or kubectl exec to get into the container and check the status of the mountpoint in question.

At this point, my thought was, “I’ve changed two things: the distro and the user running the app.” And I had no idea which of the two changes to the image had introduced the log writing issue.
What I had left to do was to rebuild the Docker image, still without a “root” user, but with a base distro in order to have access to at least ls, touch, etc.

I should point out that all of this was happening while my website was offline because I don’t have a testing environment in my homelab (not yet, at least).

Once I deployed the pod with the new “debug” image, I was able to log into the pod (or rather, into the pod’s container) and realize that the /app/logs folder wasn’t owned by the current user (if I remember correctly, it should be a user with UID 1000), but was instead owned by root.

How to Waste Time Asking Gemini for the Solution

I initially turned to Gemini 2.5 Flash (I know, I should have used the Pro model, but I thought the solution would be simple) to find a solution to the permissions problem with the logs folder.
Its answers seemed really good, and it was always very self-confident, as is always the case with its hallucinations, ça va sans dire. I spent about half an hour on it, but in the end, I gave up and went back to searching on Google, the “old-fashioned” way.

The Solution

The solution came from an issue on the Longhorn project’s GitHub repo that saved me. In short, the problem arises because Longhorn, when it “mounts” the PVC in the container, sets the owner user and group to root, which prevents the non-root user in my image from accessing that PVC.

It still took me some time to put the pieces together, I must admit, but in the end, I chose solution number 7 (Case 7), which was the best for my use case because it didn’t require me to create custom StorageClasses or overhaul my manifests, but to act directly on the securityContext of my Deployment.
Basically, it’s about telling Kubernetes: ‘Hey, when you mount this volume, please make sure it belongs to a group that my application user can write to.’ Simple and effective.

Conclusions and Manifest

So there you have it, an entire afternoon of debugging to add three lines of YAML to my securityContext. But beyond the technical fix, this experience reminded me of two important things.
First: minimal and non-root images are fantastic for security, but they can make debugging a real nightmare if you’re not prepared. Second: never underestimate the power of an “old-fashioned” search on GitHub issues when AI leads you astray.

Now my site is back online, more secure than before, and I’ve learned a valuable lesson about storage permissions in Kubernetes.

I’m adding the relevant part of my manifest that I used for the app’s deployment below.

apiVersion: apps/v1
kind: Deployment
metadata:
 name: lazzarotto-dev
 namespace: dmz
 labels:
 app: lazzarotto-dev
spec:
 replicas: 2
 selector:
 matchLabels:
 app: lazzarotto-dev
 revisionHistoryLimit: 2
 template:
 metadata:
 labels:
 app: lazzarotto-dev
 spec:
 securityContext:
 runAsGroup: 1000
 runAsNonRoot: true
 runAsUser: 1000
 fsGroup: 2000
 containers:
 - name: lazzarotto-dev
 image: git.mlazzarotto.it/marco/lazzarotto_dev:20260205-113032
 imagePullPolicy: Always
 [...]

Boosting Navidrome Security: SSO Auth with Traefik and Authentik

postmaster@mlazzarotto.it (Marco Lazzarotto) — Sun, 11 May 2025 00:00:00 +0000

Introduction

Music streaming services like Navidrome provide a fantastic way to access your personal music collection from anywhere. However, exposing such services to the internet comes with security concerns.

This guide demonstrates how to secure your Navidrome instance using Authentik’s Single Sign-On (SSO) capabilities behind a Traefik reverse proxy.

By implementing this setup, you’ll add an additional security layer to your music server while maintaining convenient access for legitimate users.

Assumptions and DNS Records

This guide assumes you have already installed and configured:

Authentik as your identity provider
Traefik as your reverse proxy
Navidrome as your music streaming server

For the purposes of this tutorial, we’ll use the following domains:

music.example.com: Your public-facing Navidrome instance
example.com: Your external domain
internal.example.com: Your internal subdomain

Understanding The Authentication Flow

The authentication flow works as follows:

A user attempts to access music.example.com
Traefik intercepts the request and forwards it to Authentik via the authentik-forward-auth middleware
If the user isn’t authenticated, they’re redirected to the Authentik login page
After successful authentication, Authentik sends the user back to Navidrome along with authentication headers
Navidrome reads these headers to identify the user and grants access accordingly

Importantly, our configuration deliberately excludes authentication for two specific paths:

/share/: Allows anonymous access to shared music links
/rest/: Permits API access for mobile applications like Symfonium or DSub

This selective authentication provides both security and functionality where needed.

Authentik Configuration

Application and Provider

To set up Navidrome in Authentik:

From the Authentik admin dashboard, select “Applications” and click “Create with Provider”
On the “Application” screen:
- Enter “Navidrome” as the name
- Set an appropriate slug (e.g., “navidrome”)
- Add an optional description and icon
On the “Choose A Provider” screen:
- Select “Proxy Provider”
On the “Configure Provider” screen:
- Enter a name for the provider (e.g., “navidrome-proxy”)
- Select the authentication flow that you typically use
- Choose “Forward auth (single application)”
- Enter https://music.example.com as the external host
Skip the “Configure Bindings” screen and complete the wizard

Outpost

Next, connect your application to the Authentik outpost:

Navigate to “Outposts” in the Authentik admin interface
Edit the “authentik Embedded Outpost”
Under the “Applications” section, add your newly created Navidrome application
Save the changes

Traefik Configuration

The Traefik configuration manages traffic routing and authentication. Here’s the setup:

# Traefik configuration for Navidrome with Authentik SSO
http:
 routers:
 to-authentik-outpost:
 entryPoints: webSecure
 rule: "Host(`music.example.com`) && PathPrefix(`/outpost.goauthentik.io/`)"
 service: authentik
 priority: 200
 middlewares:
 - authentik-forward-auth
 to-protected:
 entryPoints: webSecure
 rule: "Host(`music.example.com`) && !(PathPrefix(`/share/`) || PathPrefix(`/rest/`))"
 service: navidrome
 priority: 100
 middlewares:
 - authentik-forward-auth
 to-subsonic:
 entryPoints: webSecure
 rule: "Host(`music.example.com`) && PathPrefix(`/rest/`)"
 service: navidrome
 priority: 150
 to-navidrome:
 entryPoints: webSecure
 rule: "Host(`music.example.com`) && PathPrefix(`/share/`)"
 service: navidrome
 priority: 100
 services:
 navidrome:
 loadBalancer:
 servers:
 - url: http://navidrome.internal.example.com:4533
 authentik:
 loadBalancer:
 servers:
 - url: https://authentik.internal.example.com:9443

 middlewares:
 authentik-forward-auth:
 forwardAuth:
 address: http://authentik.internal.example.com:9000/outpost.goauthentik.io/auth/traefik
 trustForwardHeader: true
 authResponseHeaders:
 - X-authentik-username
 - X-authentik-groups
 - X-authentik-entitlements
 - X-authentik-email
 - X-authentik-name
 - X-authentik-uid
 - X-authentik-jwt
 - X-authentik-meta-jwks
 - X-authentik-meta-outpost
 - X-authentik-meta-provider
 - X-authentik-meta-app
 - X-authentik-meta-version

Configuration Breakdown

The Traefik configuration consists of several key components:

Routers:

to-authentik-outpost: Handles Authentik-specific paths with highest priority (200)
to-protected: Routes general Navidrome traffic through authentication
to-subsonic: Allows unauthenticated access to the Subsonic API (/rest/)
to-navidrome: Permits direct access to shared links (/share/)

Services:

navidrome: Points to your Navidrome instance
authentik: Points to your Authentik instance

Middleware:

authentik-forward-auth: The critical component that forwards authentication requests to Authentik and passes user information via headers to Navidrome

The configuration uses routing priorities to ensure that authentication exceptions work correctly, with higher numbers taking precedence.

Navidrome Configuration

For Navidrome to properly integrate with this authentication setup, you’ll need to configure two important settings:

ReverseProxyWhitelist: Set this to the IP address of your Traefik server to ensure Navidrome trusts the authentication headers
ReverseProxyUserHeader: Set this to X-authentik-username so Navidrome knows which header contains the username

You can configure these settings in your Navidrome environment variables or configuration file:

ND_REVERSEPROXYWHITELIST=<your_traefik_ip>
ND_REVERSEPROXYUSERHEADER=X-authentik-username

For more configuration options, refer to the Navidrome documentation.

Conclusion

With this setup complete, your Navidrome instance is now secured with Authentik SSO. When users visit music.example.com, they’ll be presented with the Authentik login page. After successful authentication, they’ll gain access to Navidrome.

One of the most convenient aspects of this integration is automatic user provisioning. If a user authenticates through Authentik but doesn’t yet exist in Navidrome, a new account will be created automatically using the username from Authentik (and a random password).

This approach provides robust security while maintaining convenient access for legitimate users, with selective authentication bypassing for specific functionality like shared links and mobile app access.

Resources Used

https://github.com/brokenscripts/authentik_traefik

https://www.navidrome.org/docs/usage/reverse-proxy

https://docs.goauthentik.io/docs/add-secure-apps/providers/proxy/server_traefik

Exposing Seafile 12 Behind Traefik: The Complete Configuration Guide

postmaster@mlazzarotto.it (Marco Lazzarotto) — Thu, 01 May 2025 00:00:00 +0000

Introduction

Seafile is a powerful, open-source file syncing and sharing platform that provides an alternative to commercial cloud storage services. When deploying Seafile in a production environment, you’ll typically want to place it behind a reverse proxy like Traefik to handle SSL termination, routing, and additional security features.

In this guide, I’ll walk you through the exact Traefik configuration needed to properly expose Seafile 12 to the internet. This setup handles all three essential components of Seafile: the web interface, the file transfer service (seafhttp), and WebDAV access (seafdav).

Understanding Seafile’s Architecture

Before diving into the configuration, it’s important to understand that Seafile consists of multiple services that need to be properly routed:

Main Web UI - The primary interface for users to interact with Seafile
Seafhttp - Handles file uploads and downloads
Seafdav - Provides WebDAV access to files

Each of these services needs its own routing rules in Traefik.

Traefik Configuration

Let’s start with the complete Traefik configuration needed for Seafile 12:

http:
 routers:
 routerSeafile:
 entryPoints: websecure
 service: seafile
 rule: "Host(`sf.mydomain.com`)"
 middlewares:
 - "HSTS"
 tls: {}
 routerSeafHttp:
 entryPoints: websecure
 service: seafhttp
 rule: "Host(`sf.mydomain.com`) && PathPrefix(`/seafhttp`)"
 middlewares:
 - "HSTS"
 - "seafhttp-strip-prefix"
 - "removeDuplicateSlashes"
 tls: {}
 routerSeafdav:
 entryPoints: websecure
 service: seafdav
 rule: "Host(`sf.mydomain.com`) && PathPrefix(`/seafdav`)"
 middlewares:
 - "HSTS"
 tls: {}

 services:
 seafile:
 loadBalancer:
 servers:
 - url: http://seafile.local:8000
 serversTransport: insecureTransport
 seafhttp:
 loadBalancer:
 servers:
 - url: http://seafile.local:8082
 serversTransport: insecureTransport
 seafdav:
 loadBalancer:
 servers:
 - url: http://seafile.local:8080
 serversTransport: insecureTransport

Middleware Configuration

In addition to the core routing rules, we need to define some middlewares to handle security and path manipulation:

http:
 middlewares:
 HSTS:
 headers:
 stsSeconds: 15552000
 stsIncludeSubdomains: true
 forceSTSHeader: true
 stsPreload: true
 frameDeny: true
 browserXssFilter: true
 seafhttp-strip-prefix:
 stripPrefix:
 prefixes:
 - "/seafhttp"
 forceSlash: true
 removeDuplicateSlashes:
 replacePathRegex:
 regex: "/{2,}"
 replacement: "/"
 serversTransports:
 insecureTransport:
 insecureSkipVerify: true

Configuration Breakdown

Let’s break down the key parts of this configuration:

1. Router Definitions

We define three separate routers, each handling a different component of Seafile:

routerSeafile: Routes requests to the main Seafile UI
routerSeafHttp: Routes file transfer requests to the seafhttp service
routerSeafdav: Routes WebDAV requests to the seafdav service

2. Routing Rules

Each router uses a combination of hostname and path-based rules:

Main UI: Matches requests to sf.mydomain.com
Seafhttp: Matches requests to sf.mydomain.com/seafhttp
Seafdav: Matches requests to sf.mydomain.com/seafdav

3. Services

Each router is connected to its corresponding service, which defines where Traefik should proxy the requests:

Main UI: Proxied to http://seafile.local:8000
Seafhttp: Proxied to http://seafile.local:8082
Seafdav: Proxied to http://seafile.local:8080

4. Middlewares

We apply several important middlewares:

HSTS: Enforces HTTPS usage by clients
seafhttp-strip-prefix: Removes the /seafhttp prefix before forwarding to the backend
removeDuplicateSlashes: Cleans up URLs with duplicate slashes. This was made necessary for me after the migration from Seafile 11 to 12, but you may not need it.

5. Security Considerations

The insecureTransport setting allows Traefik to communicate with internal services using HTTP
HSTS headers ensure clients always use HTTPS for future connections
Additional security headers protect against common web vulnerabilities

Conclusion

This configuration provides a secure and efficient way to expose Seafile 12 behind Traefik. The setup properly handles all three components of Seafile, ensuring that users can access the web interface, upload/download files, and use WebDAV functionality.

By using Traefik as a reverse proxy, you gain several benefits including automatic SSL certificate management (if configured), powerful routing capabilities, and additional security layers. This particular configuration focuses on the specific routing needs of Seafile while implementing security best practices.

Remember that this configuration assumes you’ve already set up Seafile correctly and that it’s accessible internally at the defined addresses. The configuration also assumes that you have Traefik properly configured with SSL certificates for the specified domain.

Boosting Seafile Security: Hiding Login Fields When Using SSO

postmaster@mlazzarotto.it (Marco Lazzarotto) — Sat, 26 Apr 2025 00:00:00 +0000

When it comes to securing your Seafile instance, the small details make a world of difference. Today, I’m sharing a simple yet powerful security enhancement that takes just minutes to implement but provides significant protection for your data fortress.

If you’ve set up Single Sign-On (SSO) with services like Authentik or Authelia for your Seafile instance, congratulations! You’ve taken a major step toward improving your security posture. However, there’s a sneaky vulnerability that often goes unaddressed.

Even with SSO configured, Seafile continues to display its native username and password login fields by default. This creates an unnecessary attack vector – it’s like installing a state-of-the-art security system for your home but leaving a side door unlocked.

Potential attackers can ignore your shiny SSO implementation and hammer away at the traditional login, attempting to brute force their way into your system. This is particularly concerning because:

It undermines the security benefits of your SSO implementation
The traditional login might have weaker protection against repeated attempts
Users might get confused about which login method to use

The Solution: CSS to the Rescue

The fix is delightfully simple – a few lines of CSS can completely remove those vulnerable login fields from view. The beauty of this approach is that it doesn’t just hide the fields visually; it prevents any interaction with them.

Here’s the magical CSS snippet you need:

.login-panel {
 background: transparent;
 box-shadow: none;
}

#login-form {
 display: none;
}

.login-panel-hd {
 display: none;
}

How to Implement This Fix

Log in to your Seafile administration panel
Navigate to the system settings section
Look for the custom CSS field under Settings
Paste the CSS snippet shown above
Save your changes
Refresh your login page to confirm the traditional login fields have disappeared

Why This Matters for Security

Think of this modification as closing an unnecessary port in your firewall. By removing the traditional login interface, you’re eliminating an entire attack surface. Attackers can no longer attempt to guess username/password combinations because those fields simply don’t exist anymore.

This approach follows the principle of least privilege – if SSO is your chosen authentication method, there’s no reason to expose alternative login paths.

The User Experience Benefit

Beyond security, this change also streamlines the user experience. Your users won’t face the confusion of seeing multiple login options – they’ll be guided directly to your SSO provider, reducing potential confusion and support tickets.

Closing Thoughts

Security isn’t always about complex implementations. Sometimes, the most effective security measures are the simplest ones – like removing unnecessary entry points. This small CSS tweak represents the perfect intersection of improved security and better user experience.

Remember: in the world of security, what can’t be seen often can’t be exploited. Happy securing!

Installation of Zabbix-agent in Home Assistant OS

postmaster@mlazzarotto.it (Marco Lazzarotto) — Fri, 13 Dec 2024 00:00:00 +0000

Introduction

Home Assistant OS is a highly specialized Linux distribution optimized for running the Home Assistant home automation platform.

One of its main features, which can be both an advantage in terms of security and a disadvantage in terms of flexibility, is the inability to access the OS console directly.

This limitation makes the installation of additional software such as the Zabbix agent, an essential tool for system monitoring, particularly complex.

The Solution

Fortunately, the open source community once again comes to our aid.

Thanks to the invaluable contribution of GitHub user pschmitt, an elegant solution has been developed to circumvent this limitation.

The proposed approach is to install the Zabbix agent as a native Home Assistant add-on, integrating seamlessly with the existing ecosystem.

The Repository

User pschmitt maintains a public GitHub repository, accessible at https://github.com/pschmitt/home-assistant-addons/, where he has made available the code needed to install the Zabbix agent.

This repository is specifically designed to be compatible with the Home Assistant add-on system, ensuring a clean and secure installation. your home automation installation.

Installation Procedure

To integrate the repository into your Home Assistant system, you have two methods:

Manual Method: You can follow the standard procedure for adding third-party repositories, detailed in the official Home Assistant documentation at: https://www.home-assistant.io/common-tasks/os#installing-third-party-add-ons
Automatic Method: For a faster and more foolproof procedure, you can use the direct link that automates the entire repository addition process:

Completing the Installation

Upon successful completion of the repository addition, two new add-ons will be available within your Home Assistant: zabbix-agent and zabbix-agent2.

These add-ons represent the classic and newer versions of the Zabbix agent, respectively. After choosing and installing the add-on that best suits your needs and configuring it properly, you will be able to monitor your Home Assistant server through the Zabbix platform.

This integration will allow you to keep all the critical parameters of your Home Assistant system under control, providing professional supervision of your home automation installation.

Hugo - Static Site Generator

postmaster@mlazzarotto.it (Marco Lazzarotto) — Sat, 13 Aug 2022 00:00:00 +0000

What is a static site generator

A static website generator is software that generates a static HTML website using raw data and code as “input” templates.

In essence, a static site generator automates the task of generating individual HTML pages and makes them ready to be served to users in advance.

Dynamic and static web sites

A static website then is a website consisting of one or more HTML web pages that are always loaded in the same way, in a rather basic way in that no Javascript code is used or database operations are performed.

The opposite of a static website, is the dynamic website (or CMS). The latter generates HTML pages to be served to the user dynamically, that is, when the user requests it. It can use variables such as time, date, cookies or geolocation to provide the user with a personalized user experience. All this is supported by Javascript code.

Examples of static website generators:

Hugo
Jekyll
Gatsby
Next.js

Esempi di siti web dinamici:

Wordpress
Joomla
Drupal
Magento

How it works

A static site generator like Hugo, is nothing more than a program whose purpose is to generate web pages from Markdown code and a template of your choice.

Markdown code, used in the form of files, serves the program as the source from which to obtain the text of the various pages of the site. The theme, on the other hand, is code from third-party developers that deals with the formatting of web pages.

Combining the two components results in HTML-formatted pages with text and formatting inside.

All you need to use Hugo is a computer (even offline), Hugo in fact can function as a standalone web server, but only for testing purposes. Upon execution of the hugo publish command, the software will generate all web pages.

Why I chose Hugo

Previously I was using Wordpress, a very powerful CMS suitable for a thousand different uses, but also too much for me. For my typical use it was too powerful, I would even say overkill, with the hundreds of different options sometimes it was hard to find the right page to change this or that setting.

Moreover, I also chose it for a reason of security and especially performance.

Yeah, because in the meantime, static HTML is unassailable from an IT point of view since not relying on Javascript and databases, it’s just not possible to use flaws to gain control of the site (or even worse, the server).

In addition, the inherent operation of static HTML pages allows unparalleled access speed. In fact, on PageSpeed Insights I score above 90 on the home page and above 95 on individual articles (the bottleneck is in the images, I still need to work on that).

Pros and cons

Pros

Speed
Simplicity: once configured it allows you to focus on writing articles
Flexibility, ease of customization with themes
No software to maintain
Security
Ability to write posts anywhere without using the CMS
Free hosting (an article about it coming soon)

Cons

Possibilities for use limited to blog or simple website
No editor with formatting capabilities (not natively)
Limited plugins that cannot be installed with a single click
Initial setup not exactly trivial

Considerations

As you were able to see Hugo, but static site generators in general, are suitable for those who have few demands from the point of view of plugins and adding functionality, but there is also to be said that themes are not limited to the graphical aspect (as is the case on Wordpress), but bring functionality to the site.

An example is the theme I use on this site, which for one supports search and light/dark mode switching.

On the other hand, it is also true that the initial setup is not trivial. The documentation is there, but in English and sometimes it is not exactly straightforward to find.

Credits: Icons created by Freepik - Flaticon

Nextcloud Hub Demo – How to try it

postmaster@mlazzarotto.it (Marco Lazzarotto) — Thu, 28 Jul 2022 00:00:00 +0000

Have you always wanted to test Nextcloud but didn’t feel like installing it because it was too complicated? Or do you just want to take a look to see what’s new in version 24 (Hub II)? Or do you want to show it to a friend?

In this article I will explain how you can get your hands on and test a fully functioning instance of Nextcloud Hub, thus being able to try out all the features offered by this powerful tool.

I wrote a couple of articles on this site in the past about how to try demo versions of Nextcloud without having to install it.

Previous articles, however, referred to the site of a certain Jason Bayton, who unfortunately no longer maintained these demo instances, and they are stopped at version 14.

In any case, there is no need to despair, because the eponymous software house has made a demo version of the latest version of Nextcloud available online.

How

Very simple, go to this link and click on the button Take me there!

Clicking on that button will bring up a page with a registration form, and after completing the fields you will get an email from Nextcloud with a link to start the demo instance.

From now on what you will see on your screen will be a demo version of Nextcloud Hub, fully functional with many apps running, including Collabora Online.

Collabora Online is the open source office suite used by default by Nextcloud.

WARNING: Please be advised that after 60 minutes the trial user will be deleted, so do not upload anything personal because otherwise it will all be deleted to make room for other users.

CentOS 8 - How to bind logstash on port 514

postmaster@mlazzarotto.it (Marco Lazzarotto) — Sun, 28 Nov 2021 00:00:00 +0200

The situation: you need to send logs from an old piece of equipment to logstash running on a CentOS 8, for storing your logs on ElasticSearch.

The problem

The device is old and doesn’t support changing the default syslog port from 514/udp to something different, like port 5140/udp. Unfortunately this can happen, for example on virtual appliances like ZeroShell, where there’s no way to change the syslog port from the default one, but there’s a quick solution to this!

What I’m going to show you is how to bind any process on any privileged port, while running it as unprivileged user

Why

This is a security feature, in that if you connect to a service on one of these ports you can be fairly sure that you have the real thing, and not a fake which some hacker has put up for you. It would be really dangerous to allow system-wide to any service to bind to a non privileged port, because ports from 1 to 1023 are indeed privileged!

BTW, this is not a guide on how to set the listening port of logstash, but rather to allow java to bind to a port < 1024.

How

The procedure is very easy. First of all we need to find the path of the java process bundled with logstash, and the path of the libjli.so library.

The 2 paths should looks like this:

/usr/share/logstash/jdk/bin/java
/usr/share/logstash/jdk/lib/jli

Once you have the path of the 2 files, you can start. Enter the following commands as root.

setcap CAP_NET_BIND_SERVICE=+eip /usr/share/logstash/jdk/bin/java; getcap /usr/share/logstash/jdk/bin/java # this allows java to bind to port > 1024
echo "/usr/share/logstash/jdk/lib/jli" < /etc/ld.so.conf.d/java.conf # this will be used by ldconfig
ldconfig; ldconfig -v -p | grep libjli # checking if the library we need is found in the cache
reboot

When the system is loaded, start the service and check the status and if it bounded to the right port.

systemctl start logstash; journalctl -xef -u logstash # start the service and check the logs
systemctl status logstash # check the status of the service
ss -tlnp | grep 514 # check if logstash successfully bound to 514

At this point you should have your logstash up and running, and most important listening to port 514.

Search

postmaster@mlazzarotto.it (Marco Lazzarotto) — Mon, 01 Jan 0001 00:00:00 +0000

Marco Lazzarotto

Mitigating the 'Copy Fail' Vulnerability (CVE-2026-31431) with a Simple Ansible Playbook

In a nutshell: there’s a new critical Linux bug going around

Understanding the ‘Copy Fail’ vulnerability

The ‘ghost’ aspect

Container escape

The Ansible playbook for immediate mitigation

Breaking down the playbook

How to run it

Verifying that the mitigation works

My take: one more step for containers

Stay vigilant!

Wall Street Relies on AI, Europe Builds Its Digital Fortress: Two Futures Compared

The myth of “job-stealing” AI: the data says otherwise

The real game: US Monopoly vs. European Sovereignty

USA vs. Europe, Monopoly vs. Sovereignty

Act One: The American bet on “everything, now”

Act Two: The European marathon for autonomy

Two philosophies, one choice: what digital future do we want?

Why I moved my blog from Cloudflare Pages to Kubernetes: a story of sub-directories and freedom

The initial idyll: why Cloudflare Pages seemed like the perfect choice

A slight detour: unifying domains to attract more traffic to the portfolio

The unexpected obstacle: the problem of mydomain.dev/blog

The moment of decision: evaluating alternatives

The new architecture: a look at the new setup

Gitea: controlling my code

Kubernetes: the orchestrator of everything

The big picture

Final thoughts: was it the right move?

Pros

Cons

Coming soon: how I automated everything with ArgoCD

Attack on LiteLLM: Why pip install betrayed you and requirements.txt saved you

Introduction: The Illusion of Security in an Innocent Command

Anatomy of a Foretold Disaster: What Happened to LiteLLM?

The Betrayal of pip install <package>

Example of an Insecure Dockerfile

The Unexpected Hero: requirements.txt and the Power of Pinning

Leveling Up: From a Quick Fix to a Supply-Chain Security Strategy

Conclusions: Trust is Good, Control is Better

Kubernetes, Longhorn, and Non-Root Images: A Permissions Fix Chronicle

Intro

Non-Root and Distroless Image

Troubleshooting a Distroless Container

How to Waste Time Asking Gemini for the Solution

The Solution

Conclusions and Manifest

Boosting Navidrome Security: SSO Auth with Traefik and Authentik

Introduction

Assumptions and DNS Records

Understanding The Authentication Flow

Authentik Configuration

Application and Provider

Outpost

Traefik Configuration

Configuration Breakdown

Navidrome Configuration

Conclusion

Resources Used

Exposing Seafile 12 Behind Traefik: The Complete Configuration Guide

Introduction

Understanding Seafile’s Architecture

Traefik Configuration

Middleware Configuration

Configuration Breakdown

1. Router Definitions

2. Routing Rules

3. Services

4. Middlewares

5. Security Considerations

Conclusion

Boosting Seafile Security: Hiding Login Fields When Using SSO

Boosting Seafile Security: Hiding Login Fields When Using SSO

The Problem: Dual Login Methods Create Risk

The Solution: CSS to the Rescue

How to Implement This Fix

Why This Matters for Security

The User Experience Benefit

Closing Thoughts

Installation of Zabbix-agent in Home Assistant OS

The Betrayal of `pip install <package>`

The Unexpected Hero: `requirements.txt` and the Power of Pinning