Managing Shared Credentials Without Losing Control
Shared credentials are a security liability hiding in plain sight. When a team stores API keys, database passwords, or service tokens in Slack messages, shared spreadsheets, or a single engineer’s notes app, the risk compounds every time someone new joins or leaves. Bitwarden Secrets Manager is Bitwarden’s dedicated solution for this exact problem – an open-source-backed tool built specifically for storing, organizing, and distributing machine and service secrets across teams with proper access controls.
Unlike Bitwarden’s standard password manager, Secrets Manager is engineered for developer workflows. It centers around projects, service accounts, and machine-readable access tokens rather than browser autofill and personal vaults. Secrets can be pulled directly into CI/CD pipelines, Docker environments, or application configs without anyone manually copying values out of a browser extension.
This guide walks through everything from initial organization setup to creating your first secret and distributing access to teammates.
Setting Up Your Organization and Enabling Secrets Manager
Secrets Manager is tied to a Bitwarden organization, not an individual account. If you already use Bitwarden Teams or Enterprise for password management, you may have the option to add Secrets Manager under the same organization. Start by logging into the Bitwarden web vault at vault.bitwarden.com, then navigate to your organization settings. Under the “Subscription” tab, you should see an option to activate Secrets Manager if your plan supports it. Bitwarden offers a free tier for Secrets Manager with limited seats, which is enough to test the workflow before committing.
Once enabled, a “Secrets Manager” entry appears in your organization’s left-hand navigation. Clicking into it opens a separate dashboard from the standard vault – this is intentional. The Secrets Manager interface is minimal by design: you see Projects, Secrets, Service Accounts, and People. That structure is the entire mental model you need to operate the tool effectively. Projects act as logical containers – group related secrets by environment, service, or team. A backend API service, for example, might get its own project containing all its credentials.
Invite team members to your organization first through the standard Bitwarden flow, then assign them access specifically within Secrets Manager. Go to “People” inside Secrets Manager and toggle on access for the members who need it. Bitwarden keeps Secrets Manager access separate from password vault access intentionally – not everyone in an organization needs to see infrastructure credentials, even if they share a password vault for other things.
Creating Projects, Adding Secrets, and Structuring Access
With the organization ready, create your first project. Inside the Secrets Manager dashboard, hit “New Project” and name it something descriptive – “production-api”, “staging-database”, or “github-actions” all work well. The naming convention matters more than it seems: service accounts and teammates both reference project names when you’re configuring access, so ambiguous names create confusion at scale. Once the project exists, you can start adding secrets directly to it.
Adding a secret is straightforward. Click “New Secret,” give it a key name (this is what you’ll reference in code, like DATABASE_PASSWORD or STRIPE_API_KEY), enter the value, and add an optional note for context. Assign it to one or more projects before saving. Secrets can belong to multiple projects, which is useful when a shared service account token needs to be accessible across two different application environments. Keep key names consistent – uppercase with underscores is the convention most development teams already follow from working with environment variables, and sticking to it reduces friction when engineers are wiring secrets into configs.
Access control works at the project level. You can grant a team member read or read-write access to a specific project without exposing any other secrets in the organization. This is where Secrets Manager earns its place in a real security workflow. When a contractor joins to work on one service, you give them access to exactly that project’s secrets – nothing else changes. When they leave, you revoke that project access. No need to rotate every credential in the organization just because one person’s scope changed.
Service Accounts and Machine Access
Human access handles the interactive side, but most secrets consumption happens in automated systems – CI pipelines, containerized apps, server scripts. That’s where service accounts come in. Inside Secrets Manager, navigate to “Service Accounts” and create one named after the system that will consume it: “github-actions-runner” or “docker-compose-prod” are sensible choices.
After creating the service account, assign it read access to the relevant projects. Then generate an access token from the service account’s detail page. This token is a machine credential – it authenticates non-human processes to retrieve secrets programmatically. Copy it immediately and store it somewhere safe (ideally in your CI platform’s own secret storage, like GitHub Actions secrets or GitLab CI variables), because Bitwarden will not show the full token again after you leave that screen. The Bitwarden CLI and the official SDKs for Python, Node.js, and Go all use this token to authenticate against the Secrets Manager API at runtime, pulling secret values directly rather than baking them into code or config files.
The practical CLI workflow looks like this: install the Bitwarden Secrets Manager CLI (bws), set the BWS_ACCESS_TOKEN environment variable to your service account token, then run bws secret get <secret-id> or use bws run to inject secrets as environment variables into a process automatically. The bws run command is particularly clean – it wraps your application startup command and injects all project secrets as environment variables without writing them to disk. Combined with a properly scoped service account, this eliminates the entire category of credential exposure that comes from .env files committed to version control.
Keeping the System Honest Over Time
The Secrets Manager setup is only as reliable as the discipline around it. Rotate access tokens for service accounts on a regular schedule – Bitwarden makes this non-disruptive since you can generate a new token, update the value in your CI platform, and then revoke the old one without any downtime. Audit project membership whenever team composition changes, not just when a security incident prompts a review. The “People” tab in Secrets Manager shows exactly who has access to what, and a five-minute check every time someone joins or leaves costs almost nothing compared to chasing down a credential leak after the fact.
