StrongDM / 201 / Introduction

StrongDM 201
Logs

This module covers how StrongDM generates, stores, streams, and retains logs — and the full flow a user takes to connect to a resource.

📋
What You'll Learn

By the end of this guide, you'll be able to explain the user-to-resource connection flow, identify the different types of logs StrongDM generates, configure log storage destinations, set up log streaming to external services, and understand log retention policies.

🔗
User → Resource

The connection flow and how each step is secured.

📂
Log Types

Activities, Queries, Sessions, and Replays.

🗄️
Log Storage

Remote, local, and encrypted storage options.

Prerequisites: Basic familiarity with StrongDM's architecture — clients, gateways, relays, and the control plane. See SDM 101 if needed.

User → Resource
Connection Flow

When a user connects to a resource via StrongDM, four key steps take place. Click each step to explore what happens.

01
Log on to StrongDM Client
02
Get Connection Details
03
Connect to Resource
04
Use Resource

Step 1 — Logging on to the StrongDM Client

Logging on identifies the user to the StrongDM network. User identities are tied to one or more Roles, which determine which resources the client can access. Authentication can use native StrongDM credentials or an Identity Provider (IdP) like Google or Okta. On first login, a properly configured environment shows zero resources — consistent with zero-standing privileges best practices.

Step 2 — Getting Connection Details

Users request access via Access → Request Access → Catalog in the StrongDM console. Once an approver grants access, the resource appears in the client with a local address (e.g., 127.0.0.1:10006). Users can then use any native tool to connect using that address.

Step 3 — Connecting to the Resource

StrongDM uses a proprietary routing protocol hosted in the control plane to find the optimal route through the Gateway/Relay network to the resource. Roles gate which resources are reachable; if Policies are enabled, they add a second security layer regulating what the user can do. The Gateway or Relay makes the actual connection using leased credentials or identity aliases — the user never sees the resource's real credentials.

Step 4 — Using the Resource

StrongDM continues monitoring after access is granted. Session logs are generated by the node connecting directly to the resource and uploaded to the control plane. Policy-Based Action Controls (PBAC) inspect every instruction sent to the resource in real time. Logs must be delivered successfully — this is essential to StrongDM operations.

Gateway ↔ Relay ↔ Control Plane

📡
What the Gateway & Relay Do

Both the Gateway and Relay constantly query the control plane via GRPC for information about access permissions and valid nodes. When a user makes a request, traffic flows through the Gateway to the Relay (if present) and then to the resource. The node that connects directly with the resource is responsible for sending session logs back to the control plane.

Log Types

StrongDM generates three primary log categories. Click each to see details.

Activities

Admin UI and CLI actions — settings changes, approvals, infrastructure additions.

🔍

Queries

Actual queries and actions executed by users against resources.

🎬

Sessions / Replay

Recorded playback of full sessions for supported resource types. Stored as video files.

Activities Log — Detail

Captured in the Admin UI under Logs → Activities. These record actions performed on StrongDM itself — not against resources. Examples include: changing security settings, approving access requests, adding or removing resources, and modifying roles.

Queries Log — Detail

Found under Logs → Queries. These capture the actual database queries, SSH commands, API calls, and other actions users execute against resources. Essential for audit and compliance trails.

Sessions / Replay — Detail

Session replay is available for the following resource types under Logs → SSH / RDP / Kubernetes:

SSH RDP Kubernetes Cloud Web

Sessions are stored as video recordings and include metadata: date, target, StrongDM user, authentication method, duration, and session ID.

Note: Error logs record errors across the StrongDM network. These are covered in detail in the StrongDM 302 — Troubleshooting module.

Log Storage

StrongDM can store query logs in two locations. At least one must always be enabled. Click each node to expand its options.

Rule: Either Store with StrongDM or Log locally on Node must be enabled at all times. Disabling both produces an error.
☁️ Store with StrongDM DEFAULT ON
Remote Encryption

StrongDM (default): StrongDM manages encryption (rotated hourly) and can display logs in the Admin UI.
Public key: You generate and own the key. StrongDM can only encrypt — it cannot decrypt, so logs are hidden from the Admin UI. Use the SDM CLI to view.

Retain Replay Data

Enabled by default when storing with StrongDM. Retains video recordings for SSH, RDP, and Kubernetes sessions. Disabling this also disables all future replays.

Turning This Off

Logs are no longer stored centrally. They won't be visible in the Admin UI or CLI. Replays are disabled. Local node logging becomes required.

🖥️ Store on Node (Gateway / Relay) OFF BY DEFAULT
Local Encryption

None (default): No encryption applied locally.
Public key: You own the keys. The control plane cannot decrypt. You must use your private key to read logs.

Local Storage Options

Stdout (default): Standard output of the node host OS. Requires script wrapping to capture.
Log files: Stored at ~/.sdm/logs.
TCP / Socket / Syslog: Stream to external infrastructure.

Local Format

Choose between CSV (default) or JSON. Node logs do not appear in the Admin UI — you manage your own collection, rotation, and analysis infrastructure.

Common Use Cases

Use Case Store w/ SDM Retain Replay Log on Node
Audit via Admin UI or CLI only Enable Enable Disable
Admin UI/CLI + node log files Enable Enable Enable
Admin UI/CLI + pipe to Syslog/TCP Enable Enable Enable
Node logs only (no StrongDM storage) Disable Disable Enable
Admin UI + S3 bucket via Log Stream Enable Enable Disable
All three: Admin UI + Node + S3 stream Enable Enable Enable

Log Streaming

Stream your StrongDM audit logs directly to third-party object storage for SIEM ingestion and long-term compliance.

📤
What is Log Stream?

Log Stream is the only way to directly send activities and policy evaluation data from the StrongDM control plane to an external service. It must be configured with an active "Store with StrongDM" setting — you cannot stream logs that aren't stored centrally first.

🟠
Amazon S3
🔵
Google Cloud Storage
🔷
Azure Blob Storage
SIEM Integration: Streaming logs to S3 (or equivalent) allows security information and event management tools like Splunk, Datadog, or CloudWatch to ingest activity, query, and session data for real-time security monitoring and compliance visibility.
⚙️
Configuration (Amazon S3 example)

In Settings → Security → Log Encryption & Storage: enable Log Stream, choose your provider, enter region, bucket name, and optional key prefix. Use the Test button to verify connectivity before saving.

Reference Links

Log Retention

How long does StrongDM keep logs, and how does your licensing affect visibility?

13

Months of Total Storage

StrongDM retains all logs for 13 months. After this period, logs are permanently deleted. Visibility in the Admin UI depends on your licensing tier.

13
months visible

Enterprise Bundle

All 13 months of stored logs are accessible directly through the Admin UI.

30
days visible

Standard License

Only the most recent 30 days of logs are visible in the Admin UI. Full history requires the CLI.

CLI Access: The StrongDM CLI can retrieve all available logs regardless of tier — including logs that fall outside the Admin UI's visibility window.

Reference Links

Knowledge Check

Test your understanding of the Logs module. Select the best answer for each question.

// KNOWLEDGE_CHECK — 6 QUESTIONS

1. What happens to a new user's StrongDM client when they first log in — and why?

A
All available resources are shown immediately for convenience.
B
No resources appear — consistent with zero-standing privileges best practices.
C
Resources assigned to the user's department are shown automatically.
D
An error is shown because the gateway is not reachable yet.

2. Which log type captures recordings of user sessions for SSH, RDP, and Kubernetes?

A
Activities
B
Queries
C
Sessions / Replay
D
Error Logs

3. If you choose "Public key" for remote encryption in StrongDM, what is the consequence?

A
Logs are no longer stored at all.
B
StrongDM can decrypt logs but the Admin UI is disabled.
C
StrongDM cannot decrypt the logs, so they cannot be displayed in the Admin UI.
D
Logs are automatically streamed to S3.

4. Which statement about "Store on Node" (local logging) is TRUE?

A
It is enabled by default.
B
Node logs automatically appear in the StrongDM Admin UI.
C
Node administrators must set up their own infrastructure to collect and rotate logs.
D
It can only be used when "Store with StrongDM" is disabled.

5. Log Stream can send data from StrongDM directly to which types of external storage?

A
Only Amazon S3
B
Amazon S3, Google Cloud Storage, and Azure Blob Storage
C
Any TCP endpoint
D
Syslog servers only

6. A team without the Enterprise bundle needs logs older than 30 days. What's their best option?

A
They cannot access those logs at all.
B
They must purchase an Enterprise upgrade before accessing any historical data.
C
Use the StrongDM CLI, which can access all available logs regardless of Admin UI limits.
D
Contact StrongDM support to export a CSV of historical logs.

Module Complete