Having evaluated numerous solutions for providing secure, granular access to our monitoring infrastructure over the years, our team trialed Perimeter 81 for the last six months. The primary use case was to secure access to internal Datadog components, application backends, and Kubernetes clusters for a distributed engineering team. My review is from the perspective of an observability platform administrator who needs both security and operational simplicity.
The core strength of Perimeter 81 is its abstraction of network-level access into an identity-centric model. The integration with our existing IdP was straightforward, and the ability to define access policies based on user groups, rather than IP addresses, aligns well with a zero-trust framework. For instance, we could create a policy that allowed only members of the "observability-admins" group to reach the Datadog API endpoints and internal admin consoles, while "developers" could only access specific application staging environments. This eliminated the need for maintaining bastion hosts or complex VPN subnet rules.
However, from a performance and observability standpoint, there are notable considerations. The tunneled traffic introduces latency, which becomes measurable in high-throughput APM trace or log forwarding scenarios. While not a fault of the SASE tool itself, it's a critical architectural factor. You must account for this in your data pipeline designs. Furthermore, while Perimeter 81 provides its own connection logs, correlating these with your application-level observability data in a tool like Datadog requires manual work. There is no native integration, so you are left with a disjointed view of network access events versus application performance.
For our final architecture, we used Perimeter 81 for human user access but opted for a different model for machine-to-machine communication. Service-to-service traffic, such as between our applications and Datadog agents, remained secured via mutual TLS and network policies within our cloud environment, avoiding the overhead of routing all traffic through the SASE tunnels. The configuration for setting up a secure tunnel for a resource looked something like this in their system:
```
Resource: Internal Datadog API
Identifier: datadog-api.internal
Gateway: aws-us-east-1-gw
Access Policy: Allow "observability-admins", Deny all
Protocols: TCP/443
```
In summary, Perimeter 81 is a competent solution for managing secure human access to internal tools and environments. Its policy engine is robust. However, for an organization deeply invested in a unified observability platform, the lack of deep integration and the potential latency overhead for machine traffic are significant drawbacks. It serves best as a component of a broader strategy, not as a singular conduit for all internal traffic, especially when dealing with high-volume telemetry data.
null
That identity-centric model you described is a big shift from the old ways. We've seen similar benefits with user-group based policies in our marketing automation, where it lets us lock down access to customer data without slowing down the campaign teams.
You mentioned performance considerations with tunneled traffic. Did you notice any specific latency when accessing tools like Datadog, or was it more about the overhead of managing the tunnels themselves? We're looking at similar tools for securing our own analytics platforms, and that's a key trade-off for us.
ABT – always be testing