When you need to share API keys, passwords, etc. within a team/across machines, how do you do that?
Approaches I’ve heard of
-
bitwarden h/t Eric Nantz
I’d be curious to read about any experience (and even to see diagrams 
).
3 Likes
We use LastPass to share/store the “secret” components of our servers (using the “Notes” features). It works fine for things that don’t get updated too often.
3 Likes
We have a smaller team and we share sensitive info with Keybase. We’ve found it seamless so far so I’d say it works. Downsides are that the application is pretty clunky and the company seems to be moving in a cryptocurrency direction which leaves me wondering if they’ll be around in a year.
2 Likes
Also really interested in hearing responses to this question! (or blog post?) I’ve keep telling myself I will ask my group to register for keybase and rely on keybase secure chat to send things like passwords around, but like @brycem share concerns about the longevity & scope drift of the company.
Obviously may be case dependent, In general I have tried to minimize the amount of secure things we have to exchange – for us it’s mostly RStudio Server instance passwords. I’d love to remove that entirely by relying only on systems where I can grant or remove users access ‘directly’ without having to ever send them credentials – i.e. by OAuth where I can grant authentication to via their campus or personal Google or GitHub accounts. I’d love to hear suggestions from others about ways not just to share passwords, but ways to sidestep the need to share passwords, and if there’s greater security concerns on either side?
3 Likes
I need to write a blog post on this, as @maelle has been bothering me about this for some time.
At work we use HashiCorp’s “vault” for all our secrets. It requires a server to run on, but can be configured very flexibly and with relatively little pain, and it’s highly scriptable. With vault we can store secrets in a simple key-value store and retrieve them during deployment of applications or when users need things like database passwords.
A key might be something like /secret/database/science/users/readonly so you can structure secrets in a way that makes sense. We use the vault github auth which means that our team management is enough to then scope secrets by team - our scientists do not have access to the password to write to a database for example, preventing accidental writing to a db.
We store all sorts of things in here, but mostly passwords (database, robot accounts, tokens, server sudo passwords) but also things like certificates and keys for doing https and ssh keys for things like pulling from github.
There is a command line client, as well as one for python (hvac) and for R (vaultr) alongside many other languages.
Not much docs on doing this from R but here is a blog post we wrote on sending vaultr to CRAN and a vignette
Pros: Super flexible, easy to use
Cons: Requires a server, initial setup required
3 Likes
To elaboate on git-crypt, (the link above points to my setup guide), I tried out having people sign up for keybase because its a gentler introduction to setting up GPG keys in general. Even with that GPG key setup is a bit of a pain with various system-specific install snafus. Once people are set up for this, having encrypted keys and passwords in repositories in files like .env or .Renviron is pretty easy and painless.
We also have a few repos using Ansible’s secret sharing, which is basically just a password-encrypted file. I like git-crypt better because it uses public/private keys instead, and is more generic.
4 Likes
not so fancy, but I have 1password with a shared vault
2 Likes