Cheap man's secret handling
I run a very cheap home server. How cheap? Very, very cheap. Sub Raspberry Pi 4 cheap.
It runs a ton of services, and it also works as my "Functions" server.
What is a functions server?
It's a cheap man's AWS Lambda which allows me to create small "services" like this, and deploy them automatically. It's really a game changer for simple code availability, and it's my favourite way to share functionality with others.
But sometimes a service relies on a 3rd party API, and it needs things like a token to be available. Faasd supports this using their secret API. You create a secret like this:
faas-cli secret create whatever
And when you declare in your functions.yml
that your function needs a secret:
myfunc:
lang: python3-fastapi
handler: ./myfunc
secrets:
- whatever
Your code reads a file in /var/openfaas/secrets/whatever
and that's all, there is a
secret on the server, your app can see it, it's not in the app's code, all good.
Except ... what happens if you need to redeploy faasd? You will need to create the secret again! So you need to keep the secret somewhere.
Solution: pass
I already use pass to keep many passwords, it's easy to also put secrets there.
It manages everything using a git repo, so it's a known factor. You can even do
things like add them all inside a faasd/
folder and then recreate them using
scripts, like this:
pass faasd/whatever | faas-cli secret create whatever
pass will ask for your master passphrase, secret created. You can even publish your pass repo since everything in it is encrypted with gpg, so nobody can really read it (don't do that).
So, this solution uses:
- pass
- gpg
- git
- faasd
- shell
- whatever language and framework you use in your code
And everything is seamless!
I think this is a nice example of how random tools can connect with each other because they all follow the unix convention about moving things around as text.