Having recently completed a deployment of HashiCorp Boundary with session recording enabled for PostgreSQL targets, I wanted to document the specific configuration and architectural decisions. The official documentation provides the components, but the operational nuances—particularly around storage scaling, network egress, and the interplay between Boundary controllers and workers—warrant a detailed breakdown.
Our primary requirement was to record all administrative SSH and database (via psql) sessions to a set of internal analytical PostgreSQL databases. The core architecture consists of:
* **Boundary Controllers (3):** Running in a high-availability cluster.
* **Boundary Workers (2):** One ingress worker inside the admin VPC, one egress worker per application environment.
* **Session Recording Storage:** AWS S3, with a lifecycle policy to transition to Glacier IA after 90 days.
* **Metadata Storage:** PostgreSQL database (separate from the target databases) for Boundary's own state, including session metadata.
The critical configuration resides in the worker configuration files. Session recording is a worker-driven function. Below is the relevant excerpt from our egress worker configuration (`worker.hcl`):
```hcl
worker {
name = "egress-worker-aws-us-east-1-prod"
description = "Handles sessions for prod environment"
controllers = [
"boundary-controller-01.internal:9201",
"boundary-contiple-02.internal:9201",
"boundary-controller-03.internal:9201"
]
public_addr = "boundary-worker-prod.example.com"
# Session Recording Configuration
recording_storage_path = "s3://boundary-session-recordings/prod"
auth_storage_path = "/opt/boundary/worker/"
tags {
type = ["prod", "egress"]
}
}
# KMS configuration for encrypting the storage bucket is handled via
# AWS KMS key policy and IAM instance profile attached to the worker EC2.
```
A significant consideration is that the `recording_storage_path` is defined per worker. This allows for environment-specific buckets (e.g., `prod` vs. `staging`). All workers in a cluster must share the same `auth_storage_path` to synchronize recovery keys.
The controller configuration required no direct changes for recording, but enabling it necessitated a policy change via the Boundary Admin CLI:
```bash
boundary scopes update --id=global --session-recording-default="record-activity"
```
Key operational observations after one month of runtime:
* **Storage Costs:** Raw SSH streams are relatively small, but RDP or graphical sessions can balloon quickly. Our S3 costs increased by ~18% month-over-month, primarily from a few prolonged RDP sessions to Windows targets. Implementing a strict maximum session duration at the Boundary scope level is now recommended.
* **Network Latency:** The worker streams data directly to S3. High latency between the egress worker and the S3 endpoint can cause session lag. We placed an S3 Gateway Endpoint within the VPC to mitigate this.
* **File Management:** Sessions are stored as numbered `.json` files (metadata) and `.data` files (the actual keystrokes/bytes). Forensic analysis requires a custom tool to reconstitute the stream; the Boundary Enterprise CLI provides this, but building a simple parser for alerting on specific commands is non-trivial.
* **Worker Failure:** If a worker crashes during a session, the partial recording is still uploaded to S3. The `.json` metadata file includes an `"end_time"` and `"termination_reason"`, which are crucial for auditing incomplete sessions.
The setup is functionally robust for compliance requirements (e.g., SOX, PCI-DSS). However, for organizations seeking to perform real-time analysis or alerting on session content, this architecture necessitates a secondary processing pipeline. The recordings are not queryable within Boundary itself; they are opaque binary blobs in S3 until retrieved and decoded. A logical next step would be to trigger an AWS Lambda function upon new object creation in the S3 bucket to parse and index session events into a security information and event management (SIEM) system.