Logs

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:

1. Learn what is available in StrongDM logs.
2. Learn about available methods to consume logs, and then configure log destination(s).
3. Learn about log encryption options, and then configure log encryption settings.
4. If you are retaining logs on your nodes (gateways and relays), configure local storage settings.
5. Learn how to view the logs that have been recorded for your organization.
6. 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? #

You may prefer that StrongDM store and manage your logs (or send them directly to the storage destination via Log Stream). This allows you to avoid setting up your own infrastructure to collect/ingest, rotate, and analyze logs. You can store your logs with StrongDM instead of or in addition to storing them locally on nodes.

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.

Log locally on relays and gateways? #

This setting indicates whether you wish to save log files locally on your nodes (gateways and relays). Storing your logs locally on nodes does not guarantee any persistence. If your nodes are created and destroyed with automation, or have limited storage space, careful consideration of how to store, rotate, and extract log files may be required to ensure the nodes do not run out of local storage space or that necessary logs are not lost.

If you do not wish to set up your own systems for managing logs, you can enable StrongDM to store them or pipe them to you via Log Stream.

Decide on log destination configuration based on use case #

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 the Enterprise plan is enabled for your organization and StrongDM logging is allowed, 13 months of logs are able to be viewed in the Admin UI. When the Enterprise plan is not enabled, 30 days of logs are available in the Admin UI.

If StrongDM logging is disabled altogether, logs from nodes will no longer be available in the Admin UI at all. In this case, only Activities (administrative and configuration logs) and some policy evaluation information are able to be viewed.

For more information on viewing logs with the Admin UI, see the View Logs with the Admin UI section.

CLI #

When the Enterprise plan is enabled for your organization and StrongDM logging is allowed, 13 months of logs are able to be viewed from the CLI. When the Enterprise plan is not enabled, 30 days of logs are available in the CLI.

If StrongDM logging is disabled altogether, logs from nodes will no longer be available from the CLI at all. In this case, only Activities (administrative and configuration logs) and some policy evaluation information are able to be viewed.

CLI commands can also help with some parts of viewing the raw log files locally on nodes, such as with replays.

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 organizations with the Enterprise plan enabled, logs of all queries that include 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 included.

Each action that is evaluated by policies is logged 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)
• Date: Date and time that the policy was triggered for the action
• Policies: Policy or policies that affected the action
• Actions: Specific action the user attempted to perform
• Resources: Name of the resource(s) on which the user attempted the action
• Principal: Name and email of the StrongDM user who performed the action

You can click on any policy or resource in the list to view more information for that item.

Secrets logs #

Logs for Secrets Management can be found in the Admin UI at Logs > Secrets. The Secrets logs record all user activity related to rotation, validation, and retrieval operations performed on managed secrets.

Each entry has the following fields:

• Date: Date of activity
• Operation: Type of operation (for example, read, ttl_rotate, or validate)
• User: Name of user or “system” for automated/scheduled rotations
• Managed Secret: Name of managed secret
• Secret Engine: Name of secret engine

You can filter by the account name (user or service account), managed secret name, secret engine name, or the date(s) when the operation on the managed secret was performed.

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 plan is enabled for your organization, you can view logs for any time in the last 13 months. If the Enterprise plan 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 plan 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:

• Generate a Key Pair
• Node Log Files
• Log Event References
• Log Scenarios
• Log Stream
• View Logs from the Admin UI
• View Logs from the CLI