cmars
Rotate Client Authorization Key w/out restarting docker container
Hey there!
I was wondering if there is a way to rotate client authorization keys without needing to restart the docker container.
I am working on slightly unconventional project where I want to be able to essentially add MFA to my onion sites without setting up a reverse proxy / auth solution like Authelia, Zitadel, Authentik, etc... I would like for this to happen at the client authorization level such that, even if one were to happen upon my onion sites somehow, they would not be able to access any data from them without the key.
I would like to rotate this every 30-60 seconds, similar to your traditional MFA, however I am not certain if I can without restarting the docker container. If I need to restart the docker container, I will need to rotate them at a slower interval.
Thanks!
Some additional context: I am starting the container by doing
docker run --name -d onionpipe ghcr.io/cmars/onionpipe:main --require-auth PUBKEY IP:Port~Port
When i attempt to pass it through as an environment variable so I can update it using docker exec:
docker run -e AUTHKEY='PUBKEY' -d --name onionpipe6 ghcr.io/cmars/onionpipe:main --require-auth "$AUTHKEY" IP:PORT~Port
it hangs on starting tor. I suspect there is some issue with passing the authkey from the environment variable.
Interesting use case... I'm curious how you'd coordinate key distribution at such a high rate of rotation.
From the onionpipe / Tor control socket side, I think we'll have to answer a series of questions:
Is it possible to rotate the client key over the control port protocol?
Looks like it! ONION_CLIENT_AUTH_ADD and ONION_CLIENT_AUTH_REMOVE would allow runtime rotation of the client secrets. You could even keep N client keys in rotation for better resilience against lag (thinking about the fernet token scheme in OpenStack Keystone here).
What would it take to use that capability through onionpipe?
- Support for these commands in https://github.com/cretz/bine.
- Support for some kind of higher-level control API over onionpipe, which currently doesn't exist.
That would take some doing. It sounds kind of fun, but I'm currently focused side-project-wise elsewhere (something with Veilid).
What else could I do?
You could connect to the Tor control port directly in a "sidecar" and coordinate client key rotation, completely independently of Onionpipe. So you'd let onionpipe launch Tor and manage the process like an Operator, but connect directly to its control port.
If you go this route, you might want to still use static client auth keys with Onionpipe as a longer-lived secret which is not distributed, so that you "fail closed" if your dynamic client sidecar fails to connect. It'd be a local "admin secret".
Perhaps not ideal, but this might meet your needs?
If you hit on a pattern where changes in Onionpipe would better facilitate the "sidecar pattern", that might be a more manageable piece of work I'd consider. Seems like there could be some nice overlap there with a Vanguard integration?
Hey there - I appreciate the response!
I'm curious how you'd coordinate key distribution at such a high rate of rotation.
Fortunately, the total number of people connecting to my sites are <5 - What I intend to do is generate a OpenSSL key, and push it to each person's selfhosted password manager. Each Pswd manager is locked behind webauthn and only exposed via an onionsite, and so it allows us to proxy webauthn requirements to each onionsite without needing to use a reverse proxy of any kind.
That would take some doing. It sounds kind of fun, but I'm currently focused side-project-wise elsewhere (something with Veilid).
No worries! I hope the Veilid project goes well ^-^
Perhaps not ideal, but this might meet your needs?
This may do it! I will try and it ^-^ - Thank you so much for all the information and the help :D