I'm looking into secure ways to manage secrets for our GitLab CI/CD pipelines. CyberArk Secrets Manager keeps coming up, but I'm unsure about the real integration effort.
Has anyone actually set this up? I'm curious about the steps involved and if it's worth the complexity compared to simpler vaults. How do you handle dynamic secrets for deployments? Any gotchas on pricing or maintenance?
Yes, we implemented it across three product teams last year. The integration effort is non-trivial, primarily due to the required configuration of the CyberArk Central Credential Provider (CCP) and the necessary network allowances between your GitLab runners and the CyberArk PVWA. You'll need to establish a reliable method for the runners to authenticate, often using application IDs and certificates, which adds several layers of setup compared to a cloud-native vault.
Regarding complexity versus simpler vaults, it's a trade-off for enterprise-grade audit trails and secret rotation. For dynamic secrets, you can use the CyberArk Conjur integration, which provides short-lived credentials. However, the pipeline job latency introduced by the secret retrieval calls is measurable; we observed a median increase of 450-600ms per secret fetch, which can compound in complex pipelines.
On pricing, the operational cost isn't just licensing. Consider the overhead for maintaining the high availability of the CCP endpoints and the ongoing certificate management. If your team lacks dedicated platform engineering support, the maintenance burden can outweigh the security benefits for a small to medium deployment.
Measure everything, trust only data
Latency is one thing, but let's talk about the audit trail fetish. That "enterprise-grade" logging often just creates a mountain of data no one actually reviews, while the real cost is the headcount needed to keep that whole CCP/PVWA circus running. You're spot on about the platform engineering tax.
Your stack is too complicated.
Completely agree about evaluating the complexity. We went through a similar evaluation six months back and chose a hybrid approach. For our core deployment pipelines that handle production keys, the CyberArk audit trail is actually valuable for compliance reports. But for lower environments and less sensitive app configs, we kept using GitLab's own variables or a simpler vault. The maintenance isn't too bad once the CCP is stable, but getting there requires platform team bandwidth that many product teams just don't have.
On pricing, watch out for how they count "secrets" versus "applications." Our initial quote was based on one type, but the fine print added costs for the machine identities used by the CI runners. That was a surprise.
Pipeline is king.
We did a proof-of-concept on it last quarter and honestly, the biggest hurdle wasn't the technical integration itself - it was getting our security and platform teams aligned on the new authentication flow for the runners. The actual GitLab CI job script is pretty clean once the CCP side is sorted.
But on your question of whether it's worth it, it really hinges on your compliance needs. If you don't have strict regulatory requirements demanding that granular audit trail, a simpler vault like HashiCorp or even GitLab's own external secrets feature will get you 80% of the way with 20% of the effort.
The pricing gotcha for us was the "concurrent sessions" limit for the CI connections, which we hit during peak pipeline runs. Something to check in your contract.
Comparing tools one review at a time.
The hybrid approach you describe aligns with the practical reality of these tools. Focusing the enterprise vault on the core compliance requirement while using simpler, faster solutions elsewhere is smart resource allocation.
Your point about the platform team bandwidth is critical. I've seen the initial CCP setup stretch to 6-8 weeks because it sits in a dependency queue behind higher priority work, which often kills the momentum for the product teams waiting on it.
On pricing, the "machine identities" gotcha is common. Vendors often price the human user seats visibly, but the machine or application identities, which you need for every runner or service account, are a secondary line item that scales with your automation. It's essential to model that during the cost assessment.
benchmark or bust
Yeah, that platform team dependency queue is the real killer, isn't it? Even if you've got the green light, you're just another ticket. We got around it by having one of our senior devs pair with the platform engineer for the initial CCP setup. It built some internal knowledge and shaved weeks off the timeline.
Your mention of modeling machine identity costs is spot on. We nearly missed that too. It's easy to think in terms of pipelines, but the cost scales with your *runner fleet* if you're using unique identities per runner. We ended up using a shared service account for all runners in a non-prod environment to keep those numbers down. It's a trade-off on the audit trail granularity, but it made the finances work.
The 6-8 week delay often means teams just revert to hardcoded secrets out of sheer frustration, which defeats the whole purpose.