There we go: I’ve published my first open source project. It’s called Keymaker, it’s a local web interface to manage your OVHcloud API keys (inventory them, audit them, revoke them, create new ones), and I’m going to tell you why I wrote it and how it works.
A quick word of warning up front: this is an unofficial project, with no connection whatsoever to OVHcloud. Just a tool I needed for myself, which I eventually cleaned up and released.
The trigger: API keys everywhere, and no overview left#
If you follow the My homelab from scratch series, you know I use the OVHcloud API in several places: notably for the ACME DNS-01 challenge that generates my Let’s Encrypt certificates via the ktw.ovh zone. Each integration needs a key, with its own permissions.
And that’s where the problem quietly sets in. Over time, between throwaway tests, disposable scripts and integrations that stick around, keys pile up. You end up with a handful of tokens and you’re no longer quite sure:
- what they’re still used for,
- which permissions you granted them (sometimes far too broad),
- whether they ever expire,
- and how long it’s been since they last did anything.
In other words: an attack surface growing behind your back, exactly the kind of thing I like to hunt down. Except that the OVHcloud interface, already not the handiest for creating a key, isn’t great either for tidying up and auditing what exists at a glance. I looked for a tool that did this cleanly, I couldn’t find what I wanted, so I built it.
What Keymaker does#
The idea fits in one sentence: a local console to see and control all your OVHcloud API keys in one place. In practice:
- Inventory: the list of all your keys, with their access rules, their creation date, their expiry and their last use.
- Audit: Keymaker flags risky keys, the ones with access to the whole account, the ones that never expire, the ones that have been dormant for more than six months… in short, the perfect candidates for a cleanout.
- Route explorer: a searchable browser of the OVHcloud API endpoints, so you can build access rules as tightly as possible rather than using wildcards.
- Creation and replacement: create a new key, or rotate an existing key when its permissions need to change.
- Revocation: delete a key cleanly, with confirmation to avoid the unfortunate click.
All of it in a small web interface, light/dark theme, in French as well as English.
The design choices (especially on the security side)#
A tool that handles API keys is, by definition, sensitive. So I made a few deliberate decisions from the start.
Zero persistence. Keymaker has no database, no on-disk cache. It reads your configuration read-only, queries the OVHcloud API on the fly, and writes nothing. When you shut down the container, no trace is left. It’s the same philosophy I like in Bruno for APIs: your data stays with you, and nothing lingers.
Localhost, full stop. By default, the service only listens on 127.0.0.1. It’s not meant to be exposed on the network, let alone on the internet. It’s a workshop tool, running for the length of a session on your machine.
Docker only. No installation based on dependencies that pollute the system: one image, one command, and off you go. Simpler to distribute, simpler to throw away.
Defence in depth. Beyond localhost: a random access token generated for each session, CSRF protection via a second token and no secrets in the logs. And a detail I quite like: if you don’t grant the DELETE permission to the management key, Keymaker automatically switches to read-only. The principle of least privilege applies to the tool itself.
The management key, a deliberate paradox. To manage your keys, Keymaker itself needs an API key (with the appropriate permissions). It’s the same kind of bootstrap as the age key or the GitLab token I talked about in the homelab: there’s always a first secret you lay down by hand. The good practice is to give it only what’s strictly necessary (and to revoke it with Keymaker when the day comes, naturally).
Trying it in one command#
The principle: you create a management key with the right permissions, you store it in an ovh.conf file (the standard OVHcloud SDK format), and you launch the container.
docker run --rm -p 127.0.0.1:8080:8080 \
-v ./ovh.conf:/config/ovh.conf:ro \
ghcr.io/kentrow/keymaker:0.1.0The :ro on the volume says exactly what it means: Keymaker reads the config, it doesn’t touch it. Then head to http://127.0.0.1:8080 with the token shown at startup. The details (exact permissions for the management key, file format) are in the repository README.
What it taught me#
Releasing a project isn’t just about pushing code to GitHub. It’s also writing readable docs, choosing a licence (Apache 2.0 here), polishing error messages, thinking about the person who’ll clone it knowing nothing of the context… exactly the same reproducibility reflex as in the homelab, but turned towards others this time.
It’s a first pass (version 0.1.0), written in Go, with plenty of rough edges to smooth out for sure. But it already does what I created it for: giving me, in thirty seconds, a clear view of what my OVHcloud keys can do, and which ones need deleting.
Useful links#
- The Keymaker repository on GitHub
- The issues: feedback, ideas and bugs are all welcome
My final word#
If you have an OVHcloud account and you’ve never really sorted through your API keys, run Keymaker once. You’ll probably stumble, like me, on two or three forgotten tokens with far too many permissions. And if you like the project, a star on the repo is always appreciated.
See you soon!
