Module A · Slide 81–82
High Availability
Ensure your StrongDM deployment never becomes a single point of failure. Learn how to architect resilient Gateway and Relay topologies.
🔁
Gateways & Relays
Why Multiple Nodes?

In the absence of Proxy Clusters, StrongDM recommends deploying two or more Gateways / Relays to avoid a single point of failure between the user and the resource.

How Routing Works

Gateways and Relays rely on StrongDM's built-in routing functionality to automatically select the appropriate, available node when a failure occurs. No manual intervention required — the system detects and reroutes dynamically.

  • User traffic reaches one of many available Gateways
  • The selected Gateway routes onward to an available Relay
  • The Relay makes the final connection to the Resource
  • If any hop fails, the routing system selects the next available node
📎 Reference: Deploy HA Gateways with CloudFormation → strongdm.com/docs ↗
Page 1 of 8
Module A · Slide 83–84
Proxy Clusters & Scaling
Understand the minimum requirements for HA proxy clusters and when to scale nodes vertically vs. horizontally.
🏗️
Proxy Cluster Requirements
Standard Proxy Cluster
  • At least 2 proxy workers behind a load balancer
  • Load balancer ensures high availability
  • Workers handle inbound connections from clients
Bridged Proxy Cluster
  • At least 2 proxy workers behind a load balancer
  • Additionally requires 2 bridge workers
  • Bridge workers handle cross-network routing
📈
Scaling Strategy
When to Scale

StrongDM recommends scaling nodes when they experience consistent CPU utilization above 70%. Monitor your nodes proactively to avoid performance degradation before it impacts users.

⬆ Vertical Scaling

Increase the node host's CPU and/or memory specifications. Best for quick relief when a single node is overloaded but not yet worth multiplying.

↔ Horizontal Scaling

Add additional nodes in parallel, such as in an auto-scaling group. Best for sustained load growth and improved fault tolerance.

Page 2 of 8
Module B · Slide 86–88
Terraform
Use Infrastructure-as-Code to automate StrongDM deployments. StrongDM is a registered Terraform provider with templates for AWS and Azure.
🔧
Why Terraform?
Automated Infrastructure

Instead of manually creating StrongDM resources one-by-one in the Admin UI, use Terraform to quickly deploy common infrastructure configurations in a repeatable, version-controlled, auditable way.

StrongDM in the Terraform Registry

StrongDM is a registered provider in the Terraform Registry, providing usage examples and full documentation.

registry.terraform.io ↗
☁️
Quick Start Templates
Amazon Web Services

Provision Gateways, MySQL instances, SSH servers, and VPCs on AWS automatically from a single template.

Microsoft Azure

Equivalent quick-start for Azure environments, with the same simplified onboarding flow.

📎 The onboarding.tf file shows all resources the template creates. Two Gateways are created automatically for high-availability deployments — even when not immediately obvious in the template.
📄
Template File: onboarding.tf
module "strongdm_onboarding" {
  source = "./onboarding"

  # Prefix added to all resource names
  prefix = "terraform-sdm"

  # MySQL resources (~15 min)
  create_mysql = true

  # SSH resources (~5 min)
  create_ssh = true

  # Gateways (~5 min)
  create_strongdm_gateways = true

  # VPC (~5 min; false = use default VPC)
  create_vpc = true
}
Page 3 of 8
Module B · Slide 89–96
Terraform — AWS Quick Start
Walk through the five steps required to deploy StrongDM infrastructure on AWS using Terraform, from cloning to cleanup.
✅
Prerequisites
  • A StrongDM administrator account
  • A StrongDM API key with all permissions granted (generated in Admin UI)
  • Terraform v0.14.0+ installed on the host running the scripts
  • An AWS account + AWS API key with permissions to provision all intended resources (generated on AWS Dashboard)
  • Git installed with paths added to host OS environment variables
🚀
Deployment Steps
01

Clone Repository

Download the Terraform templates from StrongDM's GitHub repository.

git clone https://github.com/strongdm/terraform-sdm-onboarding.git
cd terraform-sdm-onboarding
02

Populate Variables

Edit variables.tf and add your StrongDM API credentials and AWS keys. The template uses variables (not hardcoded values) for security best practices. All values must be enclosed in quotation marks.

03

Initialize Template

Initialize the working directory and download all required providers.

terraform init
04

Execute Template

Apply the configuration. Terraform will display a plan and prompt for confirmation. Type yes to proceed. The apply action takes a few minutes to complete.

terraform apply
05

Cleanup

To avoid unnecessary cloud expenses, destroy all resources when no longer needed. There is no undo — only yes is accepted to confirm.

terraform destroy
Page 4 of 8
Module C · Slide 1–4
Introduction to Resources — Part 2
Understand what constitutes a "resource" in StrongDM and how it extends the concepts introduced in StrongDM 101.
🗄️
What Is a Resource?
Definition

A resource is any type of digital infrastructure — datasources, servers, clusters, clouds, and websites — that an organization creates to meet its operational needs.

StrongDM's Role

StrongDM proxies network traffic to these resources and regulates access to them based on StrongDM policies. It sits transparently between users and infrastructure.

📚
Learning Objectives — This Module
  • Understand how to connect to Datasources
  • Understand how to connect to non-specific resources via TCP
  • Understand how to connect to Kubernetes clusters
  • Understand what Policy-Based Action Controls (PBAC) are available for resources
📎 Resources discussed here extend the content from StrongDM 101: Introduction to Resources — Part 1. Ensure that module is complete before proceeding.
Page 5 of 8
Module C · Slide 5–16
Flow: User to Resource
Trace every step a user takes when connecting to a resource through StrongDM — from login to active session — and understand what security decisions are made at each step.
🗺️
The Four-Step Flow
Log on to
StrongDM Client
→
Get Connection
Details
→
Connect to
Resource
→
Use
Resource
User Authentication

Logging on to the StrongDM client identifies the user to the StrongDM network. User identities are associated with one or more Roles, which determine what resources the client has access to.

Identity Provider (IdP) Support

Users can log on with a native StrongDM account or via an integrated Identity Provider (IdP) such as Google. See the StrongDM 201 — Authentication module for vendor-specific details.

No Standing Access

On first login, the client shows zero resources by default. This is intentional — it aligns with the best practice of "no standing access". Users must explicitly request access to each resource they need.

Requesting Access

Users request access via the StrongDM console: Access → Request Access → Catalog. They specify a reason and duration. The request is reviewed, and once approved, the resource appears in their StrongDM client.

Resource Appearance in Client

After approval, the resource becomes visible in the StrongDM client with a local address (e.g. 127.0.0.1:10006). Users connect using any standard tool — SSH client, DB GUI, browser — pointing to that local address.

StrongDM Routing Protocol

StrongDM uses a proprietary routing protocol, hosted in the control plane, to find the best route from the client through the Gateway/Relay combination to the resource. The user never interacts with this routing layer directly.

Policy Enforcement at Connection Time

If StrongDM policies are enabled, an additional security layer evaluates whether the user is permitted to make this connection. Access is denied if it is not permitted by both access grants AND active policies.

Leased Credentials

The credentials used to log into the StrongDM client are not the credentials used to access the resource. Gateways and Relays use leased credentials mapped to the user's identity by the control plane — the user never sees or handles the underlying resource credentials.

Policy-Based Action Controls (PBAC)

StrongDM's security doesn't end at access control. With PBAC, StrongDM continues to monitor how access is used by inspecting instructions and data sent to the resource (e.g., SQL queries, SSH commands, Kubernetes kubectl calls).

Session Logging

StrongDM generates session logs for all resource connections and uploads them to the control plane. These logs are operationally required — StrongDM will only allow continued traffic to resources if previous session logs are successfully uploaded.

  • Activities, Queries, SSH, RDP, Kubernetes, Cloud, Web, Policies
  • Accessible via Logs in the Admin UI or via the API/CLI
Page 6 of 8
Module C · Slide 17–22
TCP Connections
Use the generic TCP resource type for any infrastructure that accepts TCP connections but doesn't have a dedicated StrongDM resource type.
🔌
What is a TCP Connection Resource?
Catch-All Resource Type

The TCP connection resource can be used for any resource that accepts TCP connections and isn't already covered by a more specific StrongDM resource type (SSH, RDP, MySQL, Website, etc.).

Limited Logging — by Design

Unlike specific resource types, TCP connections do not record the content of traffic. Logs only capture:

  • Who accessed the resource
  • When the access took place
  • The number of bytes sent and received
⚠️ A TCP connection can manage access to Websites — but there is already a purpose-built Website resource type that provides far greater visibility into HTTP/HTTPS traffic. Use TCP only when no specific resource type applies.
⚙️
Configuration Fields
Display Name

Name that identifies the resource in the StrongDM console. Cannot include special characters.

Server Type

Set to TCP to select the generic TCP connection type as the target.

Hostname

Used by the Gateway/Relay to connect to the server. Can be a hostname or IP address.

Port

The port the target server listens on. Default is 3389.

Port Override

Auto-generated value between 1024–59999 not used by another resource. The StrongDM client listens on this local port for outbound traffic.

Resource Tags

Key-value pairs used to identify the resource in automation workflows and policy targeting.

docs: Add a TCP connection ↗
Page 7 of 8
Assessment
Knowledge Check
Test your understanding across all three modules. Select the best answer for each question.
Quiz StrongDM 201 — Final Assessment
1. When no Proxy Clusters are in use, what does StrongDM recommend to avoid a single point of failure?
A Deploy a single large Gateway with high CPU
B Deploy two or more Gateways / Relays
C Use a single Relay behind a load balancer
D Increase StrongDM control plane resources
✓ Correct! StrongDM recommends deploying two or more Gateways/Relays so StrongDM's routing functionality can select an available node if one fails.
✗ Not quite. StrongDM recommends deploying two or more Gateways / Relays so the routing system can automatically reroute if a node fails.
2. At what CPU utilization threshold does StrongDM recommend scaling nodes?
A 50%
B 60%
C 70%
D 85%
✓ Correct! Consistent CPU utilization above 70% is the signal to scale — vertically or horizontally.
✗ The threshold is 70% consistent CPU utilization. Scale vertically (upgrade specs) or horizontally (add nodes) once this is sustained.
3. Which Terraform command deploys the infrastructure defined in the template?
A terraform plan
B terraform init
C terraform apply
D terraform deploy
✓ Correct! terraform apply executes the actions proposed in the Terraform plan and actually creates the resources.
✗ It's terraform apply. Remember: init sets up the directory, plan previews changes, apply deploys, destroy removes.
4. What happens the first time a user logs into the StrongDM client in a properly configured environment?
A All resources are immediately visible
B Resources matching the user's role are visible
C No resources are visible — consistent with "no standing access"
D An error is displayed because no gateway is connected
✓ Correct! A properly configured StrongDM environment defaults to no standing access — users see no resources until access is explicitly granted.
✗ In a proper StrongDM setup, users see no resources by default — this is the "no standing access" best practice. Access must be requested and approved.
5. What data does the TCP Connection resource type record in its logs?
A Full packet contents, source IP, and destination port
B SQL queries and response payloads
C Who accessed it, when, and bytes sent/received
D All TCP traffic content and session replays
✓ Correct! TCP connection logs are limited to who, when, and bytes — no traffic content is recorded. Use purpose-built resource types for richer logs.
✗ TCP connection logs only record who accessed the resource, when, and how many bytes were sent/received. Traffic content is never recorded.
6. What are "leased credentials" in StrongDM?
A The user's personal username and password stored in StrongDM
B Temporary AWS credentials generated by the Terraform template
C Credentials used by Gateways/Relays to connect to resources, mapped to the user's identity by the control plane
D Credentials the user must enter manually each time they connect
✓ Correct! Leased credentials are used by the Gateway or Relay to authenticate to the resource. The user never sees them — the control plane maps them to the user's identity.
✗ Leased credentials are what Gateways/Relays use to actually connect to resources. The StrongDM control plane maps these to the user's identity. The user's login credentials are separate.
—
Page 8 of 8