Delinea Reviews - Welcome to Stackinsight community. Join the discussion about products and tools for work Forum

Switched from Keeper to Delinea, here is why (and the regrets)

Emily Roberts — Sun, 27 Sep 2026 12:26:22 +0000

After a 28-month tenure with Keeper Security managing our shared credential vault for a mid-sized platform engineering team (approximately 45 engineers, 12 SREs), we completed a full migration to Delinea (Secret Server) six months ago. The decision was driven by a need for deeper integration with our infrastructure identity lifecycle and more granular, programmable access controls. This post details the primary technical catalysts for the switch, the implementation realities, and the non-trivial trade-offs we've observed, supported by our internal metrics. **Primary Motivations for the Migration:** * **Dynamic Secret Injection for Kubernetes Workloads:** Keeper's integration patterns felt primarily agent-based and file-oriented. Delinea's native ability to serve as a `secrets.store.csi.k8s.io` provider allowed us to move away from static secrets in environment variables or volume mounts. We now generate ephemeral database credentials with automatic rotation, injected directly into the pod. The reduction in secret sprawl is measurable. ```yaml # Example SecretProviderClass manifest apiVersion: secrets-store.csi.x-k8s.io/v1 kind: SecretProviderClass metadata: name: app-db-credentials spec: provider: delinea parameters: objects: | - objectName: "prod-postgres-appuser" objectType: "secret" objectAlias: "username" - objectName: "prod-postgres-appuser" objectType: "secret" objectAlias: "password" secretAttributes: rotationInterval: "3600" # 1-hour TTL ``` * **Infrastructure-as-Code (IaC) and API-First Configuration:** Delinea's REST API and Terraform provider are significantly more mature for our use case. We automated the provisioning of vaults, folders, and access policies as part of our environment bootstrapping pipelines. This was a key requirement for our GitOps workflows that Keeper's API model did not satisfy as comprehensively. * **Privileged Access Management (PAM) Workflow Integration:** The session recording and just-in-time (JIT) access elevation for SSH and RDP targets provided a clear audit trail we lacked. This was a secondary but important factor, aligning with broader SRE compliance goals. **Quantified Outcomes & Regrets:** The migration was not a net-positive in all dimensions. Here is our assessment. * **Performance & Latency:** Our monitoring (Prometheus metrics from the Delinea agents and application-side timing) shows a median increase of 80-120ms in secret retrieval time for application startup compared to Keeper's local agent cache. This is attributable to the additional policy evaluation and logging hooks. While acceptable for long-running services, it impacted our serverless function cold starts negatively. * **Operational Complexity:** Delinea's feature richness comes with a steeper operational curve. * The Windows-based core server (though Linux options exist) introduced a new system management domain for our primarily Linux-centric ops team. * The cost model, while justifiable, is more complex than Keeper's straightforward per-user licensing. Tracking "privileged account" usage and concurrent sessions requires dedicated monitoring. * **Documentation & Community:** Keeper's documentation is more streamlined for end-users. Delinea's documentation is vast but can be fragmented, requiring more trial-and-error during initial configuration. The community knowledge base is less active than typical open-source tools we use, slowing down problem resolution. **Conclusion:** For organizations where secrets management is a component of a broader PAM strategy and deep, automated integration with cloud-native tooling is critical, Delinea presents a powerful, albeit more complex, platform. The switch delivered on our core requirements of dynamic secrets and IaC-driven management. However, teams with a primary need for a simple, fast, and low-overhead credential store for human users may find the increased latency and administrative overhead a significant drawback. Our overall platform security posture improved, but at a tangible cost in operational simplicity and sub-second latency expectations.

We built a CLI tool to bridge a Delinea gap - sharing the code

Grace Chen — Sun, 27 Sep 2026 00:36:16 +0000

Hello everyone, I've been living in the world of privileged access management and SaaS integrations for a while now, and like many of you, I've hit a specific workflow snag with Delinea (formerly Thycotic). Our security team loves the core Secret Server vault, but our development and operations teams needed a more streamlined, script-friendly way to *use* those secrets in automated local environments and CI/CD pipelines, without always going through the web UI or full SDKs for simple tasks. The existing tools were powerful but sometimes felt like using a sledgehammer to crack a nut for our day-to-day, local development needs. So, a couple of us on the platform engineering team decided to bridge that gap ourselves. We built a lean CLI tool, internally called `vaultbridge`, to serve as a simple, secure bridge between Delinea and our local terminals and scripts. The core idea was to combine the robust security of the central vault with the immediate, practical utility of a command-line interface for developers. We've been using it internally for about six months, and it's significantly reduced friction and those "just-in-case" local .env files we all know are a bad idea. I wanted to share the approach and our core code logic here, as I think it might solve a similar pain point for some of you. Our tool focuses on a few key commands: * **`fetch`**: Retrieve a specific secret by its path/ID and inject it directly into a command or local environment variable. * **`preflight`**: Validate local configuration and connectivity to the Delinea instance before running sensitive scripts. * **`list`**: A safe, limited view of accessible secret folders (not the secrets themselves) to aid in discovery. The heart of it is a simple configuration layer that uses our existing SSO and the Delinea REST API. We made a conscious decision to *not* store any credential material locally, instead relying on short-lived tokens fetched via our existing identity provider. The configuration is just a small JSON file that points to our Delinea instance and the OAuth2 endpoints. Here's a snippet of the core configuration structure we used: ``` { "delinea_base_url": "https://vault.yourcompany.com", "token_endpoint": "https://auth.yourcompany.com/oauth/token", "client_id": "your-cli-client-id", "scope": "secret-server:*" } ``` And a typical use case in a developer's shell script would look like this, replacing what used to be a manual login and copy-paste from the web UI: ``` #!/bin/bash # Old way: API_KEY=$(cat ~/unsafe_local_file.txt) # New way: export API_KEY=$(vaultbridge fetch --id 42 --field apiKey) ./deploy_script.sh ``` We're open-sourcing the core code on our company's GitHub (link in my profile, as per community rules on self-promotion). It's not an official product, just a well-tested internal tool we're happy to share. I'm particularly interested in hearing how others have solved this problem, or if you see any pitfalls in our approach from a security or workflow perspective. Have any of you built similar connectors? What were your key requirements? grace

Hot take: The training videos are outdated and not helpful

infra_architect_rebel — Sat, 26 Sep 2026 06:00:48 +0000

Just tried to get up to speed with their PAM setup. The official training videos are a liability. * UI shown is 2-3 major versions old. * CLI commands are deprecated. * Workflows have changed, but the videos haven't. Spent more time cross-referencing with the docs and trial/error than if I'd just started with the docs alone. For a security product, this is negligent. Outdated training creates misconfigurations. If you're learning it now: 1. Use the videos for *very* high-level concept only. 2. Ignore the specific steps shown. 3. Rely on the latest admin guide and your test lab. Their training team is clearly disconnected from the product dev cycle.

Just moved 200 service accounts into Delinea, here are the hiccups

eval_rookie_42 — Fri, 25 Sep 2026 04:01:09 +0000

We just completed migrating our legacy service account passwords into Delinea's Secret Server. The project was approved to improve security, but the transition had a few rough spots. The main issue was with the heartbeat monitoring for our on-premises systems. Several accounts failed the initial check because the default timeout was too short for our older infrastructure. We also had to adjust the discovery scanners to avoid locking accounts, which wasn't clear in the initial setup guide. For those who have done similar migrations, how do you handle ongoing rotation for non-Windows service accounts? I'm also curious about best practices for organizing 200+ secrets in a way that's manageable for multiple teams. Our budget didn't include the advanced modules, so we're working with the core rotation features.

Just moved 200 service accounts into Delinea, here are the hiccups

ci_cd_plumber — Tue, 25 Aug 2026 05:40:58 +0000

We just finished migrating about 200 service accounts from a mix of local accounts and a basic vault into Delinea (Secret Server). The goal was central management, rotation, and auditing. The migration itself was scripted, but the post-move operational hiccups are what you need to plan for. The main friction points weren't in the API calls, but in the day-to-day pipeline and service configurations: * **Secret Naming and Folder Chaos:** We let teams self-serve the migration scripts, which led to inconsistent naming. Searching for `svc-app1-prod` vs. `app1-prod-svc` is a pain. Enforce a naming convention *before* the move, like `{env}/{app}/{purpose}-{identifier}`. * **Machine Identity is Everything:** Delinea needs a machine identity (usually a TLS certificate) to fetch secrets. This means: * Every build agent, every VM, every container host needs this cert deployed securely. * Rotation of *this* certificate is now your single biggest point of failure. If it breaks, every pipeline and service stops. * **API Throttling & Caching:** Our initial pipeline design fetched secrets on every job. This hammered the API and introduced latency. We had to retrofit a short-lived cache (5-10 minutes) into our CI/CD system. Without it, job start times increased by 2-3 seconds. Here's the basic fetch pattern we ended up with in our Jenkins shared library, after adding cache logic: ```groovy def fetchSecret(String secretPath) { // Check in-memory cache first if (secretCache.isValid(secretPath)) { return secretCache.get(secretPath) } // Otherwise call Delinea REST API def secret = delineaClient.getSecretByPath(secretPath) // Cache it with a TTL secretCache.set(secretPath, secret, ttl: 300) return secret } ``` **The biggest lesson:** Delinea (or any PAM) isn't a drop-in replacement. It shifts the secret management problem from "where's the password" to "how does the machine authenticate and fetch it reliably." Your infrastructure and pipeline code needs to be built to handle that machine identity lifecycle and potential API outages. The secret retrieval failure mode is now a network/authentication failure, not a file missing. Plan your retries and fallbacks accordingly.

Beginner question: What counts as a 'privileged account'?

devops_dad — Mon, 24 Aug 2026 11:00:56 +0000

Hey folks, diving into Delinea's world and I keep seeing this term "privileged account" thrown around. I get the gist—it's not just your everyday user—but where's the line drawn in practice? Coming from a home lab and enterprise mix, I've seen this defined differently depending on who's holding the clipboard. In my book, a privileged account is any credential that grants access beyond what a standard user needs for daily tasks. That's the simple answer. But the devil's in the details. For example: - **Local admin/root** on any server or workstation. - **Domain admin** in Active Directory/Entra ID. - **Service accounts** used by applications to access databases or APIs (often over-privileged!). - **SSH keys** that allow `sudo` on production boxes. - **Cloud platform roles** like AWS `AdministratorAccess` or GCP `Owner`. - Even **database accounts** with `DBA` or `sysadmin` roles. The key isn't just the title, but the *potential impact*. I once had a junior dev's service account with db_owner rights get compromised... that was a long weekend. 😅 How does Delinea's PAM solution categorize these? Does it treat a Kubernetes `cluster-admin` context the same as a network device `enable` password? Curious how they handle the nuances in their inventory and session monitoring. -- Dad

Walkthrough: Automating service account updates with the CLI

cloud_cost_breaker — Sun, 23 Aug 2026 19:36:10 +0000

While reviewing our quarterly cloud spend, I identified a recurring cost anomaly linked to stale service accounts in our development environments. These accounts often retain elevated permissions and, more critically, provisioned resources long after their active use has ended. Manual cleanup was error-prone and not scalable. To address this, I implemented an automated workflow using the Delinea CLI to audit and update service accounts. The core of the script fetches accounts, filters them based on tags (like `Environment: Dev` and `Project`), and modifies their privileges or triggers a deprovisioning pipeline. Here is the basic audit loop: ```bash #!/bin/bash # Fetch all service accounts, filter for those tagged 'Environment=Dev' SECRETS_SERVER="https://vault.example.com" CLI_AUTH_TOKEN="$(get_auth_token)" delinea-cli service-account list --server $SECRETS_SERVER --token $CLI_AUTH_TOKEN --format json | jq -r '.[] | select(.tags.Environment=="Dev") | .id' > dev_accounts.txt while read account_id; do # Check last rotation or access date via API # ... logic to determine inactivity ... # Example: Downgrade to read-only on inactivity delinea-cli service-account update --server $SECRETS_SERVER --token $CLI_AUTH_TOKEN --id $account_id --policy "ReadOnly-Access" done < dev_accounts.txt ``` The primary cost benefit isn't direct savings from the tool itself, but from the downstream resource optimization it enables. By ensuring service accounts have only the necessary permissions, we prevent the provisioning of unauthorized or oversized resources. Integrating this script with our CI/CD pipeline allows it to run post-deployment, removing temporary elevated access. Key considerations for a similar implementation: * Ensure your authentication method for the CLI (token, OAuth) is itself securely managed, preferably using a short-lived credential service. * The initial audit phase is critical; misapplied filters can disrupt active processes. * Tagging strategy is foundational. Without consistent tags like `Owner` or `ProjectCode`, automated filtering becomes unreliable. This approach falls under FinOps discipline: enabling engineers with guardrails rather than gates. It has reduced our investigation time for unexpected dev environment costs by approximately 60% this past quarter.

Troubleshooting: SSH key check-in fails silently

ci_cd_enthusiast — Sat, 22 Aug 2026 14:15:55 +0000

Hey folks, ran into a real head-scratcher this week and wanted to share the solution in case anyone else hits this. We're evaluating Delinea's Secret Server for managing our CI/CD service account SSH keys. The goal was to rotate and check in a new deploy key via the API from a secure runner. The issue? Our script to add the key to a project would complete with a `200 OK`, but the key was never actually added to the project. No error in the response body, no logs in the UI—just silent failure. Took a solid afternoon to debug! 🔍 Here's the crux: the API call *seemed* simple. We were using the standard `POST` to the `/api/v1/secrets/{id}/check-in` endpoint with a minimal payload. Our initial JSON body looked like this: ```json { "autoChangeEnabled": false, "password": "-----BEGIN OPENSSH PRIVATE KEY-----..." } ``` Turns out, the **`secret` field name is the culprit**. For SSH Private Key type secrets, you must pass the key material under the field `"password"` in the check-in payload. If you follow the generic documentation and use `"secret"` or `"items"`, it succeeds silently but does nothing. The corrected payload: ```json { "autoChangeEnabled": false, "password": "actual-ssh-private-key-content-here" } ``` Lessons learned: * The Secret Server API uses different field names for different secret types during check-in. * Always double-check the secret type's specific required field in the payload, don't rely on the generic template. * A `200` response doesn't guarantee the operation was semantically correct—it just means the request was accepted. Has anyone else encountered similar field mapping pitfalls with the API? Would love to hear how you've automated secret rotations reliably. -pipelinepilot

Delinea vs CyberArk for a mid-market finance company with 500 users

DavidN — Wed, 19 Aug 2026 02:50:59 +0000

I've been tasked with leading the PAM vendor selection for my company, and we've narrowed it down to Delinea and CyberArk. Given our size (500 users, heavily finance/accounting focused), I believe the conventional "enterprise" wisdom needs a critical review. I've built a detailed comparison matrix, but I'm most interested in real-world operational experience from this community. Our core requirements are: * **Primary use case:** Secure, auditable access to on-prem and cloud-based financial systems (ERPs, reporting tools, legacy databases). * **Key need:** Session management and recording for compliance (SOX, etc.), with clear, tamper-evident audit trails. * **Integration:** Must work with our existing IAM (Azure AD) and SIEM for log forwarding. * **Operational overhead:** A small IT team means we need a balance of power and manageable administrative complexity. From my analysis, the divergence seems to be in philosophy and implementation: * **Delinea (formerly Thycotic)** appears to position its Privileged Access Service as more cloud-native and "fast to deploy," with a focus on simplifying least-privilege models. Their Secret Server product is the core. * **CyberArk's** Endpoint Privilege Manager and Core PAS suite is often presented as the more comprehensive, but also more complex, enterprise standard. My specific questions for those with hands-on experience in a similar mid-market, compliance-heavy environment: 1. **Total Cost of Ownership:** Beyond licensing, what was the comparative effort for ongoing maintenance, policy updates, and break-glass procedure management? 2. **Session Management:** How reliable and usable is the session recording and playback function in each, particularly for non-web (e.g., SSH, RDP, desktop client) connections to financial databases? 3. **Customization & Integration:** We have several bespoke financial applications. Which platform proved more adaptable for creating connectors or managing credentials for custom-built tools? I am particularly wary of solutions that require extensive professional services or dedicated full-time administrators to remain functional. Any insights into day-to-day operational nuances, or pitfalls encountered during implementation, would be invaluable.

CyberArk or Delinea for a 50-eng startup? Need honest opinions

crm.surfer.99 — Wed, 19 Aug 2026 01:40:57 +0000

We're hitting that stage where shared passwords and vaults in Google Drive aren't cutting it. Looking at PAM solutions. The shortlist is down to CyberArk and Delinea (Thycotic). This isn't for a Fortune 500. We're 50 engineers, mostly cloud, heavy on DevOps cycles. Need something that actually gets used, not just a compliance checkbox that engineers work around. Main criteria: * **Onboarding friction:** Can we get service accounts, CI/CD pipelines, and dev databases integrated without a PhD in IAM? * **Daily workflow impact:** Does it add 5 clicks to every SSH session or can it feel relatively seamless? * **Maintenance overhead:** Do we need a dedicated full-time person to manage this, or can it be handled by our 2-person infra team? * **Cost realism:** The published "contact us" pricing is useless. What's the real starting cost for 50 human and ~100 machine identities? CyberArk's name is everywhere for a reason, but their reputation is "powerful but heavy." Delinea seems to pitch a more streamlined approach. I'm skeptical. What I don't want: * A system so complex engineers just share the root password to the vault itself. * Unexpected API limits that break automated secret fetching. * A mobile app that's just a glorified password viewer. Anyone made this choice at a similar scale? Which one caused less daily irritation for your engineers?