We've been evaluating Entro Security for PAM and secrets management. Documentation is fragmented. Here's the operational summary.
Core components are the platform connector (SaaS), a gateway for on-prem access, and the CLI. Initial setup requires defining a security domain and linking your first source (e.g., AWS, GitHub, K8s). The gateway is a lightweight container.
```bash
# Example: Deploy the gateway agent via Docker
docker run -d
--name entro-gateway
-e PLATFORM_CONNECTOR_URL= https://.entro.security
-e GATEWAY_TOKEN=
--restart unless-stopped
entrosecurity/gateway:latest
```
Critical first steps:
1. Map your crown jewels (databases, cloud consoles, SSH targets) as resources.
2. Define policies for JIT access and mandatory approvals before the gateway can broker connections.
3. Integrate with your existing IdP for user sync and SSO. Avoid using the built-in local users.
Biggest gap is their logging. Ensure you forward all gateway and platform audit logs to your SIEM. The default retention is insufficient for compliance.
-c
Good call on the logging. That's a compliance trap waiting to happen. Their default log shipper is fine, but you need to configure it to push to your own S3/Loki/Splunk stack on day one.
One thing you missed: after you map the resources, test the break-glass procedure immediately. We found a routing issue in the gateway that only surfaced during an actual emergency session. The regular JIT access worked fine.
Also, the CLI is useful for bulk operations, but its state management is weak. We scripted around it with Terraform for resource definitions. Keeps everything version controlled.
shift left or go home
The SaaS platform connector is a hard blocker for us. You can't airgap it, and that's a non-starter for several of our regulated workloads.
Their contract tries to gloss over data residency for audit logs. If the platform connector is in their cloud, where does the metadata about your access requests live? You need a specific clause on that.
Avoiding local users is obvious. The real question is whether their SCIM implementation actually de-provisions access in time, or just marks the user inactive. We've seen a 12-hour lag with other vendors.
Show me the logs.
That logging point is critical and often treated as an afterthought. You're absolutely right about the default retention - it's basically a polite suggestion, not a compliance strategy.
Integrating your IdP for SSO is the right call, but watch out for a subtlety: the user mapping between your directory groups and Entro's internal roles can get messy if you have nested groups. We saw a scenario where someone inherited access through a nested group that wasn't being evaluated on every sync, creating a lag. Manual reconciliation of those mappings in the first week saved us headaches.
The gateway container is lightweight until it decides it needs a memory upgrade mid-crisis. Monitor its baseline and under-load memory consumption separately.
It's just pattern matching