Automated Connect server token rotation
I've been evaluating whether I can use 1Password Connect for configuration/secrets management for my company's services. 1Password Connect looks very appealing for several reasons:
- No rate limits. No usage limits. As a 1Password customer, we have unlimited access to this offering.
- Uniform UI. We already use 1Password for managing passwords and various secrets used during local development. It would be very nice to use the same interface to manage lifecycle of configurations and secrets that are used by production services.
- Pretty straightforward REST API and SDKs in languages that we use allows getting the latest config/secret values at runtime. I am not very interested in using 1Password Connect Operator (or using k8s Secrets in general) since this provides secrets to the service at deploy time. I appreciate the ability to automatically redeploy the service when the underlying 1Password item changes but this works well only for stateless services. I prefer getting configurations/secrets at runtime over an API.
I started experimenting with this offering and working out how to integrate it into our systems. The docs recommend creating a Connect server token for every service which makes a lot of sense. And the docs strongly suggest setting an expiration on this token which also makes sense. After all, it's a static credential not tied to the identity of the service that uses it; so frequent rotation should reduce the risk of a leaked token causing damage.
But the issue is that I don't see a way to automate this rotation given the permission model that is in use today. Is it possible for either a Service Account or a Connect client to manage connect tokens (create/delete tokens)?
I was thinking of integrating 1Password connect as follows:
- Our deployment pipeline is high trust. It would use either Service Account or Connect client credentials that expire infrequently. It's OK for a human to ensure this credential doesn't expire and rotate it when necessary.
- When a service deployment is kicked off, the deployment pipeline creates a new Connect token.
- The pipeline ensures that the newly created Connect token is accessible to the service as an environment variable.
- Once the service is deployed and is considered healthy, the old Connect token (used by the previous deployment of the service) is deleted.
In this setup, the deployment pipeline can create the new Connect token with a relatively short expiry and we can assume that every service gets redeployed more often than this expiration period.
I think this setup is pretty reasonable but I don't see a way of giving the deployment pipeline access to create/delete Connect tokens. I tried using a Service Account to create a Connect token via the CLI and got 403. I see that it's possible to give a group access to manage Secrets Automation, but I don't think it's possible to make a Service Account a member of some group. Correct me if I am wrong.
I also tried using a Connect client to create a new Connect token and this didn't work:
"op connect token create" doesn't work with Connect.
https://developer.1password.com/docs/connect/manage-connect of your docs mentions: "You can use 1Password.com or the https://developer.1password.com/docs/connect/api-reference/ to: ... https://developer.1password.com/docs/connect/manage-connect#create-a-token and https://developer.1password.com/docs/connect/manage-connect#revoke-a-token Connect server tokens." but I think it's a typo.
As things stand today, Connect server token rotation can only be done by a human user which doesn't scale beyond a handful of services. If I were to go down that path, I would have to set expiration to a longer period which affects security. This makes 1Password Connect a lot less appealing.
Please let me know if I am missing something and if there is a way to automate token rotation.