Hi everyone, I've been diving into 1Password Business with my team over the last few months, mostly for our human users, and it's been great for shared marketing and dev logins. But I've hit a conceptual wall with our CI/CD pipelines.
We have several automated processes (like deploy scripts, analytics sync jobs, and content build pipelines) that need access to third-party services—think AWS, HubSpot APIs, and our CMS. Right now, these 'service account' credentials are hard-coded in environment files, which I know is a huge security no-no.
I see that 1Password has CLI tools and the whole 'Secrets Automation' thing, but I'm trying to wrap my head around the real-world workflow. Do you create a regular 1Password item (like a 'Login') for each machine identity and then pull it via the CLI in the pipeline? Or is there a different item type or a best practice structure for this specific use case?
Also, how do you handle permissions? Creating a vault just for these machine secrets and having the CI/CD service use a specific access token seems logical, but I'm curious about how you all manage rotation and auditing. Any gotchas or lessons learned would be super helpful.
I manage a small marketing tech team for a 70-person SaaS company. We've moved all our CI/CD and automation secrets out of config files and into 1Password Business, handling deployments to AWS and API calls to HubSpot and our CMS daily.
* **The setup isn't a Login item:** You use a specific **"Secret"** item type in 1Password for service credentials. It's designed for non-human use, storing things like API keys, tokens, and private certificates. You don't fill in username fields you don't need.
* **The real cost isn't just user seats:** To use Secrets Automation with CI/CD, you need the 1Password Business plan, which is roughly $8/user/month. The hidden cost is the **extra service account fee**, currently $5/month per machine identity. If you have 10 pipelines, that's an extra $50/month on your bill.
* **Integration effort is moderate but permanent:** You connect your pipeline using the 1Password CLI with a **service account token**. Generating that token and setting vault permissions takes maybe 30 minutes per CI/CD system. The ongoing effort is near zero, which is the win.
* **The break point is in orchestration:** 1Password manages the secret storage and access beautifully, but **it does not manage the actual rotation.** If you need to automatically rotate an AWS key every 90 days, you still need to build that process yourself, update the secret in 1Password via API, and sync the change. It's a store, not a rotator.
My pick is 1Password Secrets Automation for this, because it solves the secure storage and access problem cleanly for a fixed, known cost. If your main need is pulling static credentials securely in pipelines, it's a direct fit. If you need automated, scheduled credential rotation, tell us what cloud platform you're on and how many keys you manage, because that changes the recommendation.
Your CRM is lying to you.
The 'Secret' item type you've been advised to use is indeed the correct starting point. However, I've found the permissions and vault structure to be the critical, often overlooked, component. You absolutely need a dedicated vault for these CI/CD secrets, but you must also create a separate 1Password service account (that $5/month identity) for each distinct pipeline or automation context. Do not reuse a single service account across multiple pipelines, as this destroys your audit trail and makes granular revocation impossible.
In practice, you'll grant each service account access only to that dedicated automation vault. The CI/CD job then uses that service account's `OP_SERVICE_ACCOUNT_TOKEN` to fetch the specific secret. Rotation is still manual; you update the 'Secret' item and the next pipeline run fetches the new credential. The audit log in 1Password will show which service account accessed which item and when, which is your primary verification.
A significant gotcha is that the CLI's behavior can change between versions, and pinning that version in your Docker build image is a must. Also, while pulling a secret into a pipeline environment variable is common, for longer-lived processes, consider using the `op run` command to inject them directly, which can reduce the secret's exposure window in the CI system's own environment.
every dollar counts
You're absolutely right about the dedicated vault and separate service accounts for audit integrity. The point about pinning the CLI version in your Docker image is critical, but I've found the dependency management can get messy across teams. We now maintain a central internal Docker image with the pinned `op` CLI, Node, Python, and other core tooling just for this purpose. It adds a layer of management, but it standardizes the runtime and prevents "works on my machine" failures when the CLI updates.
I do have a practical counterpoint on rotation being manual. For high-velocity teams, that becomes a serious operational burden and a source of drift. We've started using 1Password's Events API to monitor for secret access failures, which often indicates a credential has expired somewhere downstream. It's not true automated rotation, but it at least triggers an alert for the team to go update the Secret item, moving us from a purely reactive to a monitored manual process.
Support is a product, not a department.
Your point about monitoring the Events API for failures is a smart operational improvement over pure manual checks. That shift from reactive to monitored manual is often the realistic step before full automation.
But that central Docker image approach is a double-edged sword. It solves the immediate versioning problem, but now you've created a single point of failure and a new team dependency. Who owns that image's security updates? What's your SLA when a zero-day in the pinned CLI version needs a rebuild? You've traded one type of drift for another.
For the rotation burden, I'd push back a bit. If manual updates are causing enough drift to be a "serious operational burden," then your secret rotation policy might be part of the problem. Why are you rotating so frequently that it can't be scheduled?
—AF