Service Account Credential Rotation Without Manual Intervention in ShotGrid

Can ShotGrid Service Accounts Rotate Automatically?

Short answer: No. ShotGrid’s web UI and REST API do not expose a built‑in scheduler for rotating OAuth 2.0 bearer tokens or script‑user API keys. The only way to change a key is to trigger a regeneration manually or via an external call.

Why the Lack of Native Rotation Matters

Because a service‑account key is a long‑lived credential, an attacker who obtains it can impersonate the service indefinitely. Manual rotation keeps the key in use for as long as an admin remembers to change it, increasing the window of exposure. Automated rotation reduces that window but requires a trusted automation process that itself must be protected.

How to Automate Rotation Outside ShotGrid

While ShotGrid can’t schedule token renewal, you can build a lightweight automation that:

1. Regenerates the key via the API
   

   curl -X POST \
     -H "Content-Type: application/json" \
     -H "Authorization: Bearer <admin‑token>" \
     -d '{"userId": <script‑user‑id>}' \
     https://<shotgrid‑host>/api/v1/script/key
   

   This call returns the new key; the old key is immediately invalidated.
2. Stores the new key securely
   Use a secrets manager (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, etc.) to write the key under a predictable name (e.g., shotgrid/sg_service_key). Ensure the write operation is audited.
3. Propagates the key to dependent services
   If your application reads the key from the secrets manager at startup, it will automatically pick up the new value the next time it restarts. For long‑running services, you can trigger a graceful reload or use a sidecar that watches the secret and sends a SIGHUP to the main process.
4. Schedules the automation
   Configure a cron job, CI/CD pipeline, or serverless function to run the script every N days (e.g., 30). Store the automation’s credentials in the same secrets manager, granting only the read/write scope needed for the regeneration endpoint.

Security Implications

• Exposure Window: Manual rotation can leave a stale key active for weeks; automated rotation can limit that window to the rotation interval.
• Automation Credential Risk: The script that calls the regeneration endpoint must be protected. If it is compromised, an attacker can generate a new key and bypass the rotation schedule.
• Service Disruption: Changing the key invalidates all active bearer tokens. Services that don’t restart or reload the key immediately will fail authentication until they are restarted.
• Audit Trail: Automated rotation should log each regeneration with a timestamp and the actor (automation service). Manual changes rely on admin logs, which may be less granular.

When Manual Rotation Might Still Be Preferable

If your organization has strict controls over automation, or if the service accounts are only used in a few tightly‑controlled scripts, manual rotation can be simpler and reduces the attack surface of an automated process. Just make sure to document the rotation schedule and enforce it via policy.

Next Steps

1. Verify that no native rotation UI exists by inspecting the “Script Users” section in the ShotGrid admin panel. 2. Decide on a rotation interval that balances security and operational overhead. 3. Implement the automation script as described, secure its credentials, and test the key propagation path. 4. Monitor for failed authentication after rotations and adjust the reload strategy if necessary.