fixup! chore(config): rename to docs

Author: andrewazores

docs/_subsections/operator-architecture.md

@@ -63,7 +63,7 @@ The label <code>cryostat.io/callback-port</code> can be used to control the HTTP
 
 ### [Flow of JFR Data](#flow-of-jfr-data)
 
-**Cryostat** traditonally connects to other **JVM** applications within its cluster using remote JMX, using cluster-internal URLs so that no traffic will leave the cluster. **Cryostat** supports connecting to target **JVMs** with JMX auth credentials enabled ("Basic" style authentication). When a connection attempt to a target fails due to a <code>SecurityException</code>, Cryostat responds to the requesting client with an HTTP 427 status code and the header <code>X-JMX-Authenticate: Basic</code>. The client is expected to create a [Stored Credential](/guides/#store-credentials) object via the **Cryostat API** before retrying the request, which results in the required target credentials being stored in an encrypted database table. When deployed in **OpenShift** the requests are already encrypted using **OpenShift** TLS re-encryption as mentioned above, so the credentials are never transmitted in cleartext. The table is encrypted with a passphrase either provided by the user at deployment time, or generated by the **Operator** if none is specified. It is also possible to configure **Cryostat** to trust SSL certificates used by target JVMs by adding the certificate to a <code>Secret</code> and linking that to the **Cryostat CR**, which will add the certificate to the SSL trust store used by **Cryostat**. The Operator also uses **cert-manager** to generate a self-signed CA and provides **Cryostat's** auth proxy with certificates as a mounted volume. For more information on setting this up, see [Configuring the Operator](/config/#configure-the-cryostat-operator)
+**Cryostat** traditonally connects to other **JVM** applications within its cluster using remote JMX, using cluster-internal URLs so that no traffic will leave the cluster. **Cryostat** supports connecting to target **JVMs** with JMX auth credentials enabled ("Basic" style authentication). When a connection attempt to a target fails due to a <code>SecurityException</code>, Cryostat responds to the requesting client with an HTTP 427 status code and the header <code>X-JMX-Authenticate: Basic</code>. The client is expected to create a [Stored Credential](/guides/#store-credentials) object via the **Cryostat API** before retrying the request, which results in the required target credentials being stored in an encrypted database table. When deployed in **OpenShift** the requests are already encrypted using **OpenShift** TLS re-encryption as mentioned above, so the credentials are never transmitted in cleartext. The table is encrypted with a passphrase either provided by the user at deployment time, or generated by the **Operator** if none is specified. It is also possible to configure **Cryostat** to trust SSL certificates used by target JVMs by adding the certificate to a <code>Secret</code> and linking that to the **Cryostat CR**, which will add the certificate to the SSL trust store used by **Cryostat**. The Operator also uses **cert-manager** to generate a self-signed CA and provides **Cryostat's** auth proxy with certificates as a mounted volume. For more information on setting this up, see [Configuring the Operator](/docs/#configure-the-cryostat-operator)
 
 In more recent releases, **JVM** applications may optionally be instrumented with the **Cryostat Agent**, which uses the local **JDK** Instrumentation API to hook into the target application. The **Cryostat Agent** then exposes a **JDK** HTTP(S) webserver, generates credentials to secure it, and looks up its supplied configuration to locate the **Cryostat** server instance it should register with. Once it is registered the **Cryostat Agent** creates a <code>Stored Credential</code> object on the server corresponding to itself, then clears its generated password from memory retaining only the hash. From this point on, the **Agent** and **Cryostat** server communicate with each other using Basic authentication bidirectionally, and with TLS enabled on each webserver if enabled/configured.