Anyone else dealing with this mess? We've got shared OAuth tokens for external APIs (think Slack, GitHub, Jira) that need to be used by our CI/CD pipelines. They expire. Rotating them manually is a pain and a security risk. 1Password Secrets Automation seems like the obvious vault, but how do you handle the actual *refresh*?
I'm currently abusing a Kubernetes CronJob that runs a script to refresh the token and update the secret in 1Password. It's ugly but works. The script looks something like this:
```bash
#!/bin/bash
# pseudo-code essence
NEW_TOKEN=$(curl -s https://api.example.com/refresh -H "Authorization: Bearer $OLD_REFRESH_TOKEN" | jq -r '.access_token')
op item edit "Service Token" --vault=Engineering credential="$NEW_TOKEN"
```
But now I have to manage the CronJob's own credentials to write to 1Password. Feels like I'm just building a rickety tower of secrets on top of secrets. 😩
What's the *proper* GitOps way? A dedicated token-refresher service? Does 1Password have a native pattern for this that I'm missing?
I'm a senior platform engineer at a ~300-person fintech, where we manage OAuth tokens for about a dozen external SaaS integrations powering our internal tooling and CI/CD. In production, we've moved from a manual rotation script to a dedicated, internal token management service built around HashiCorp Vault and a lightweight Go refresh orchestrator.
**Core Comparison of Approaches**
1. **Integration & Maintenance Effort:** A custom Kubernetes CronJob like OP's requires ~40-80 lines of scripting plus ongoing maintenance for each token type, and you're responsible for securing the refresh token itself. A dedicated internal service centralizes logic but demands initial development sprint (2-3 weeks for basic version). Managed services like Vault's OAuth flow or Akeyless require upfront configuration but then hands-off operation.
2. **Security Footprint:** The CronJob pattern leaves a persistent refresh token stored somewhere (1Password item, K8s Secret) which is a static secret you must still rotate. A purpose-built service can fetch short-lived tokens directly from your IdP (e.g., using workload identity) eliminating long-lived refresh secrets entirely. Vault's OAuth secrets engine holds the refresh token, but it's encrypted at rest and access is audit-logged.
3. **Cost & Licensing:** For low volume, the DIY CronJob is effectively free outside eng hours. HashiCorp Vault Enterprise (required for OAuth engine) runs ~$27/host/month at our scale, plus operational overhead. Akeyless SaaS platform pricing is usage-based but starts around $5k/year for their platform tier. AWS Secrets Manager with Lambda rotation is $0.40/secret/month + Lambda costs, but you build the connector.
4. **Failure Mode Clarity:** Scripts fail silently without rigorous monitoring and can leave tokens stale. A service can implement active health checks (e.g., token validity probe) and alerting. Vault's OAuth engine provides a renewal window but can struggle with custom provider token responses if they deviate from spec, requiring a custom plugin.
**My Pick**
For your CI/CD pipeline use case, if you're already using 1Password Secrets Automation, I'd recommend integrating a small, audited Lambda or Cloud Function (not a K8s CronJob) to handle the refresh, triggered by a scheduled event. The function assumes an IAM role with write access to 1Password via its service account, eliminating the secret-on-secret problem. This decouples the refresh logic from your cluster and leverages managed scheduling. If your token count grows beyond 5-6, then evaluating Vault Enterprise becomes justifiable. To decide, tell us: are these tokens only for your CI/CD system, or also for backend services, and what's your current primary cloud provider?
p-value < 0.05 or bust
Yes, moving to a dedicated service is the right scaling point. I've seen teams hit it around 5-6 distinct token flows. The break-even math is clear.
The security comparison you made is key. Your second point about eliminating long-lived refresh tokens is the real win. Storing a refresh token in 1Password just moves the static secret problem, it doesn't solve it.
One caveat on the 2-3 week dev sprint estimate: that's only if you're exclusively using Vault's OAuth secrets engine for supported providers (AWS, GCP, Azure). For custom OAuth providers, you still have to write and maintain the refresh adapter logic yourself, which is essentially the same script you were running in the CronJob, just inside a plugin. The orchestration is cleaner, but the core complexity remains.
Prove it with a benchmark.