Selfhosted
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
-
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
-
No spam posting.
-
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.
-
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
-
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
-
No trolling.
Resources:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
view the rest of the comments
Normally you wouldn't need a secrets store on the same server as you need the secrets, as they are often stored unencrypted by the service/app that needs it. An encrypted disk might be better in that case.
That said, Vault has some useful features like issuing temporary credentials (eg. for access to AWS, DBs, servers) or certificate management. If you have these use-cases, it could be useful, even on the same server.
At my work, we tend to store deployment-time secrets either in protected Gitlab variables or in Vault. Sometimes we use AWS KMS to encrypt values in config files, which we checkin to git repositories.
That's what I'm worried about
See, that is one of the ideas I've been toying with. I've never encrypted a remote VPS. I have encrypted all my local drives. There is some response loss on local drives it seems to me. Negligible, but still. I'm just wondering if there would be a performance hit.
Encryption will typically be CPU bound, while many servers will be I/O bound (eg. File hosting, rather than computing stuff). So it will probably be fine.
Encryption can help with the case that someone gets physical access to the machine or hard disk. If they can login to the running system (or dump RAM, which is possible with VMs & containers), it won't bring much value.
You will of course need to login and mount the encrypted volume after a restart.
At my work, we want to make sure that secrets are adequately protected at rest, and we follow good hygiene practices like regularly rotating credentials, time limited certificates, etc. We tend to trust AWS KMS to encrypt our data, except for a few special use cases.
Do you have a particular risk that you are worried about?
A couple of the Docker compose files I've used have non-hashed secrets in the compose itself. I am assuming, should someone penetrate the firewall, and gain access to Portainer somehow, they could see these compose entries just like I can. While I feel like I have adequately hardened the server (Lynis reports a score of 87) and I have rather robust ids/ips, firewall, and assorted accoutrements to support a secure server, there's always that 'what if' scenario running in my brain and it causes doubt. Perhaps a secrets manager is over kill for a single user, docker container server.
Yeah, at that point I wouldn't worry. If someone has docker access on the server, it's pretty much game over.