Refactor agent architecture guides into one (#41009)

* Refactor agent architecture guides into one

See #37558

The Teleport documentation has two guides that explain the architecture
of Teleport agents:

- The Database Access Architecture guide
  (`docs/pages/database-access/architecture.mdx`)
- The SSH Nodes guide (`docs/pages/architecture/nodes.mdx`)

While these guides are framed around describing the architecture of
specific agent services, most of the information in these guides applies
to Teleport agents in general.

This change refactors these two guides into a single Teleport agent
architecture guide that applies to all agent services. Where agents
differ, the guide users tables to explain differences. It also links to
more specific guides where applicable.

As an alternative, we could create a separate architecture guide for
each agent service. This change avoids this approach because:
- The purpose of this change is to refactor existing information for
  discoverability, and adds minimal new information.
- Agent services differ substantially in how they proxy traffic to
  specific resources. As of #40115, we expect how-to guides to contain a
  "How it works" section to explain the architecture of enrolling a
  specific resource (#39979 includes an example that edits database
  guides). This approach is cleaner than using a single guide to
  describe the architecture of connecting to every single resource an
  agent can proxy.
- The convention of having a separate `[Resource] Access` section of the
  docs per agent service reflects legacy messaging that we are moving
  away from.

More specific changes:

- Remove `docs/pages/database-access/architecture`.
- Combine information from the Database Architecture and SSH Nodes
  guides into an Agent Architecture guide in
  `docs/pages/architecture/agents.mdx`.
- Move session secording information from the SSH Nodes guide to
  the Session Recording architecture guide, where it is more
  appropriate.
- Remove "Cluster State" from the SSH Nodes guide, since this
  information is present in the backends reference.
- Briefly document direct dial mode for agents, but frame the new guide
  around the assumption that users will/should enroll agents via the
  Teleport Proxy Service.
- Add a new architecture diagram and moves the original one to the
  Database Access Introduction page.

* Respond to greedy52 feedback

- Edit list of database protocols.
- Note additional commands that retreive certificates.
- Add information re: `tsh apps login` to the client cert table.
- Fix Desktop Service introduction mistake.
- Mention the Discovery Service after the list of agent services.
- List the Discovery Service as one that does not require a reverse
  tunnel.
- Mention HTTP apps in the local proxy table.

* Partially respond to feedback

- Use a clearer first paragraph and replace "proxy" where possible when
  talking about agents.
- Use more accurate column heading in service table.
- Clarify where agents can run and their relationship to services.
- Other accuracy/clarity fixes, including incorporating suggested
  wording.
- Describe example agent-to-resource authentication methods for
  resources besides databases.
- Mention Teleport Connect.
- Remove the mention of agent ping message payloads.

* Edit the agent architecture guide

Flatten the heading structure, organizing the guide according to
connections between components, merging the "Retrieving credentials"
sections into sections related to communication between components.

Also clarify the process in which the Proxy Service forwards traffic to
an agent over a reverse tunnel.

* Edit the intro paragraph

* Fix spelling

* Fix linter errors

- Update link target paths
- Add the "Cluster state" H2 from the original "Nodes" architecture
  guide to the Backend Reference so the latter doesn't need to link to a
  missing section.

docs/config.json

@@ -1437,10 +1437,6 @@
           "title": "Using the Teleport Database Service",
           "slug": "/database-access/guides/"
         },
-        {
-          "title": "Architecture",
-          "slug": "/database-access/architecture/"
-        },
         {
           "title": "Reference",
           "slug": "/database-access/reference/",
@@ -1888,10 +1884,10 @@
           "title": "Trusted Clusters",
           "slug": "/architecture/trustedclusters/"
         },
-        {
-          "title": "Teleport Nodes",
-          "slug": "/architecture/nodes/"
-        },
+	{
+	  "title": "Teleport Agents",
+	  "slug": "/architecture/agents/"
+	},
         {
           "title": "Session Recording",
           "slug": "/architecture/session-recording/"

docs/cspell.json

@@ -184,6 +184,7 @@
     "SLAVEOF",
     "SLES",
     "SLOWLOG",
+    "SPDY",
     "SPIFFE",
     "SQLSTATE",
     "SSUBSCRIBE",
@@ -873,6 +874,7 @@
     "trustedclusters",
     "trustpolicy",
     "truststore",
+    "tshd",
     "turnoffuserassign",
     "ubunutu",
     "udev",
@@ -941,8 +943,7 @@
     "yubishm",
     "znmqk",
     "zxvf",
-    "zztop",
-    "SPDY"
+    "zztop"
   ],
   "flagWords": [
     "hte"

docs/pages/access-controls/compliance-frameworks/soc2.mdx

@@ -72,7 +72,7 @@ Each principle has many "Points of Focus" which will apply differently to differ
 | CC6.7 - Uses Encryption Technologies or Secure Communication Channels to Protect Data | Encryption technologies or secured communication channels are used to protect transmission of data and other communications beyond connectivity access points. | [Teleport has strong encryption including a FedRAMP compliant FIPS mode](./fedramp.mdx#start-teleport-in-fips-mode) |
 | CC7.2 - Implements Detection Policies, Procedures, and Tools | Processes are in place to detect changes to software and configuration parameters that may be indicative of unauthorized or malicious software. | [Teleport creates detailed SSH Audit Logs with Metadata](../../reference/audit.mdx) <br/><br/> [Use BPF Session Recording to catch malicious program execution](../../server-access/guides/bpf-session-recording.mdx) |
 | CC7.2 - Designs Detection Measures | Detection measures are designed to identify anomalies that could result from actual or attempted (1) compromise of physical barriers; (2) unauthorized actions of authorized personnel; (3) use of compromised identification and authentication credentials; (4) unauthorized access from outside the system boundaries; (5) compromise of authorized external parties; and (6) implementation or connection of unauthorized hardware and software. | [Use Enhanced Session Recording to catch malicious program execution, capture TCP connections and log programs accessing files on the system the should not be accessing.](../../server-access/guides/bpf-session-recording.mdx) | 
-| CC7.3 - Communicates and Reviews Detected Security Events | Detected security events are communicated to and reviewed by the individuals responsible for the management of the security program and actions are taken, if necessary. | [Use Session recording to replay and review suspicious sessions](../../architecture/nodes.mdx#ssh-session-recording). | 
+| CC7.3 - Communicates and Reviews Detected Security Events | Detected security events are communicated to and reviewed by the individuals responsible for the management of the security program and actions are taken, if necessary. | [Use Session recording to replay and review suspicious sessions](../../architecture/session-recording.mdx). | 
 | CC7.3 - Develops and Implements Procedures to Analyze Security Incidents | Procedures are in place to analyze security incidents and determine system impact. | [Analyze detailed logs and replay recorded sessions to determine impact. See exactly what files were accessed during an incident.](../../server-access/guides/bpf-session-recording.mdx) | 
 | CC7.4 - Contains Security Incidents | Procedures are in place to contain security incidents that actively threaten entity objectives. | [Use Teleport to quickly revoke access and contain an active incident](../../access-controls/guides/locking.mdx) <br/><br/> [Use Shared Sessions so Multiple On-Call Engineers can collaborate and fight fires together.](../../connect-your-client/tsh.mdx#sharing-sessions) |
 | CC7.4 - Ends Threats Posed by Security Incidents | Procedures are in place to mitigate the effects of ongoing security incidents. | [Use Teleport to quickly revoke access and contain an active incident](../../access-controls/guides/locking.mdx)   | 

docs/pages/access-controls/reference.mdx

@@ -362,7 +362,7 @@ unexpected changes to the configuration or state of your cluster.
 
 It is possible to further limit access to
 [shared sessions](../connect-your-client/tsh.mdx#sharing-sessions) and
-[session recordings](../architecture/nodes.mdx#ssh-session-recording).
+[session recordings](../architecture/session-recording.mdx).
 The examples below illustrate how to restrict session access only for the user
 who created the session.
 

docs/pages/agents/introduction.mdx

@@ -12,6 +12,10 @@ your infrastructure.
 
 ## Architecture overview
 
+This section provides a brief outline of how Teleport agents run in a Teleport
+cluster. For more information on the architecture of Teleport agents, read
+[Teleport Agent Architecture](../architecture/agents.mdx).
+
 ### Services
 
 Each Teleport process can run one or more **services**. A Teleport instance runs

docs/pages/application-access/introduction.mdx

@@ -20,6 +20,12 @@ Examples include:
 If you are running applications on Kubernetes, you can [enroll them in your
 Teleport cluster automatically](../auto-discovery/kubernetes-applications.mdx).
 
+Teleport protects applications through the Teleport Application Service, which
+is a Teleport agent service. For more information on agent services, read
+[Teleport Agent Architecture](../architecture/agents.mdx). You can also learn
+how to deploy a [pool of Teleport agents](../agents/introduction.mdx) to run
+multiple agent services.
+
 ## Getting started
 
 Learn how to register an application with Teleport in our [getting started