We've been running CyberArk for 18 months to manage privileged access for our infrastructure and Kubernetes clusters. The team consists of five engineers with combined responsibilities in security, platform engineering, and on-call. After the initial "wow, enterprise PAM" phase wore off, we've settled into a daily operational reality that is, frankly, a mixed bag of powerful capability and profound frustration. This is not a review from a CISO's PowerPoint deck; it's from the people who have to make it work at 3 AM.
**The Good (Where It Earns Its Keep)**
* **Centralized Session Management & Recording:** For SSH and RDP sessions to critical nodes and databases, the isolation and full audit trail are non-negotiable for us. The session playback has been invaluable in at least two major incident post-mortems to see exactly what commands were run.
* **Credential Vaulting Core:** The fundamental secret storage is robust. Rotating service account passwords automatically for Windows servers and network devices works as advertised. The API for fetching secrets, while clunky, is reliable.
* **Privilege Delegation:** The ability to broker access to a production server without handing out the root password, using ephemeral credentials, is a core security control we wouldn't want to give up.
**The Bad (Where The Friction Lives)**
* **Operational Overhead is Immense:** This is not a "set and forget" system. It's a complex distributed application that *you* now host and manage.
* The components (PVWA, CPM, PSM, etc.) are fragile. We've had numerous issues with the Password Manager (CPM) failing to rotate passwords due to obscure timeout settings, requiring constant tuning of `policy.xml` files.
* Patching is a multi-day orchestration nightmare that often breaks integrations.
* **Kubernetes Integration is an Afterthought:** Their "native" Kubernetes integration is essentially a sidecar container that fetches secrets from the vault. It doesn't understand pod identity natively, forcing you back to static accounts or complex workarounds. We ended up building our own operator to sync secrets to native Kubernetes Secrets (with short TTLs) because the official method added too much latency and complexity to our pod startup.
```yaml
# This is a simplified version of the custom controller logic we had to write.
# The CyberArk Conjur provider does not handle dynamic, per-pod identities well.
apiVersion: v1
kind: Secret
metadata:
name: app-db-creds
annotations:
cyberark-sync/secret-id: "prod/postgres/app-user"
cyberark-sync/ttl: "300s" # Force a re-fetch every 5 minutes
type: Opaque
data:
password: "" # Populated by controller
```
* **Cost and Complexity Spiral:** The licensing model is opaque and punishing. Every new type of target (Windows server, Unix server, database, Cisco device) can be a different cost center. Scaling the infrastructure (redundant PVWAs, PSMs) for high availability directly translates to significant additional license and hardware costs.
* **User Experience is Antiquated:** The Privileged Access Web Interface (PVWA) is slow and unintuitive. Engineers complain about the number of clicks to get a simple SSH session. For a tool designed for emergency access, the UI delay is perceptible and aggravating during incidents.
**Conclusion & Alternatives Considered**
CyberArk is powerful for what it is: a legacy-aware, enterprise PAM suite that excels at managing traditional, static infrastructure (servers, network devices, AD accounts). If that's your primary threat model, it will do the job, albeit at a high total cost of ownership.
However, for a team also heavily invested in cloud-native and Kubernetes, it feels like we're forcing a square peg into a round hole. We constantly evaluate whether the benefit for the 70% of our legacy estate justifies the overhead for the 30% that is modern.
We are actively piloting HashiCorp Vault for secrets management (particularly for apps and CI/CD) and are considering a more focused PAM tool like Teleport or Bastion for secure access to our Kubernetes clusters and cloud consoles. CyberArk may remain as the "record of truth" for our core server credentials, but its role is shrinking, not expanding, in our architecture.
If your environment is predominantly static, on-prem servers, you can probably tolerate its weight. If you are moving fast with containers, microservices, and dynamic infrastructure, prepare for a significant integration tax and ask very hard questions about the roadmap.
Measure twice, migrate once.
That's the exact turning point in the PAM journey, isn't it? The core credential rotation works, but the human operational experience often falls apart.
Your mention of the API being clunky resonates. For us, that's where the real cost lives. We built a ton of wrapper scripts and error handling for those API calls, which becomes a maintenance burden. It feels like you're paying enterprise prices but still need to build half the "enterprise readiness" yourself.
Curious - have you tried integrating its secret fetches into something like a Kubernetes operator or your CI/CD pipeline? The friction there, especially around just-in-time access for deployments, is where we started questioning the total cost of ownership versus a more developer-centric secrets manager. The audit trail is fantastic, but if engineers are working around it because the workflow is heavy, you've created a new shadow IT risk.
Every dollar counts.