Security controls, encryption, and compliance for HoneyHive self-hosted deployments
HoneyHive’s self-hosted deployment model is built for regulated enterprises that require complete data sovereignty, network isolation, and auditability. This page covers the security controls enforced in self-hosted (BYOC and BYOVPC) deployments, with specific implementation details for each layer.For infrastructure details, see Platform Architecture.
Self-hosted deployments are supported on all major cloud providers (AWS, GCP, Azure) and on-premise infrastructure. For simplicity, all security controls described on this page reference the AWS implementation, which is our most common deployment target. Equivalent controls are available for other cloud providers.
Trace ingestion, evaluation, data storage, SDK endpoints
Customer’s AWS account
Key security properties:
All customer data, including PII, is processed and stored exclusively within the Data Plane. No PII or customer data leaves the customer’s account. Trace metadata and metrics are exported to the Control Plane for central reporting and alerting, but raw trace content (LLM inputs/outputs) never leaves the Data Plane.
Communication is one-way: the Data Plane initiates outbound HTTPS connections to the Control Plane. The Control Plane never initiates connections into the customer’s network.
There is no VPC peering, Transit Gateway, or cross-account IAM between the two planes. They are fully independent at the network and identity layers.
All data stored in HoneyHive is encrypted at rest using customer-managed AWS KMS keys. Each encryption scope uses a dedicated key for isolation and independent rotation.
Scope
Method
Details
Database (RDS PostgreSQL)
AES-256 via KMS
Customer-managed KMS key with automated or customer-managed rotation. Covers all metadata, project configurations, and evaluation results.
Object storage (S3)
SSE-KMS
Server-side encryption with a customer-managed KMS key. Applies to trace data, log archival, and PII storage.
Kubernetes secrets (EKS)
Envelope encryption
Dedicated KMS key encrypts the data encryption keys (DEKs) that protect secrets stored in etcd.
Analytics engine (ClickHouse)
EBS-level encryption
Underlying EBS volumes encrypted via KMS. Covers all event data, trace spans, and evaluation scores.
Terraform state
SSE-KMS
State files stored in S3 with KMS encryption. DynamoDB lock table for state locking.
Application-level
AES-256
Field-level encryption for sensitive data within the application, using KMS-managed key IDs. This is independent of storage-level encryption and provides an additional layer of protection for specific fields.
ACM-managed certificates on Application Load Balancer. All SDK and REST API traffic is encrypted.
Data Plane to Control Plane
TLS 1.2+
Outbound HTTPS only. The Data Plane validates the Control Plane’s certificate.
Inter-service (CP ↔ DP)
gRPC over TLS
NLB-terminated TLS on port 443 for gRPC communication between planes.
Database connections
TLS 1.2+
RDS enforces encrypted connections via ssl_mode.
Services across the Control Plane and Data Plane leverage TLS for encryption in transit and token-based identity protocols for authentication. Cross-plane communication is authenticated at the application layer, ensuring that only authorized services can exchange data between planes.At the application layer, project-scoped API keys provide access control for all SDK and API traffic. HoneyHive uses a flat RBAC model where API keys are unique per project, ensuring tenant isolation.
HoneyHive uses the External Secrets Operator (ESO) to bridge cloud secret managers (e.g., AWS Secrets Manager, GCP Secret Manager) into Kubernetes, eliminating static credentials from application configuration. Secrets are encrypted at rest in the cloud provider’s secret manager using KMS, and ESO syncs them into Kubernetes secrets automatically using workload identity (e.g., IRSA on AWS). No static cloud credentials exist in the cluster.
IAM Roles for Service Accounts (IRSA) via OIDC federation. Each Kubernetes service account is bound to a dedicated IAM role with least-privilege permissions. No static AWS credentials exist in the cluster.
Pod-level isolation
Every service (e.g., dp-ingestion, cp-backend) runs under its own Kubernetes service account with a scoped IAM role. Services cannot access resources assigned to other services.
EKS endpoint access
Configurable as private-only or private + public. Public access, when enabled, is restricted to known CIDRs for CI/CD pipelines.
Operator access
Zero-trust network access (e.g., Twingate, Zscaler, or customer-equivalent VPN) required to reach internal services. No persistent VPN tunnels.
EKS admin access
Admin and read-only principal ARNs with external ID validation. Break-glass bastion host available (optional), restricted to known IPs.
AWS account isolation
The Data Plane runs in a dedicated AWS account with no cross-account IAM roles to HoneyHive’s infrastructure.
SAML 2.0 SSO (Okta, Azure EntraID, Google Workspace, OneLogin), plus Google/GitHub/Microsoft SSO and email/password with MFA. SAML groups are auto-mapped to custom roles via JIT provisioning.
RBAC
Role-based access control at organization, workspace, and project levels. Custom role definitions on Enterprise plans. Dual-control access: both membership and role required.
API key scoping
API keys are issued per-project with scoped permissions.
Session re-authorization
Role or membership changes invalidate active sessions, triggering re-authorization without requiring logout.
For connecting customer applications to the Data Plane:
Method
Use Case
Direct HTTPS
When the Data Plane is deployed within the same VPC as the application being traced, services connect directly over HTTPS with application-layer security (API key authentication).
AWS PrivateLink
Customer application VPC connects to Data Plane via private endpoint (recommended for cross-VPC production workloads).
VPC Peering
Bidirectional private network access between customer and HoneyHive VPCs.
Network isolation between workloads is currently enforced at the VPC and security group level. Kubernetes NetworkPolicy resources are recommended for defense-in-depth but are not deployed by default in the current Helm charts. Customers can add NetworkPolicy resources to further restrict pod-to-pod communication within the cluster.
The platform includes OpenTelemetry-based instrumentation across all services for metrics, traces, and logs. Pre-configured alert configurations and runbooks are available on request for both Control Plane and Data Plane components.Customers can integrate their existing monitoring tools (e.g., Datadog, Splunk) alongside the built-in observability stack.
All KMS keys are customer-managed within the customer’s AWS account. HoneyHive has no access to these keys.
Key
Purpose
Rotation
EKS secrets encryption key
Envelope encryption for Kubernetes secrets stored in etcd
AWS-managed or customer-managed rotation policy
RDS encryption key
Database encryption at rest (PostgreSQL)
AWS-managed rotation
S3 encryption key
Object storage encryption for traces, logs, and PII data
Customer-managed rotation policy
Application encryption key
Field-level AES-256 encryption within services
Customer-managed rotation policy
Terraform state encryption key
State file encryption in S3
Customer-managed rotation policy
Each key is scoped to a single purpose. Key rotation does not require service downtime - AWS KMS retains previous key versions for decryption of existing data.
Scanning tools - Wiz for cloud infrastructure and container scanning, Dependabot for dependency vulnerabilities, and CodeQL for static application security testing (SAST).
Response SLAs - Critical vulnerabilities are triaged within 24 hours and patched within 7 days. High-severity vulnerabilities are patched within 30 days. See the changelog for historical patch cadence.
Patch management - EKS and RDS run on managed services with automatic security patching. Application-level patches are deployed via the standard GitOps pipeline.
Container image security - Base images are regularly updated and scanned. Images are pulled from private registries or customer-provided mirrors.
In self-hosted deployments, all customer data remains within the customer’s AWS account and region. No trace data, evaluation results, or PII leaves the Data Plane boundary.
