Need a tool for project credential sharing

Tools
#1

Does anyone use a tool for sharing credentials and env files with your development team? Or better yet, any suggestions or best practices to working around this?

We have an app that uses firebase, as one example, but we don’t want to raise the barrier to entry by having everyone have to go through setting up their own firebase account, etc.

Passbolt looks like a solid self-hosted option that gives you group and user-level permissions:

Keybase is also an option though I’m not entirely wooed by the file sharing + teams model.

#2

At the brigade level, for Code for SF, we used to just use a Google Sheet which, while isn’t great from a governance standpoint, does get the job done. We then switched to LastPass which is paid, but reasonably cheap.

Passbolt seems promising!

Curious to hear what others are using.

1 Like
#3

OpenOakland uses 1password. We reached out to them and were able to get them to donate it for us. It’s great to have all our usernames and passwords in one secure place such that whenever anyone changes a password it is immediately propagated in everyone’s workflow. But this is mostly good for username/password logins like Mailchimp, etc.

As for managing environment files, this is an age old problem. Internally at CfA, I have seen us use “shared notes” in LastPass to store .env files. It just becomes part of your workflow to do something like this pseudocode:

lastpass show [note id] > .env.development

(I don’t actually know the command)

whenever pulling new code.

1 Like
#4

Why not creating credentials for each of the dev separately? Another option would be a VPN + IP rules on the firewall.

#5

That’s an ideal solution, but projects often end up with at least some services that don’t support this. Also, even where multi-account access is supported, when it comes to the organization as a whole maintaining access to key services for all projects, it is unfortunately far more practical to have an org-level services email account that every project just knows to invite to everything and submits a randomized password to the org-level password store

We’ve been using bitwarden_rs at Code for Philly for a couple months now and I’m happy with it, I had a draft topic about it I forgot to post:

#6

To be clear, the credentials I was referring to (that we use the command-line tool to put in project-level config files) are passwords for project-level things like:

  • API keys for infrastructure providers (e.g. AWS)
  • API keys for third-party services (e.g. Mixpanel, Email sending services, etc.)
  • Semi-private configuration values like Webhook URLs
  • Shared configuration values (e.g. feature flags stored as environment variables)

There are also many credentials we store that are not project-level, that we also use LastPass / 1password to share amongst the leadership of the organization. These are things like:

  • Twitter login
  • Root login for things with individualized access (e.g. Mailchimp, our Brigade’s Wordpress)

Ideally, a password storage solution can support both workflows. Even though they are different workflows, standardizing on a single password storage method within a Brigade keeps things simpler.

Finally, on the topic of 1password. They gave us (OpenOakland leadership) the impression they would renew our 100% nonprofit discount indefinitely, but it turns out that there was a misunderstanding there. When it came time to renew, they offered us only a 50% discount. It’s still a tool we’ll use, but we’re somewhat limited now that we’re paying $2/user/month for it.

#7

bitwarden_rs does this well, you can create any number “organizations” within your server which are the root of all sharing. Within an organization you can invite members and create “collections” (folders). Each member in an organization can either have access to all collections or select collections. Everything you add to bitwarden is private only under your account, until you opt to share it into one of the organizations you’re a member of and select which collection(s) it should be part of. So we have a main CfP organization and have collections for social media, infra, minor projects, etc. Major projects get their own org

Finally, on the topic of 1password. They gave us (OpenOakland leadership) the impression they would renew our 100% nonprofit discount indefinitely, but it turns out that there was a misunderstanding there. When it came time to renew, they offered us only a 50% discount. It’s still a tool we’ll use, but we’re somewhat limited now that we’re paying $2/user/month for it.

This is why i’m kind of militantly anti-SaaS for things we’re going to be operationally dependent on. This is ALWAYS the endgame, if the product doesn’t get shuttered first. Freebies are attractive but often you’re setting intractable timebombs for future leaders and handicapping the organization with usage constraints all along the way :-/

1 Like
#8

KeePassXC has recently implemented sharing credentials of grouped entries and synchronization with networked databases, so I think it now covers the need mentioned in this group

It was pulled in develop branch, is planned to be shared in 2.4.0 release.

1 Like
#9

In Toronto, we’ve been pretty low-tech. For organizing, we just use two collaborative document tools: HackMD and Google Docs.

We’ve used a simple hackmd pad to share information about what services we use (or have used) and who has access: http://link.civictech.ca/inventory

And then we use a locked-down GDoc file to store shared passwords. (linked in the hackmd)

The one risk vector (that’s a real, on-the-ground caveat), is that we link the gdoc from publicly readable places (like right now!) and someone can theoretically create a “familiar-looking” gmail account and request access. Since many past organizers (~30) have view/edit access to the gdoc, one of them might grant access without checking with others.

We’ve never had any issue with this approach fwiw. It’s served us very well, and I usually advocate for something this simple and accessible for other projects.

Projects handle their own passwords, and we don’t offer anything for that. I suspect many use simple docs like the organizers do.