Installing Step CA in My Homelab

Step CA is an open-source private CA made by Smallstep. I will use it to generate certificates for some componenents in my lab.

First we install the dependencies:

sudo apt-get update && sudo apt-get install -y --no-install-recommends curl gpg ca-certificates

Then we get the Smallstep repository signing key:

sudo curl -fsSL https://packages.smallstep.com/keys/apt/repo-signing-key.gpg   -o /etc/apt/keyrings/smallstep.asc

Then we add the Smallstep repository:

cat << 'EOF' | sudo tee /etc/apt/sources.list.d/smallstep.sources > /dev/null
Types: deb
URIs: https://packages.smallstep.com/stable/debian
Suites: debs
Components: main
Signed-By: /etc/apt/keyrings/smallstep.asc
EOF

Then we install step-cli and step-ca:

sudo apt-get update && sudo apt-get -y install step-cli step-ca

Then we check the install:

step-ca version
step version
Smallstep CA/0.30.2 (linux/amd64)
Release Date: 2026-03-23T00:18:00Z
Smallstep CLI/0.30.4 (linux/amd64)
Release Date: 2026-06-10T06:10:28Z

Next, we’ll run the initializer:

step ca init \
  --name "lostintransit.se" \
  --dns "stepca.lostintransit.se" \
  --address ":443" \
  --provisioner "[email protected]"
✔ Deployment Type: Standalone
Choose a password for your CA keys and first provisioner.
✔ [leave empty and we'll generate one]: 

Generating root certificate... done!
Generating intermediate certificate... done!

✔ Root certificate: /home/ddib/.step/certs/root_ca.crt
✔ Root private key: /home/ddib/.step/secrets/root_ca_key
✔ Root fingerprint: 8f08102ae41eb7fc6a57f62fbaccaf82cb7a67dbedca858a0352a75b4fa763cd
✔ Intermediate certificate: /home/ddib/.step/certs/intermediate_ca. Continue reading

AI solving problems

I’ve been able to find some time, lately, to work on my project backlog. And because it’s 2026, I’ve been using AI as a diligent intern.

I’ve ranted before about seccomp, but still used it for a project or two. But then, rarely, it triggered an unexpected openat. That’s exactly the kind of I do want to detect and kill the binary for, so I don’t just want to allow it. I want to know where it’s coming from.

strace showed it’s trying to read /proc/sys/vm/overcommit_memory.

It’s certainly not my code. But just the Rust transitive dependency tree is quite a few crates:

$ cargo tree | sed -r 's/^[^a-z]+//;s/ .*//' | sort -u | wc -l
236

Step 1 was to run it in gdb, and reproduce the problem. But it’s a bit trickier than that, because seccomp fully kills the process, so no backtrace. And setting breakpoints requires a few more syscalls to work, just for the process to work under gdb (e.g. sigaltstack).

And turns out some calls fail with EINTR if running under a debugger.

Yes, I can fix all these things. But why not put the AI intern on it?

AI Continue reading

Scaling Security Insights: how we achieved a 10x increase in global scanning capacity

Security Insights provides actionable security recommendations for every Cloudflare account. To find these insights, we perform regular scans for all accounts, zones, and DNS records, looking for potential security risks and misconfigurations.

However, two key issues emerged. First, our scans were too infrequent. Scans were only being performed every week or two, and therefore newly introduced security risks could remain undetected for up to two weeks. Second, automatic scanning was opt-in for many free plan accounts – meaning lots of accounts weren’t being scanned at all.

The risks of infrequent or nonexistent scans are rising: as automated attacks accelerate, the window for detecting security misconfigurations is shrinking. Making sure that we’re finding these issues for all of our customers is crucial to our aim of building a better Internet for everyone.

We calculated that to increase our scanning frequencies and enable automatic scanning for all accounts, we would need to increase our scanning throughput by around 10x on average – from 10 scans per second to 100 per second. But our system was already struggling with its load: millions of events were filling up our backlog waiting to be processed; our API was frequently timing out; our processes were crashing. Continue reading

AI in Networking with Andrew Yourtchenko

I always wanted to find someone who is more positive about AI than I am, while having solid “can deliver working stuff at scale” credentials. Andrew Yourtchenko definitely fits the bill. I first met him (online) when he was still an engineer in Cisco TAC, and when we finally met in person, he was busy automating the deployment of Cisco Live networking infrastructure. He was also instrumental in bringing us closer to ubiquitous IPv6 deployment with Happy Eyeballs.

Cisco Live 2026 – Requiem For A Corner

Cisco Live US 2026 was an interesting ride this year. There was a lot of talk about AI. There was a big discussion about security and how we are protecting our software from the AI models on the horizon that are ready to uncover every bug ever conceived. And there was even more discussion about whether Cisco was ahead of the game or behind the curve on their support for everything from eBPF to the latest Mythos reports. I say there was a lot of discussion, but I’m not sure where exactly it was happening.

Social Desert

One of the biggest things I heard from my friends at the event was how light everything felt. Fewer people was a common theme. The reported number was around 22,000 but it felt closer to 20,000 to me. The World of Solutions felt very spread out this year, with most of the back side being Cisco booth space.

The other thing was the Social Hub. It had shrunk from last year. At least the couches were facing each other this year. And there were some cool stickers and some interesting puzzles to work on. But there were far too few tables for people Continue reading

Installing Dnsmasq in My Homelab

Dnsmasq is an application which has features like DNS caching, DHCP server, and so on. It’s useful as a DNS server in a homelab as it can reply to DNS queries for what’s in its database, and forward everything else to an authoritative server or recursive resolver. This is useful in my lab as I want to resolve for example gitlab.lostintransit.se locally, but lostintransit.se (my web server) or any other domains via recursive resolvers. Most DNS servers are authoritative for a zone or parts of a zone, but dnsmasq responds only to what it knows and forwards everything else, which is perfect for my needs.

First I’ll configure a static IP on the host by modifying the file in /etc/netplan:

sudo vi 50-cloud-init.yaml

The contents are now:

sudo cat 50-cloud-init.yaml 
network:
  version: 2
  ethernets:
    ens160:
      dhcp4: no
      addresses:
        - 192.168.128.53/24
      routes:
        - to: default
          via: 192.168.128.1
      nameservers:
        addresses:
          - 8.8.8.8
          - 8.8.4.4

I’m using recursive resolvers for now but will update it later.

Then apply the configuration:

sudo netplan apply

The IP has been updated:

ip addr show ens160
2: ens160: <BROADCAST,MULTICAST,UP,LOWER_UP>  Continue reading

Five Principles of an Accountable AI Agent Network: How to Evaluate Any Governance Platform

The first post in this series argued that AI agent governance hasn’t kept pace with deployment. The second laid out the five pillars of accountability, and what is required. The third walked through why network policies, API gateways, MCP/A2A protocols, DIY security patterns, and Role-based Access Control (RBAC) each leave critical accountability gaps.

So what does good look like?

The five pillars define what AI agent accountability requires. The principles below define how a governance platform should deliver it. These are the architectural principles your team should evaluate any AI agent governance solution against, whether you build it, buy it, or assemble it from open-source components.

If a vendor pitches you a governance platform that fails any of these five, walk away.

What are the five principles of an accountable AI agent network?

Kubernetes Network Policies are essential for securing any cluster. They restrict which pods can communicate with which other pods at the network level, and they should absolutely be part of your security posture.

  1. Default-deny: No agent communicates unless a policy explicitly permits it.
  2. Attribute-based policy: Policies reference agent attributes, not agent names.
  3. Zero-trust identity: Every request authenticated, every identity verified.
  4. Audit by design: Every interaction produces a Continue reading

A field guide to the agents in your cluster

You know every service in your cluster by name. You know which team owns each one, what it talks to, how it scales, where its logs go. The agents are a different story.

That’s not a criticism, it’s an observation, and it’s one we keep running into. Every company we talk to is shipping agents of some kind, from scales of 10s to 1000s. Customer service bots that field tier-one tickets. Internal copilots that draft emails and summarise meetings and write the boring half of every PR. SREs that handle their own incidents at 2am while the team sleeps. What used to be a few experimental builds in a dev cluster is now dozens in some shops and hundreds in the biggest, growing faster than most teams are tracking.

That growth curve is the interesting part. Services tend to come into existence through a fairly heavyweight process. There’s a ticket, a design review, an owner, a runbook. Agents tend to arrive the way side projects do:

  • Somebody had an idea on a Tuesday.
  • By Friday it was in staging.
  • At some point nobody can quite remember when it became part of the actual business.

Who said it could do that?

Continue reading

Route public traffic to private applications with Cloudflare

For most of the Internet’s history, public and private infrastructure operated as separate worlds. Public applications lived behind content delivery networks (CDNs) and web application firewalls (WAFs). Private applications lived behind virtual private networks (VPNs), firewalls, and separate operational stacks. We think that distinction is becoming obsolete.

Many of the applications organizations care about are not public websites. They are internal APIs, AI agent backends, MCP servers, operational tools, and services that were never designed to be exposed to the public Internet. Yet these applications still need modern security, performance, and programmability services. Security should be a property of the traffic reaching an application, not an accident of where the application happens to sit.

Until now, applying those services to private applications often required public IPs, firewall exceptions, connector software, or complex networking. As a result, many private applications missed out on capabilities such as WAF, bot management, rate limiting, caching, traffic acceleration, rewrites, and Workers, despite needing the same protections and controls as public-facing applications.

Today, we're launching Application Services for Private Origins in closed beta for eligible Enterprise customers. Customers can now securely route traffic to private origins without exposing those origins to the public Internet. This allows Continue reading

1 4 5 6 7 8 3,884