Anyone using CyberArk for service accounts in production?

We've been using it for about a year for similar use cases. The API is solid, but the initial setup for Jenkins plugins was a bit clunky. Once configured, it's reliable.

Biggest win for us was automating secret rotation for those database service accounts. We built a small sidecar service that fetches creds from CyberArk and injects them as environment vars into the pipeline right before the deployment step. Zero hardcoded leftovers.

Performance hit is minimal - maybe adds 2-3 seconds to a pipeline for the credential fetch. Totally worth it for the security bump. Our cloud service principal rotation is fully automated now, which is a huge relief.

We've been on CyberArk for service accounts for a few years now, and your use cases line up almost exactly with ours. On API reliability, I'd say it's dependable for automated retrieval, but you absolutely need to build in retry logic with exponential backoff - we've had the occasional network blip cause a pipeline to fail. That's more of an infrastructure note than a critique of the API itself.

For handling secret rotation in pipelines, our approach was to avoid having the pipeline itself call the CyberArk API directly. Instead, we centralized it into a shared pipeline library (Jenkins) or a composite action (GitHub Actions). That library handles the fetch, maps the secret to an environment variable with a short TTL, and then explicitly wipes it after the deployment step. This keeps the pipeline code clean and ensures we don't accidentally log the secret. The performance impact is similar to what user623 mentioned, a few seconds at most.

A caveat on SSH keys: the integration can be trickier. We ended up writing a small wrapper script that fetches the private key and passes it directly to ssh-agent within the pipeline session, making sure to unload it after. The key is to never let the key material hit the disk, even temporarily. Have you looked at how you'll handle that part yet?

Totally agree on the shared library approach. It's a game-changer for consistency across teams. We did something similar with a custom Terraform provider module that fetches creds from CyberArk during plan/apply, so the secret's only ever in memory during the Terraform run.

The retry logic point is crucial. We learned the hard way too. Our backoff logic also includes a notification to our monitoring channel if it fails more than twice - helps us spot infrastructure issues early.

I'm curious about your wrapper for SSH keys. Did you run into any issues with the key persisting in the agent longer than expected on long-running jobs?