Feature #2099
sharing accounts/credentials
Description
__We should come up with a robust and secure way to share accounts/credentials related to the GROMACS infrastructure. If only X knows the password because he/she set up the machine/service is bad. Not having access to a compiler because only Y knows the Intel account's credentials is silly. Using crappy passwords just because they're easy to remember is a bad excuse.
I'd think a password database with strong encryption and strong master pass (+ key?) would be best. I'd recommend keepass, it has clients for everything, so it mostly just works, but there could be even simpler/better alternatives.
I know a single point of failure is not ideal, but some of the current practices are just poor, don't scale, and don't allow sharing responsibilities.
History
#1 Updated by Alexey Shvetsov about 3 years ago
Well, there is some simple way (at least how its done in gentoo linux):
Account info storred in file encrypted with GPG (so anyone who has right key [there can be many keys to decrypt] can read contents of this file). So in this case file can even be stored in some public place =)
#2 Updated by Roland Schulz about 3 years ago
Do we want those with access to some of the logins to have access to all? Or do we need a solution where we can give people access to only some?
I also think we should use gpg. Something like https://github.com/StackExchange/blackbox seems like a good solution.
#3 Updated by Szilárd Páll about 3 years ago
- Description updated (diff)
#4 Updated by Szilárd Páll about 3 years ago
- Description updated (diff)
#5 Updated by Szilárd Páll about 3 years ago
Good point, GPG should be enough, but if we have a number of accounts, not having to maintain our own tabulated, sane formatted text file would already be a benefit.
Roland's point is good, we might want to be able to share only some of the data, not all, but I'm not sure if this is a must.
#6 Updated by Roland Schulz about 3 years ago
The nice thing about something like blackbox is that you can add users and remove users in a safe way. Given that there is no common master password you can remove users without having to create a new master password and reshare that new master password with all users. Resharing the master password in a safe way is hard, because you need a secure channel. And it integrates nicely into git and thus works nicely with our other infrastructure.
#7 Updated by Stefan Fleischmann over 2 years ago
- Project changed from Sysadmin to Support Platforms
#8 Updated by Roland Schulz about 2 years ago
keybase encrypted git (https://keybase.io/blog/encrypted-git-for-everyone) might be great for this