now secrets are stored on the FS, it might make it much easier to support multi-portal systems if those are stored in the DB. Also easier for backups.
They probably need to be encrypted if (remote) database is used...
We are talking about:
In order for the CA key to be used in vpn-ca it needs to be either first written to a file, or e.g. passed as through environment variable... We need to modify vpn-ca for this as well to support that.
not only does vpn-ca need to support reading CA from env, it should probably also work without writing / reading anything from disk. This is a bit more tricky, especially when you want to have cert and key separately. You'd need to pipe stuff, e.g.
$ vpn-ca -gen-key > ca.pem $ CA_KEY=$(cat ca.pem) | vpn-ca -ca -name "VPN CA" >>ca.pem $ vpn-ca -gen-key > server.pem $ CA=$(cat ca.pem) | vpn-ca -server -name foo.example.org >>server.pemThat's quite cumbersome! Especially the self signed case which is weird using this pattern.
We may simply get rid of the distinction between key/crt file and store everything in 1 file, i.e. both the cert and private key concatenated. Then it is up to the 'consumer' of vpn-ca output to deal with that.
Perhaps we make this WAY too complicated and we should only store the "dynamic" keys in the database, i.e. the files in
/var/lib/vpn-user-portal. The rest will never change, or only change if there is a serious problem.
The rest will never change, or only change if there is a serious problem.
The main thing is that these keys are generated on the node(s). So if a profile is added in the config with OpenVPN support, a new tls-crypt key will be generated and registered at the portal(s) and thus needs to be synced as well. It would be neat to only have the need to sync
/etc/vpn-user-portalbetween portals and not/var/lib/vpn-user-portal.
This feature by itself is maybe not enough to modify the database. If we could also make other stuff part of the DB it might start to make sense, for example configure profiles as well though the DB. Then we can easily modify config through the web for example, or write a script to dynamically create a profile, etc...
tls-crypt-default.key|# ... ... wireguard.0.public.key|++h9x4ws2mGS3+dza3CPPlB9cSGF2Q7SHGp8v8neGz4=
one way to handle vpn-ca, is to generate passphrase in environment variable to encrypt the files being generated . once the generation process is completed, the pass phrase can be used to decrypt the files during the db insert.
one way to handle vpn-ca, is to generate passphrase in environment variable to encrypt the files being generated . once the generation process is completed, the pass phrase can be used to decrypt the files during the db insert.
The encryption is actually the easy part...
The hard part is deciding whether we want this at all, whether we want to have more configuration stuff stored in the database, whether we even want the CA in the database for which I'm currently leaning towards "no", because it never every changes during the lifetime of the server, i.e. it is "static". But if we'd go "database all the way for everything", then it may make sense again.
moving config to the database will make it robust. as start to be able to view all configs (specially with multi-portal in mind). having portal, profile, nodes config in database, implies having their respective keys along. CA as master key, if stored in database, it think it would require level of security, in-terms of storage-API between all portals and DB instead of direct DB access. portal will have to use portal{x}.key.