Credential Management

On this page

• Overview
• The Developer Experience and Community Success team vault
• Setting up the vault
  • Team account structure
  • Vaults
• Best practices for management
  • Owners for the Dev Success team, Administrators for others
  • One account per umbrella, one vault per project in an umbrella
  • Users should have View access only.
  • Each vault should have at least one maintainer who can view/change passwords.
  • Use MFA tokens and store them in the vault.

Overview

While most of the services a community uses can be managed via LFX Project Control Center, there are some external services and tools that are currently not able to be managed, such as…

• DockerHub
• Twitter or other social media accounts
• Package management services ( ex. PyPi )

In these situations, creating a secure password vault for the community to use is best. This password vault should, at minimum…

• Be easily accessible and integrate with browsers and workflows
• Securely store credentials, including MFA tokens
• Allow levels of management ( ex., view only, ACLs, etc.)

The best service currently for this is 1Password, which conveniently provides an open-source projects plan our communities can use. More details at https://github.com/1Password/1password-teams-open-source

The Developer Experience and Community Success team vault

While this credential management workflow applies to vaults set up for 1Password instances associated to projects, there is a centralized vault at the LF for the Developer Experience and Community Success team as well.

It is recommended to keep the secrets related to each project in each associated instance, and the main key for each instance in the centralized Developer Experience and Community Success team vault.

The vault is set up to be accessible by a 1Password group also named Developer Experience and Community Success. Anyone in that group can add other LF team members, but only IT Services can modify the vault or the group’s settings.

Setting up the vault

Before anything, follow the instructions for setting up the team account at https://github.com/1Password/1password-teams-open-source#how-to-apply. For step 2 ( Invite at least one other person to your team and add them to the Owners group ), have the created user’s email go to the project’s primary operations email alias. Save the credentials for this account in the Developer and Community Success vault.

Team account structure

There are two main organization structures in 1Password: Groups and Vaults. Groups are designed for user management, though these groups have defaults, and you cannot add custom groups with the version of 1Password provided. You can review details on the default groups for 1Password ( which cannot be changed/removed/added ) at https://support.1password.com/groups/.

Vaults

Vaults are ways to group sets of passwords that certain users would use.

For Vaults Out of the box, there are two vaults available.

• Private ( credentials specific to only you )
• Shared ( credentials shared with everyone in the team account )

Generally, there are few use cases for the Private vault, and it’s not recommended to use it.

The Shared vault is best used for credentials that anyone in the community should use. Examples might include:

• Legacy community shared Zoom account.

The Shared vault should be configured to set the Team Members group to View access, as generally, you do not want to expose credentials but rather have them used.

If you have groups of users that only need access to certain passwords, it’s best to create a vault with just those passwords and add the users needing access specifically to that vault. More details on creating and sharing vaults are at https://support.1password.com/create-share-vaults/.

Best practices for management

While there are a variety of ways to use 1Password for a project community, generally, the below are the best practices everyone should follow.

Owners for the Dev Success team, Administrators for others

Since the Dev Success team does the 1Password billing management, only Dev Success team members should be in the Owner group.

It’s a good practice to have some community administrators for the 1Password account, and the determination of who should be a community administrator should live with the technical leadership team. Community administrators should be put in the Administrators group.

One account per umbrella, one vault per project in an umbrella

The rationale here is that it’s a lot of overhead to manage 1Password accounts, and generally, there will be shared resources across an umbrella, so it makes more sense to have a single vault.

Users should have View access only.

This is to prevent the leaking of credentials to resources in plain text. 1Password has several web browser and CLI integrations that allow access to credentials for authentication in various applications and services without exposing the passwords in plain text.

Each vault should have at least one maintainer who can view/change passwords.

This gives the project flexibility in changing passwords and credentials as needed without the Dev Success team needing to be involved.

Use MFA tokens and store them in the vault.

If a service provides the ability to use MFA tokens, 1Password can manage this natively. More details at https://support.1password.com/one-time-passwords/

---