Logs
Last modified on September 18, 2024
StrongDM provides several options for configuring logs within your organization, allowing for a variety of usability and security use cases to be met. StrongDM logs are a core part of the platform, as they provide an audit trail for activities within the platform and for queries made against resources. For that reason, it’s important to configure logs correctly for your organization.
This guide walks you through the following aspects of interacting with StrongDM logs:
- Learn what is available in StrongDM logs.
- Learn about available methods to consume logs, and then configure log destination(s).
- Learn about log encryption options, and then configure log encryption settings.
- If you are retaining logs on your nodes (gateways and relays), configure local storage settings.
- Learn how to view the logs that have been recorded for your organization.
- Lastly, learn about any further details your organization requires, such as the StrongDM log retention policy, enabling the Log Stream service, or exporting your logs to other logging services.
What is Available in StrongDM Logs?
To begin, there are four basic kinds of information that StrongDM generates logs for:
- Activities: These logs entries capture events that occur within the StrongDM product (that is, the Admin UI and the CLI); actions are primarily administrative (for example, users changing each others’ permission levels, adding or editing infrastructure, changing settings, and so forth).
- Queries: These logs entries record access to any resources and the commands run on them.When an Enterprise organization has Policies enabled, query logs usually include an
authz
object that contains information about the policy evaluation for the query, as well. For more information, see the Policy Logs section. - Sessions/Replay: These log entries allow for the playback of sessions that are captured whenever an SSH, Kubernetes, or RDP session is completed.
- Error: These are traditional error logs that record state and errors and are output to a file called
sdm.log
on clients and on node (gateway or relay) servers. These logs are output on each client and node as a natural consequence of operation and are not the subject of the settings discussed below.If you need help interpreting error logs and troubleshooting your client or node error logs, visit the Help Center.
For more details on specific log event types that are available either from node logs or from the Log Stream output, see the Log Event References section.
Configure Log Destination Settings
When choosing how to manage your StrongDM logs, the first decision to make is, in general, where you want log information to be available. You can consume logs:
- Manually in the Admin UI under Logs
- Manually at the CLI using the sdm audit command tree
- Manually by inspecting gateway and relay log files
- Pipe logs directly to an S3 bucket via the Enterprise feature Log Stream (which is the only way to directly send activities and policy evaluation data from the StrongDM control plane to an outside service).
- Pipe logs from gateways and relays to another service via the variety of manually configured methods (Stdout, TCP, Socket, Syslog)If you wish to collect and/or visualize logs in another service, remember that piping node (gateway or relay) logs directly to those services is possible, but does not include Activities or added information for policy evaluations that occurred within the StrongDM control plane. To achieve this, Log Stream is necessary.
You can choose to enable or disable any combination of these options. That is, you can enable StrongDM to retain logs, enable Log Stream, and also store logs on your gateways and relays, or any subset of those options. Choose your log destination settings suggestions based on how you wish to consume logs.
Store with StrongDM?
If you wish for StrongDM to retain your logs, enable this option. This option must be enabled to view node logs in the Admin UI, to view node (gateway or relay) logs from the StrongDM CLI commands, to view replays, and to pipe logs via the Log Stream feature.
This option does not need to be enabled if you only wish to manually view node logs in your server log files or pipe them to another service from your servers.
Retain SSH, RDP, and Kubernetes replay data sent to StrongDM**
If you select Yes, replays are stored and replayable.
If you select No, new replays are not stored remotely, replay attempts are disabled, and only session metadata (that is, user, resource, and total replay time) is stored. No replay data is stored.
If you attempt to replay a session via the CLI or SDKs while this option is set to No, then all recorded session replays present the session metadata, but no actual replay data can be queried. This behavior persists even if the option is set to No and then is later set to Yes, because StrongDM doesn’t retain replay sessions that are recorded when retention is disabled.
Note that if you set this option to No and then set it to Yes again, you are able to attempt to replay those sessions, but because there is no data to render, the replay shows a black screen for the total duration of the session.
Log locally on relays and gateways?
This setting indicates whether you wish to save log files locally on your gateways and relays.
Decide on log destination configuration based on use case
Use case | Store with StrongDM | Retain replay data | Log locally |
---|---|---|---|
| Enable | Enable | Disable |
| Enable | Enable | Enable |
| Enable | Enable | Enable |
| Disable | Disable | Enable |
| Disable | Disable | Enable |
| Enable | Enable | Disable |
| Enable | Enable | Enable |
Example scenario
Alice logs in to StrongDM Desktop on her laptop, connects to postgres-01
server through StrongDM, and then sends a query.
- An Activity is logged when Alice signs in to her local client, and a local error log is generated if any problems occur.
- If the organization has policies enabled and statements that would be triggered by this query, any context-based evaluations leave Activities with attached policy evaluation information.
- As Alice’s traffic passes through her organization’s network of nodes (gateways and relays), the last node in the network handles logging in the following ways:
- If the organization has configured settings to allow nodes to log locally, the node makes record of her query. If her query triggered evaluation by any policies that assess specific Postgres actions (PBAC) data for that evaluation is attached to the query log. These logs are available to be read on the node, or piped out to outside services via TCP or other methods.
- If any problems occur, errors are logged locally on the node.
- If the organization has configured settings to allow StrongDM to retain logs, the node sends the log data to StrongDM, where it is now available via the Admin UI and CLI. It will also be streamed to your external storage location if you have configured Log Stream.
Configure Log Encryption Settings
Once you have decided where your logs should be stored, you should consider how they are secured: Through remote encryption or local encryption.
Remote encryption
If you are storing logs with StrongDM, you can allow StrongDM to encrypt the logs for you, or you can opt for Public key and add the public key from a key pair that you generate and have StrongDM use that. That is, the system uses your generated key to encrypt logs, but only you can decrypt them. This means that if StrongDM stores these logs, it can only send them back to you still encrypted, and they are not viewable in the Admin UI.
Local encryption
By default, logging is enabled only to StrongDM servers. By turning on gateway or relay logging, you have logs located on the individual gateways and relays for your organizations, if any. Enabling public key encryption for (gateway or relay) logging encrypts these logs so they cannot be viewed without the private key.
To turn on relay encryption, ensure that Log locally on relays? is set to Yes and Local encryption? is set to Public key.
When you enable these settings, you are presented with a text box, allowing you to paste in your public key. If you have not already created one, do so now (see the Generate a Key Pair section if needed). Copy and paste the entire contents of the key into the text box, including the -----BEGIN PUBLIC KEY-----
and -----END PUBLIC KEY-----
lines. If you have already set up public key encryption on StrongDM (Remote encryption), this box already contains a public key. Remote and node encryption use the same key.
Finally, click on the Save button. You should receive a confirmation notice before the changes take effect.
Configure Local Storage Settings
If you are storing logs locally on gateways/relays and/or are piping logs elsewhere from the gateways/relays, you should adjust the following settings to meet your needs:
Local storage?
This field needs to be configured if you are doing anything more than storing local log files. If you would like to send the logs to another program, service, or server, you may choose from the options Stdout, TCP, Socket, or Syslog, and configure your integration as you see fit. This setting does not affect the error logs of the clients or gateways/relays, which are in their local sdm.log
file. StrongDM neither provides nor enables rotation of the sdm.log
file, so if you wish to rotate this log, you must set up and manage that process yourself. The primary purpose of the error logs is to troubleshoot in real time, so this may not be necessary in many cases.
- Log Files: If you choose the “Log files” option for Local storage? the relay or gateway writes logs to
<SDM_RELAY_HOME_DIRECTORY>/.sdm/logs/
. This log rotates if the current log file grows to 100 MB. - Stdout: If you choose Stdout, the relay or gateway logs to
STDOUT
, and you need to ensure that you have the relay or gateway process wrapped in a script that captures that output to redirect to a destination of your choosing. - TCP: The TCP option lets you specify a host/port combination to send logs. You can use this option to send directly to a log aggregator or security information and event management (SIEM) solution that can accept syslog-style log delivery.
- Socket: The Socket option sends to a specified local socket. This option is primarily useful for log aggregators that put agents on individual hosts and expect logs to be delivered via socket.
- Syslog: The Syslog option lets you specify the host/port combination of a syslog server to send logs using the syslog protocol. You can use this option to send logs directly to a syslog aggregator or a SIEM solution.
Local format
If you intend to store logs locally on your nodes (gateways and relays) you need to select a format for the log files. You can choose JSON or CSV, based on the tool or service you intend to use to process or read the logs.
View Logs
You can view logs in several ways.
Admin UI
When StrongDM logging is enabled, the Admin UI contains logs with a limited date range for Activities, Queries, Replays, Web, and Policies. If it is disabled, Activities and some Policy logs are the only items present.
For more information on viewing logs with the Admin UI, see the View Logs with the Admin UI section.
CLI
The CLI allows access to logs for the last 13 months (Enterprise customers) for all of the same event types. For more information on viewing logs with the CLI, see the View Logs with the CLI section.
Node log files
Each of your nodes (gateways and relays) generates local log files, if local logging is enabled for your organization. These files can be directly viewed as necessary. For more information on viewing node files, see the Node Log Files section.
Policy logs
For Enterprise organizations, logs of all queries that included policy evaluations that occur within the StrongDM control plane are available in the Admin UI or via Log Stream. Additionally, if your log encryption and storage settings allow StrongDM to retain logs from your nodes (gateways and relays), policy evaluations that happen at the node level, such as for PBAC events, are also be included.
start
events in node logs or query
events from Log Stream, events that include the authz
field are events that triggered policy evaluation. This field is a JSON payload of all data pertaining to the policy evaluation. A reference of the schema of the authz
field and the information that is stored in it can be found in the Policy Info in Logs section.Admin UI Policy Monitor
Each action that is evaluated by policies is logged in the Policy Monitor list that can be found in the Admin UI at Logs > Policies.
Each entry has the following fields:
- Result: Either allow or deny; the result of the policy assessment for the action(s)
- Target: Entity targeted by the action
- Actions: Specific action the user attempted to perform
- User: Name and email of the StrongDM user who performed the action
- Timestamp: Date and time that the policy was triggered for the action
You can click on any item in the list to open the details view for that item.
Log Retention
This section provides information about our log retention policy. StrongDM stores logs (such as queries, replays, and so forth) for a period of 13 months. If the Enterprise bundle is enabled for your organization, you can view logs for any time in the last 13 months. If the Enterprise bundle is not enabled, you can view logs for the last 30 days by default.
The Admin UI shows logs when you select StrongDM as the storage destination, or when you choose to store logs with StrongDM and with your gateway servers locally or with third parties. Logs are visible in the Admin UI for a particular period of time depending on the type of record. For example, some logs may show 12 months of entries, while certain kinds of queries may show the last day or the last 100 queries.
You can use the CLI to download the logs, search for specific events beyond the time range shown in the Admin UI, and get other audit information.
Log Stream
If the Enterprise bundle is enabled for your organization, you can use Log Stream to stream your StrongDM audit logs to a third-party object storage service, such as Amazon S3.
For configuration information and examples of streamed logs, please see Log Stream.
Configure Logging Services
For examples on how to configure logging with various services, see our guides:
- Logging Scenario - Send Local Logs to CloudWatch
- Logging Scenario - Send Local Logs to S3
- Logging Scenario - Send Local Logs to Filebeat
- Logging Scenario - Send Local Logs to Graylog
- Logging Scenario - Logging with Rsyslog
- Logging Scenario - Send Local Logs to a Splunk Indexer
Conclusions
In this guide, you have considered:
- Where you want logs to be stored
- How you want to consume logs
- How you want logs to be secured
- How you want logs to be stored and in what format
- How to view logs
- What the retention policy is for logs
- How to learn more about Log Stream or other log export scenarios
You can find resources and information about the following StrongDM topics in this section: