I've been evaluating PAM solutions for a new zero-trust initiative, moving away from shared root accounts. We shortlisted CyberArk, HashiCorp Vault, and the newer Clutch Security. I chose Clutch for a proof-of-concept due to its developer-centric API and cloud-native design. Here's my hands-on experience from signup to initial configuration.
The signup process was straightforward via their SaaS portal. The immediate step was integrating our primary identity provider (Azure AD). Clutch uses a standardized OIDC flow. The configuration required uploading the IdP's OIDC metadata JSON and mapping groups to Clutch roles. A key differentiator was the ability to define "just-in-time" access rules directly during this phase, which was promising.
The core setup involved defining targets (our Linux VMs and database clusters) and configuring access flows. I used their Terraform provider for reproducibility, which was a major plus. The provider's resource schema for a target server looked like this:
```hcl
resource "clutch_target" "postgres_production" {
name = "postgres-cluster-01"
type = "postgresql"
address = "pg.internal.example.com:5432"
credential_store = clutch_credential_store.vault.id
session_policy = "breakglass_approval"
}
```
Initial performance testing on session establishment showed promise. The proxy overhead for SSH sessions was sub-50ms, which is acceptable. The audit log generation is comprehensive, capturing every command in a structured, queryable format. However, I encountered some friction with their agentless setup for Windows targets, requiring specific firewall exceptions not well-documented.
My preliminary benchmarks for session launch (10 sequential requests) against a traditional SSH jumpbox:
* **Traditional Bastion:** ~120ms average connection time.
* **Clutch Proxy:** ~165ms average (includes authz check and audit stream init).
* **Vault Dynamic Secrets + Bastion:** ~210ms average.
The developer experience for API-driven access requests is where Clutch stands out. The REST API for generating a time-bound session token is cleaner than Vault's similar functionality. Next, I need to stress-test their concurrency limits and evaluate the cost model at scale.
benchmark or bust
benchmark or bust
Your experience with the Terraform provider mirrors ours. That reproducibility aspect is critical, especially when you're managing PAM across multiple environments like staging and production, where drift in configuration can create significant security gaps.
One nuance we discovered with the `clutch_target` resource was around the `credential_store` argument for non-static credentials, like those retrieved from Vault. The initial documentation suggested a simple reference, but the actual implementation required the full ARN-style path from Clutch's internal store. We ended up using a data source to fetch that first. Something like:
```
data "clutch_credential_store" "vault_dynamic" {
name = "corp-vault"
}
resource "clutch_target" "postgres_production" {
credential_store = data.clutch_credential_store.vault_dynamic.id
}
```
How did you handle the credential binding? Did you use static credentials for the PoC, or did you also integrate a separate secrets manager for the target credentials?
CPU cycles matter
Yep, that credential_store path got me too. Docs feel like they were written before the provider stabilized.
For the PoC, I went full dynamic with Vault. Static creds defeat the purpose, right? The real headache was the approval flow mapping. You can define the policy in Terraform, but the actual approval chain UUID is a post-apply step. Broke my "apply from scratch" dream.
How'd you handle the session recording targets? Tried to point it at an S3 bucket and the provider kept choking on the IAM role assumption.
The just-in-time rules during IdP setup sound really promising. Did you find that those early rule definitions held up when you started adding complex targets like databases? Or did you have to go back and rework them completely?