diff --git a/docs/pages/access-controls/reference.mdx b/docs/pages/access-controls/reference.mdx
index b997923644e90..043cd15fa4312 100644
--- a/docs/pages/access-controls/reference.mdx
+++ b/docs/pages/access-controls/reference.mdx
@@ -408,18 +408,18 @@ metadata:
 spec:
   allow:
     rules:
-    # Teleport allows shared session access by default, so for our restrictions
-    # to work we first allow access to ssh_sessions...
-    - resources: [ssh_session]
+    # Teleport allows session access to the user's sessions
+    # and sessions they can join by default. This allows seeing any sessions.
+    - resources: [session_tracker]
       verbs: ['*']
   deny:
     rules:
     # ... and then limit that access via a deny rule.
     # Deny rules take precedence over allow rules, so the resulting role allows
     # users to create SSH sessions but to only view their own sessions.
-    - resources: [ssh_session]
+    - resources: [session_tracker]
       verbs: [list, read, update, delete]
-      where: '!contains(ssh_session.participants, user.metadata.name)'
+      where: '!contains(session_tracker.participants, user.metadata.name)'
 ```
 
 ## Second Factor - U2F
@@ -435,7 +435,7 @@ Here is an explanation of the fields used in the `where` and `filter` conditions
 | -------------------------- | ------------------------------------------------- |
 | `user.spec.roles`          | The list of roles assigned to a user              |
 | `session.participants`     | The list of participants from a session recording |
-| `ssh_session.participants` | The list of participants from an SSH session      |
+| `session_tracker.participants` | The list of participants from an SSH session      |
 | `user.metadata.name`       | The user's name                                   |
 
 Check out our [predicate language](../reference/predicate-language.mdx#scoping-allowdeny-rules-in-role-resources)
diff --git a/docs/pages/includes/role-spec.mdx b/docs/pages/includes/role-spec.mdx
index 1da85f344b6e7..b6a1cd12946cc 100644
--- a/docs/pages/includes/role-spec.mdx
+++ b/docs/pages/includes/role-spec.mdx
@@ -356,7 +356,9 @@ spec:
     # access_plugin_data - allows modifying Access Request plugin data
     #
     # session            - session playback records
-    # ssh_session        - an active SSH session
+    # session_tracker    - an active session
+    # ssh_session        - allows seeing active sessions page
+    # instance           - a Teleport instance
     # event              - structured audit logging event
     #
     #
diff --git a/docs/pages/reference/networking.mdx b/docs/pages/reference/networking.mdx
index 888898c989478..97f08b39a903c 100644
--- a/docs/pages/reference/networking.mdx
+++ b/docs/pages/reference/networking.mdx
@@ -149,6 +149,10 @@ In those cases, they can set up separate listeners in the config file.
 | 3023 | All clients | SSH port clients connect to. The Proxy Service will forward this connection to port `3022` on the destination service. |
 | 3024 | Auth Service | SSH port used to create reverse SSH tunnels from behind-firewall environments into a trusted Proxy Service instance. |
 | 3080 or 443 | Proxy Service | HTTPS connection to authenticate `tsh` users into the cluster. The same connection is used to serve a Web UI. |
+| 3036 | Database Service | Traffic to MySQL databases.|
+| 5432 | Database Service | Traffic to Postgres databases.|
+| 27017 | Database Service | Traffic to MongoDB instances.|
+| 6379 | Database Service | Traffic to Redis instances.|
 
 ### Auth Service ports
 
@@ -225,6 +229,15 @@ meaning that you can expose ports on that service's host directly to clients.
 This is useful when you need to connect to resources directly if the Proxy
 Service becomes unavailable.
 
+<Admonition
+  type="tip"
+  title="Note"
+>
+  In Teleport Cloud, the Auth and Proxy Services run in Teleport-owned infrastructure.
+For this reason, Teleport Cloud customers must connect their resources via reverse tunnels.
+Exposing ports for direct dial is only supported in self-hosted deployments.
+</Admonition>
+
 The table below describes the ports that each Teleport Service opens for proxied
 traffic:
 
@@ -232,12 +245,8 @@ traffic:
 | - | - | - |
 | 3022 | SSH Service | Incoming SSH connections.|
 | 3026 | Kubernetes Service | HTTPS traffic to a Kubernetes API server.| 
-| 3036 | Database Service | Traffic to MySQL databases.|
-| 5432 | Database Service | Traffic to Postgres databases.|
-| 27017 | Database Service | Traffic to MongoDB instances.|
-| 6379 | Database Service | Traffic to Redis instances.|
 | 3028 | Windows Desktop Service | Teleport Desktop Protocol traffic from Teleport clients.|
 
-Applications registered with the Teleport Application Service can only be
-accessed via the Teleport Proxy Service, not directly via the Application
-Service.
+You can only access enrolled applications and databases through the Teleport Proxy Service.
+The Teleport Application Service and Teleport Database Service use reverse tunnel
+connections through the Teleport Proxy Service and cannot expose ports directly.