Hi everyone! 👋 We're finally diving into 1Password Business, and I'm tasked with setting up the 'Secrets Automation' feature for our development team. I've read the overviews, but I'd love to hear from teams who are already using it in practice.
Our main goal is to securely replace the hardcoded API keys and environment variables scattered in our config files and CI/CD scripts. The devs are excited but a bit unsure about the actual workflow change.
From an enthusiast who loves a good checklist, I'm trying to map out our first steps. Does this sound right?
* **Start with the 1Password CLI tool:** My understanding is this is the core piece for developers to fetch secrets.
* **Create a dedicated vault for automation:** Probably separate from our personal employee vaults, with tight access controls.
* **Define our initial secret types:** Things like database credentials, cloud provider keys, and external API tokens.
* **Integrate with our CI/CD (GitHub Actions first):** This seems to be the biggest win for automating deployments.
My specific questions are:
1. What was your team's biggest "aha" moment or hurdle when switching from a manual secrets process?
2. Are there any particular templates or permission structures you found crucial for a smooth developer experience?
3. How do you handle secret rotation? Does the automation make it easier or introduce new steps?
Any pro-tips, pitfalls to avoid, or even a skeleton of your onboarding doc would be incredibly helpful. I want to make this adoption as seamless as possible for our engineers.
Cheers!
Yeah, your checklist is spot on! Creating a dedicated automation vault was our first move too. It keeps things clean.
Our biggest "aha" was seeing devs stop sharing secrets over Slack. The CLI made it so simple to just reference an item name. The biggest hurdle was that initial shift - remembering to use the CLI instead of just opening the app.
> integrate with our CI/CD (GitHub Actions first)
Absolutely. Start with one pipeline to get the service account and permissions sorted. It gets easier after that first one works.
Do you have a plan for rolling it out to the team? Like, a pilot project or all at once?
The shift away from Slack secrets is a real win for audit trails. That's the compliance benefit right there.
On the pilot question, I'd recommend against an all-at-once rollout. Start with a single, non-critical service in your GitHub Actions. You need to validate your access model for the service account and get the revocation process documented before it touches anything production-adjacent.
Get that first pipeline working, then have the devs from that project champion it to others.
Where is your SOC 2?
Your checklist is solid for the technical steps. The process and governance around it are what trip teams up.
Your second question about permission models is the right one to focus on. Avoid giving individual devs broad access to the automation vault. Instead, use tightly scoped service accounts for CI/CD systems and rely on group-based permissions for devs accessing secrets locally. The principle should be that the pipeline account can only read the secrets it needs, nothing else.
My addition to your list would be: **Document a clear revocation procedure.** Before you store a single production key, know exactly how to instantly rotate it and update all references. That's the real test of your automation setup.