I've been evaluating Delinea's suite (formerly Thycotic) for securing access to our Kubernetes infrastructure, specifically for CI/CD pipelines and developer tooling. The marketing claims are one thing, but what actually works in practice? After running a proof-of-concept for the last quarter, I can share some concrete observations.
The core challenge is bridging their traditional PAM model (vaults, password rotation) with the ephemeral, API-driven nature of Kubernetes. Here's what we implemented and tested:
* **Secret Server with the Kubernetes Sidecar Injector:** We deployed the Delinea Kubernetes Agent to auto-inject sidecars into pods. These sidecars fetch credentials (like database passwords) from Secret Server at runtime. The configuration is declarative via pod annotations.
```yaml
annotations:
delinea.com/secret-server-credentials: "true"
delinea.com/secret-name: "prod-db-creds"
```
This works, but adds overhead per pod. We measured a ~100ms latency on pod startup for credential retrieval. For our batch jobs, this was acceptable; for auto-scaling web services, it became a bottleneck.
* **DevOps Secrets Vault (DSV) for Service Accounts:** This was more aligned with cloud-native patterns. We stored Kubernetes Service Account tokens in DSV and used its API for JWT issuance to CI runners. The workflow involved a simple REST call from the pipeline:
```bash
# Request a short-lived token for a specific secret
ACCESS_TOKEN=$(curl -X POST https://dsv.example.com/oauth2/token ...)
```
Performance was significantly better. The DSV REST API consistently responded in <50ms. The main pitfall was managing the DSV policy schema—it's flexible but required careful mapping to our existing RBAC roles.
The biggest hurdle wasn't the technology itself, but the operational model. Rotating static secrets in Secret Server is robust, but integrating with Kubernetes' own certificate rotation for the control plane required custom scripting, which added complexity we hoped to avoid.
For teams considering this stack, I'd recommend starting with DSV for API-based access and treat Secret Server for legacy or highly static secrets. The hybrid approach seems to be where the practical utility lies.
benchmark or bust
benchmark or bust
That latency observation is super interesting, thanks for sharing real numbers. The sidecar injection pattern is slick for keeping secrets out of the image, but that cold-start penalty adds up fast when you're scaling.
We tried a similar approach with a different vendor and hit the same wall. We ended up moving to a pull-based model where the app initialization code fetches from the vault directly - still using the sidecar, but as a local cache so the fetch isn't on the critical path for pod readiness. It's a bit more code but saved our scaling services.
Have you looked into the trade-offs with using the DSV for issuing short-lived Kubernetes ServiceAccount tokens instead? That's been a more Kubernetes-native path for us, though it shifts the complexity to the RBAC side.
@sre_journey