Merge branch 'master' into smallinsky/bump_e_ref

docs/config.json

@@ -1912,7 +1912,7 @@
       "nodeIP": "ip-172-31-35-170"
     },
     "access_graph": {
-      "version": "1.20.1"
+      "version": "1.20.4"
     },
     "ansible": {
       "min_version": "2.9.6"

docs/pages/access-controls/access-graph/self-hosted.mdx

@@ -29,8 +29,19 @@ to Teleport Enterprise customers.
 - A TLS certificate for the Access Graph service
   - The TLS certificate must be issued for "server authentication" key usage,
     and must list the IP or DNS name of the TAG service in an X.509 v3 `subjectAltName` extension.
+  - Starting from version 1.20.4 of the Access Graph service, the container runs as a non-root user by default.
+    Make sure the certificate files are readable by the user running the container. You can set correct permissions with the following command:
+    ```code
+    $ sudo chown 65532 /etc/access_graph/tls.key
+    ```
 - The node running the Access Graph service must be reachable from Teleport Auth Service and Proxy Service.
 
+<Notice type="warning">
+    The deployment with Docker is suitable for testing and development purposes. For production deployments,
+    consider using the Teleport Access Graph Helm chart to deploy this service on Kubernetes.
+    Refer to [Helm chart for Access Graph](self-hosted-helm.mdx) for instructions.
+</Notice>
+
 ## Step 1/3. Set up the Teleport Access Graph service
 
 You will need a copy of your Teleport cluster's host certificate authority (CA) on the machine that hosts the Access Graph service.

docs/pages/reference/networking.mdx

@@ -233,21 +233,16 @@ Service, Kubernetes Service, and other services that protect resources in your
 infrastructure, there is no need to open ports on the machines running the
 agents to the public internet. 
 
-Some Teleport services listen for traffic to one of their proxied resources,
-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. 
+<Details title="Direct connections to agents">
 
-<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>
+If you run a self-hosted Teleport cluster, you can join an agent [directly to
+the Teleport Auth
+Service](../agents/join-services-to-your-cluster/join-token.mdx#start-your-teleport-process-with-the-invite-token).
+In this setup, certain Teleport services open their own listeners rather than
+accepting connections via reverse tunnel. The Proxy Service connects to these
+agent services by dialing them directly.
 
-The table below describes the ports that each Teleport Service opens for proxied
+The table below describes the ports that each Teleport service opens for proxied
 traffic:
 
 | Port | Service | Traffic Type |
@@ -256,6 +251,9 @@ traffic:
 | 3026 | Kubernetes Service | HTTPS traffic to a Kubernetes API server.| 
 | 3028 | Windows Desktop Service | Teleport Desktop Protocol traffic from Teleport clients.|
 
-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.
+You can only access enrolled applications and desktops 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.
+
+</Details>