Session recording
For reasons similar to Audit Logs, an essential principle of securing access to sensitive resources is creating a record of users' access and actions over remote sessions. In this context, recordings of remote access are often necessary.
Many organizations require the ability to record and playback sessions as an auditing capability for compliance and threat management.
In Boundary, a session represents a set of connections between a user and a host from a target. A session begins when an authorized user requests access to a target and ends when the access is terminated.
When you enable session recording on a target, any user session that connects to the target is automatically recorded. An administrator can later view the recordings to investigate security issues, review system activity, or perform regular assessments of security policies and procedures.
Workers
Boundary workers perform the recording function. Recording data does not pass through the control plane.
The worker stores the session recording on the local disk during the recording phase and then moves it to the external object store when the session has terminated. Boundary stores recordings in the BSR (Boundary Session Recording) format. During session establishment, the control plane passes any credentials needed to access the external object store to the worker performing the recording. See storage for more information on considerations and provider options.
For targets configured with multi-hop workers, the worker configured to access the external object store records the session. If no worker can access the storage backend, the session is terminated, and an error is returned.
HCP Boundary
Self-managed workers are required to enable session recording with HCP Boundary.
Recorded sessions
Allowed users can view all recorded sessions through a Boundary’s administrative web portal.
Please see the tutorial showcasing how to enable session recording with Terraform, AWS and Vault
Storage Considerations
Before enabling the session recording, one or more storage buckets in Boundary must be created and associated with the external object storage. Organizations must check the considerations for both local storage and external object storage to determine which will meet their requirements.
Local storage
- The number of concurrent sessions that will be recorded on that worker.
- Available disk space is defined by
recording_storage_minimum_available_capacity - If organizations don’t configure the minimum available storage capacity, Boundary uses the default value of 500MiB.
Refer to the following example configuration to configure workers for session recording storage:
worker {
auth_storage_path = "boundarydemo-worker-1"
initial_upstreams = ["10.0.0.1"]
recording_storage_path = "localstoragedirectory"
recording_storage_minimum_available_capacity = "500MB"
}
If a worker is in an unhealthy local storage state, Boundary does not allow new session recordings or session recording playback until the worker is in an available local storage state.
Organizations can check the storage state determined by recording_storage_minimum_available_capacity:
- Available
- Low storage
- Critically low storage
- Out of storage
- Not configured
- Unknown
External object storage
The retention period is how long a BSR will be retained in the external storage and from the actual size of the recording data perspective, at a minimum, a session recording for a session with one connection requires 8KB of space for BSR keys, checksums, and metadata.
Estimating how much storage is required to allocate to workers and the external storage provider for recordings depends on user activity. You need to consider the number of concurrent sessions that will be recorded on that worker.
Storage providers
Organizations must associate the Boundary storage bucket with an Amazon S3 or MinIO storage.
Amazon S3
- Contains the bucket name, region, and optional prefix, as well as any credentials needed to access the bucket.
- Can use static or dynamic credentials. Organizations can configure static credentials using an access key and secret key or dynamic credentials using the AWS AssumeRole API. Here is an example IAM Role policy that can be referenced.
{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"s3:PutObject",
"s3:GetObject",
"s3:GetObjectAttributes",
"s3:DeleteObject",
"s3:ListBucket"
],
"Effect": "Allow",
"Resource": "arn:aws:s3:::session_recording_storage\*",
"Resource": "arn:aws:s3:::session_recording_storage/foo/bar/zoo/*"
},
{
"Action": [
"iam:DeleteAccessKey",
"iam:GetUser",
"iam:CreateAccessKey"
],
"Effect": "Allow",
"Resource": "arn:aws:iam::123456789012:user/JohnDoe"
}
]
}
MinIO
- Organizations must provide service account access keys when configuring a Boundary storage bucket.
- It must be configured with R/W access. If you use a restricted IAM user policy, the following policy actions must be allowed at a minimum.
{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"s3:PutObject",
"s3:GetObject",
"s3:GetObjectAttributes",
"s3:DeleteObject"
],
"Effect": "Allow",
"Resource": "arn:aws:s3:::test-session-recording-bucket/*"
},
{
"Action": "s3:ListBucket",
"Effect": "Allow",
"Resource": "arn:aws:s3:::test-session-recording-bucket"
}
]
}
Storage buckets
A resource known as a storage bucket is used to store the session recordings. The storage bucket represents a location in an external object storage. A storage bucket's name is optional, but it must be unique if you define one. Storage buckets can be associated with zero to many targets.
Organizations must configure workers for local storage and a compatible S3 storage endpoint to create a storage bucket in Boundary. Follow the Create a storage bucket procedure for detailed configuration steps.
For Amazon S3, the required fields for creating a storage bucket depend on whether you configured the static or dynamic credentials. Although credentials are stored encrypted in Boundary, by default the AWS plugin attempts to rotate the credentials Organizations provide. The given credentials are used to create a new credential, and the original credential is revoked. After rotation, only Boundary knows the client secret the plugin uses. Refer to the required field as below
- Common
- Worker filter
- Disable credential rotation
- Static
- Access key ID
- Secret access key
- Dynamic
- Role ARN
- Role external ID
- Role session name
- Role tags
Lifecycle
Boundary provides storage policies to manage the lifecycle of the stored recordings, allowing administrators to set retention and auto-deletion dates. This helps ensure that recordings are available and accessible for the desired retention period, ensuring organizations can meet regulatory requirements like HIPAA, SOC 2, etc. Auto-deletion helps to reduce management and storage costs by automatically deleting recordings at the designated time and date.
Storage policies
Boundary storage policies play a crucial role in enforcing compliance with specific laws or regulations. It is important to note that the system does not support an undo action. Therefore, updating the storage policy of a session recording can have immediate and possibly unexpected results, such as the immediate deletion of session recordings.
Retention
Organizations should configure Boundary’s retention period in accordance with any regulatory requirement minimums, e.g. SOC 2 at 7 years. Generally, it is good practice to set retention periods in alignment to your organizational policies, with considerations of storage costs.
Scope
A storage policy exists in either the global scope or an org scope. Storage policies created in the global scope can be associated with any org scope. However, a storage policy created in an org scope can only be associated with that org scope. Any storage policies associated with an org scope are deleted when you delete the org.
Organizations should start with a global-scoped storage policy unless an org scope has specific requirements.