An interactive training guide covering Policy-Based Action Controls, Cedar policy syntax, access workflows, and zero-standing privilege best practices.
About Policies
Policy Editor
Cedar Language
PBAC & Actions
Access Workflows
Standing Access
◈Explain how PBAC is used in StrongDM
◈Describe how policies are structured in Cedar
◈Demonstrate granting and revoking resource access
◈Explain request and approval workflows
◈Define standing access and zero-standing privileges
◈Understand the role of posture visibility tools
Module 1.1 — Policies
User → Resource Flow
Every connection through StrongDM follows a defined sequence. Understanding this flow is the foundation for understanding how policies fit in.
4 steps
2 security layers
Click steps to explore
The Connection Sequence
When a user connects to a resource via the StrongDM network, the following four steps occur. Click each step to learn more.
💡 Click any step to reveal details
Step 01
Log on to the StrongDM client
→
Step 02
Get connection details from client
→
Step 03
Connect to resource
→
Step 04
Use resource
Step 1 — Logon & Identification. Logging on identifies the user to the StrongDM network. User identities are associated with one or more Roles, which determine which resources the client can see. Users can authenticate with a native StrongDM account or via an Identity Provider (IdP) such as Google. In a properly configured environment, new users see zero resources by default — consistent with zero-standing privilege best practices.
Step 2 — Get Connection Details. After an access request is submitted and approved, the resource appears in the StrongDM client. Users connect via a local loopback address and a port override specific to each resource (not the resource's default port). The StrongDM client acts as a local proxy.
Step 3 — Connect to Resource. Roles define which resources a user can access. If policies are enabled, an additional layer checks whether the connection is permitted. StrongDM uses a proprietary routing protocol to find the best path from the client → Gateway/Relay → Resource. The Gateway or Relay uses leased credentials or identity aliases — not the user's StrongDM credentials — to connect.
Step 4 — Use Resource. Once connected, StrongDM continues monitoring via Policy-Based Action Controls (PBAC) — inspecting instructions and data sent to the resource. Session logs are generated, resource-specific (SSH, RDP, Kubernetes, etc.), and uploaded to the control plane. StrongDM will only allow continued traffic to resources whose previous logs are properly uploaded.
Two Security Layers
StrongDM applies security at two distinct points in the flow.
🔐 Layer 1 — Roles & Access Grants
Roles determine which resources a user can see in their client. Without a role grant, the resource is invisible. This is the first gate — controlling who has access.
🛡️ Layer 2 — Policies (PBAC)
When policies are enabled, access is denied unless both an access grant and a policy permit it. Policies regulate what users can do, when, and from where — beyond just identity.
ℹWhen policies are enabled, StrongDM implements implicit deny behavior: resources are inaccessible unless explicitly permitted by a policy. As of the time of writing, this is enabled by default on all new StrongDM tenants.
⚠Policies extend beyond IAM (Who) by also addressing What (actions on resources), When (time and IP constraints), and Where (device/context trust level).
Page 1 of 8
Module 1.2 — Policies
Policy Creation
Policies are created in the Policy Library and edited using the built-in Policy Editor, which supports both a visual builder and direct Cedar syntax.
Creation Process
Three steps to get a working policy in place.
1
Create the Policy
In the StrongDM console, navigate to the Policy Library. Click + Add Policy, give it a name, and optionally a description. Click Save. The policy is now an empty container.
2
Open the Policy
From the Policy Library list, click Details next to the policy you created to open it in the Policy Editor view.
3
Write Statements & Save
Use the Policy Editor to enter statements — either via the visual builder controls or by typing Cedar syntax directly. Click Save before navigating away or injected statements will be lost.
The Policy Editor
The editor has two main areas that work together.
✏️ Editing Area
Displays the Cedar policy statements saved to a policy. You can type Cedar syntax manually here. Changes persist only after clicking Save.
🧱 Builder Controls
A visual form-based interface with fields for Access, Who, What, When, and With. Click Inject policy statement to push the built statement into the editing area. The builder adds new statements — it does not edit existing ones.
⚠Important: The Inject policy statement control only inserts new statements. To edit an existing statement, you must modify it directly in the editing area. Writing manually requires familiarity with Cedar — use the builder controls if you're new to the language.
Builder Controls Reference
Control
What it defines
Example values
Access
Effect — permit or forbid
PermitForbid
Who
Principal — the user or role
All Principals, specific User, specific Role
What (Resource)
Resources the policy applies to
All Resources, SSH test, tagged resources
What (Action)
Actions permitted or forbidden
All actions, connect, SQL::delete, SQL::update
When
Time or context conditions
Always, specific time windows
With
Additional requirements
Workflow approval, MFA challenge
ℹTo delete a policy, open it in the Policy Library, go to the Settings tab, and click Delete at the bottom of the screen.
Page 2 of 8
Module 1.3 — Policies
Statement Structure
StrongDM uses the Cedar policy language. Every policy statement follows a defined structure with an effect, scope, and optional conditions.
permit or forbid — whether the statement allows or blocks the action
📋
Scope
Combination of principal, action, and resource the policy applies to
🔍
Conditions
Optional when / unless blocks for contextual constraints
Effect: Permit vs Forbid
✅
Permit Statements
▼
A permit statement allows user actions when all of the following are true:
• The user's username or role matches the principal in the statement
• The resource being accessed matches the resource in the statement
• Any contextual elements in the statement match the user's current context
• The user completes any additional requirements (e.g., MFA, workflow approval)
🚫
Forbid Statements
▼
A forbid statement blocks user actions when all of the following are true:
• The user's username or role matches the principal in the statement
• The resource being accessed matches the resource in the statement
• Any contextual elements in the statement match the user's current context
🔴Forbid always wins. When both Permit and Forbid statements apply to the same principal/resource, Forbid takes precedence — regardless of statement order or how many permits exist. The Policy Builder does not currently check for conflicts.
Scope: Principal, Action, Resource
The scope defines exactly who, what, and where the policy applies.
👤Principal — Who
▼
The principal identifies who is permitted or forbidden access. It can be:
💡Roles are preferred for production environments for easier maintenance. User IDs are found in the URL of a user's profile page or via sdm admin users list in the CLI.
⚙️Action — What (Behavior)
▼
The action specifies the exact operation a user is permitted or forbidden to perform. Actions include both StrongDM-level and database-level operations.
Resource IDs are found in the URL of the resource's page in the console, or via sdm admin servers list in the CLI. Use Builder controls to avoid needing to know IDs manually.
Page 3 of 8
Module 1.4 — Policies
Actions & PBAC
Policy-Based Action Controls (PBAC) let StrongDM monitor not just who connects, but what they do once connected — at the instruction level.
What are Actions?
The action in a policy statement indicates the specific operation a user is permitted or forbidden to perform on a resource.
Types of Actions
StrongDM Actions — e.g., connecting to a resource (StrongDM::Action::"connect")
Database Actions — CRUD operations like SQL::Action::"delete", "update", "insert"
Resource-Specific Actions — e.g., Postgres-specific functions like Postgres::Action::"callFunction"
ℹStrongDM can perform different actions on different resources. The full list of available actions for a resource type is searchable directly in the Policy Editor's Builder controls under "What."
How PBAC Fits In
Traditional access control stops at the door. PBAC goes further — it's a continuous assessment.
🔑 Traditional IAM
Controls who can access what. Once the user is in, their behavior inside the resource is generally unconstrained from the access layer's perspective.
⚡ PBAC (StrongDM)
Continuously monitors what users do once connected. Inspects instructions and data sent to the resource and can block destructive operations in real time.
Four Trust Pillars
Policies can enforce trust across all of these dimensions simultaneously.
🙋 Trust the User (Who)
Validated via IdP integrations and StrongAuth. Answers: is this the right identity?
💻 Trust the Device (On What)
Endpoint verification and EPP/EDR integration (e.g., CrowdStrike, Sentinel One). Answers: is this device healthy and trusted?
📍 Trust the Context (Where, When)
IP address and time-based conditions. Answers: is this request from the right location at the right time?
✅ Trust the Action (What)
PBAC action inspection. Answers: is what the user is trying to do permitted?
✓PBAC enables continuous assessment — not just a one-time gate check at connection time, but ongoing evaluation of every instruction sent to the resource.
Page 4 of 8
Module 1.5 — Policies
Policy Use Cases
Real-world examples of how Cedar policy statements solve common enterprise access control challenges.
UC #1
Restrict Dev DBs to a Role; Read-Only on Production
Scenario
Only users in the devDBUsers role should have full access to development databases (tagged env=dev). All other users should be denied access. This is achieved by permitting the role on tagged resources and letting the implicit deny handle everyone else.
Resource TagRole-Scoped Permit
Cedar Policy
// Permit devDBUsers role on dev-tagged resources permit( principalinStrongDM::Role::"devDBUsers", action, resource ) when { resource.sdm.tags has env &&resource.sdm.tags.env=="dev" };
UC #2
Allow Production Access to On-Call Role with MFA
Scenario
Users in the oncall-dev role need access to production resources in the US-East region, but must complete an MFA challenge first. This prevents unattended access and ensures presence before connection.
Users can perform delete or update operations on a Postgres resource, but must complete MFA first. This adds a friction gate specifically for destructive actions — not blocking access entirely, just raising the bar for risky operations.
SQL queries by the operator role are capped at 100 rows and a notification is displayed to the client. Admins are excluded from this restriction using the unless clause.
Row LimitClient NotifyAdmin Exempt
Cedar Policy
// Limit rows and notify — except for admin @maxrows("100") @notify("queries are limited to 100 rows") permit( principalinStrongDM::Role::"operator", action, resource ) unless { principalinStrongDM::Role::"admin" };
Page 5 of 8
Module 2.1 — Access
Granting Access
Resource access is controlled through Roles and the StrongDM console. Zero-standing access is the recommended default posture.
Zero-Standing Privileges
In a correctly configured environment, users start with no access to any resources.
✓When a new user first logs into their StrongDM client, they should see "You have no resources." This is the expected state — consistent with zero-standing privilege best practices. Resources are granted on a just-in-time basis.
Roles: The Access Mechanism
User identities are assigned to Roles. Roles define which resources are visible and accessible.
Role Assignment
A user's StrongDM identity is linked to one or more Roles. Each Role contains resource grants. When a user logs in, the client shows all resources associated with their roles.
Port Overrides
Users connect to the StrongDM client's loopback address (127.0.0.1) with a resource-specific override port — not the resource's real port. Port overrides are configured when defining the resource and must be unique in the range 1024–64999.
Credentials and the Gateway
Users never handle the resource credentials directly.
🔒 Leased Credentials
The credentials used to logon to the StrongDM client are not the credentials used to access the resource. The Gateway or Relay makes the actual connection to the resource using either leased credentials or identity aliases — stored in Strong Vault or an external secret store. Users never see or handle these credentials.
ℹMore details about leased credentials are covered in the StrongDM 201 — Authentication module.
Session Logging
StrongDM monitors and records all traffic through the proxy.
📋 Session Logs
Generated for each resource type with specific log categories (SSH, RDP, Queries, Kubernetes, Cloud, Web, Policies)
Uploaded to the StrongDM control plane
Essential for operations: StrongDM will only allow traffic to resources if logs from previous sessions are properly uploaded to the control plane
Viewable by administrators in Logs → Activities / Queries / SSH / RDP etc.
Page 6 of 8
Module 2.2 — Access
Approval Workflows
Users can request temporary access to resources through a structured approval process, enabling just-in-time access without standing privileges.
The Request & Approval Flow
With the right workflow configured, users follow this path:
1
User Browses the Catalog
The user logs into the StrongDM console and navigates to Access → Request Access → Catalog. They find the resource and click Request access, providing a reason and duration.
2
Request Sent to Approver
The request is routed to the designated approver. The approver logs into the console and goes to Access → Request Access → Requests. They locate the pending request and click Action → View request details.
3
Approver Reviews and Approves
The approver reviews the request details — requester, resource, reason, and duration. They click Approve (or Deny). An optional note can be sent back to the requester.
4
Resource Appears in Client
After approval, the resource appears in the user's StrongDM client for the approved duration. When the time expires, it disappears automatically — enforcing time-limited access.
Approval Step Types
Three types of approval steps can be configured on a workflow.
⚡ Automatic
Requests meeting conditions are instantly approved. Best for low-risk resources with no manual oversight needed.
🎫 ServiceNow
Requests and approvals are managed through ServiceNow. Integrates with existing ITSM workflows for compliance-heavy environments.
🙋 Manual
Selected StrongDM users (by role or individual) must manually approve requests. Supports groups like "Resource role" or "admin" as required approvers.
When Policies Add a Second Approval
With a workflow-enabled policy in place, users may encounter two sequential approvals:
Step 1
Request access on Catalog
→
Step 2
Approve (Access Grant)
→
Step 3
Connect to resource
→
Step 4
Approve (Policy)
→
Step 5
Use resource
ℹThe friction of two approvals can be mitigated through standing access configurations for frequently-used resources. Details are covered in the Standing access sub-section of the Access module.
Posture Visibility Tools
StrongDM integrates with endpoint security platforms to factor device health into access decisions.
🛡️ EPP/EDR Integration
Posture visibility tools like CrowdStrike and Sentinel One report on device health and security posture. This data can be used in policy conditions — e.g., only allowing connections when context.trust.status == "good". This adds the "Trust the Device" layer to your access controls.
Page 7 of 8
Assessment
Knowledge Check
Test your understanding of StrongDM 201 — Policies and Access. Answer all questions to complete the course.
Question 1 of 5
When both a Permit and Forbid statement apply to the same principal and resource in the same policy, which takes precedence?
APermit — it is evaluated first
BForbid — it always takes precedence, regardless of order
CThe last statement written wins
DThe policy is invalid and must be corrected
Question 2 of 5
What does PBAC stand for, and what does it control?
APrincipal-Based Access Control — controls who can log in
BPolicy-Based Audit Control — controls log retention
CPolicy-Based Action Controls — monitors what users do once connected to a resource