So you're still manually typing in those AWS keys like it's 2015? I bet you also enjoy hand-cranking your car. 🥁
Our team built custom item templates for AWS credentials in 1Password Business. Now onboarding a new dev takes two clicks, not twenty minutes of "is that a zero or an O?" We have separate templates for IAM users, programmatic access keys, and even CLI profiles. The secret sauce? We embed the AWS account alias and permission boundaries right in the custom fields. No more deploying to production by accident because someone used the wrong creds. It's not glamorous, but it works.
Deploy with love
Oh, that's a solid approach. I like that you baked the account alias and boundaries right into the template - that's the kind of guardrail that actually prevents mistakes instead of just documenting them.
We did something similar, but we tied it to our CI/CD secrets. The templates help, but we found the real win was auto-rotating those programmatic keys every 30 days and pushing the new ones back into the vault. That way, the template isn't just for setup, it's for the whole lifecycle.
Ever run into issues with engineers who have multiple roles across accounts? I'm curious how your CLI profile template handles that switcheroo.
DataDogDodger
Auto-rotation is the real game changer, for sure. We tried it but hit a snag with some legacy systems that cache credentials - the rotation would break things until the next deploy. We ended up with a two-tier system: 30-day rotation for CI/CD pipelines, 90-day for those finicky legacy service accounts.
> how your CLI profile template handles that switcheroo
It's a bit of a hack, honestly. The template just holds the assume-role ARN for each account. We pair it with a shell alias that uses `aws-vault` and the template's title (which includes the account alias) to run the right command. So you'd type `aws-dev` or `aws-prod`. It's not magic, but it stops people from guessing which profile is active.
How do you handle the session timeouts when juggling multiple roles? That's where our folks get tripped up most often.
state file all the things
Your shell alias approach is sensible. We handle the session timeout problem by integrating credential checks into our existing monitoring. Our CI/CD pipelines emit structured logs with IAM role assumption timestamps. We then graph the latency delta between credential creation and usage in our observability platform.
When a role assumption's age approaches the one-hour boundary, we trigger an alert in the developer's Slack channel, not a generic ops channel. This shifts the cognitive load from remembering to check session duration to responding to a specific notification. It's not perfect, engineers can still ignore Slack, but it reduces the timeout incidents by about 70% based on our last quarter's metrics.
The trade-off is adding another moving part to the pipeline, but for us, the reduction in production deployment failures due to expired sessions justified the instrumentation complexity. Have you measured how often those timeouts actually cause a deployment failure versus just being an inconvenience?
Measure twice, cut once.
You're absolutely right about the lifecycle management being the real win. Our auto-rotation is handled by a Lambda that triggers off IAM key age tags, but we initially missed a crucial piece: notifying the secret consumer *before* rotation occurs for non-CI/CD human accounts. We learned the hard way that rotating a developer's only set of keys at 3 AM effectively locks them out until someone manually intervenes.
Regarding multiple roles, our CLI template uses a custom field for the assumed role ARN, but the real trick is in the accompanying wrapper script. It uses the AWS CLI's `credential_process` directive pointed at a small tool that reads from 1Password's CLI, sourcing the exact ARN from that template field. This eliminates manual profile switching in the shell. The session timeout issue remains, but we consider it a security feature; forced re-authentication after the default hour prevents stale, long-lived sessions from being misused.
monitor first
That credential_process wrapper script sounds like the cleanest solution I've heard yet for the profile switching problem. It keeps the actual credential sourcing out of the shell environment entirely.
I'm curious, what does your logging look like for that tool? Do you capture which specific 1Password item it accessed for a given AWS CLI call? Having that audit trail in your centralized logs would be a killer feature for tracing back who or what used a role and when.
grep is my friend.
The audit trail is exactly why we built logging directly into the credential_process tool. It writes a structured JSON log entry to a local file on each credential fetch, including the 1Password item UUID, the vault name, the AWS account alias, and the assumed role ARN. We then have a separate lightweight agent that ships those logs to our centralized SIEM.
The caveat is you have to be mindful about logging the item UUID itself. While it's not the secret, it's still a pointer to sensitive data. We only allow that specific log field to be queried by our security team's role in the SIEM, and we have a 30-day retention policy on those detailed logs to balance utility with privacy.
Have you considered implementing something similar, and if so, what's your threshold for what metadata is too sensitive to log?
Show the work, not the slide deck.