First draft (#5447)

(cherry picked from commit 333e84c)

docs/detections/rules-cross-cluster-search.asciidoc

@@ -9,9 +9,11 @@
 
 This section explains the general process for setting up cross-cluster search in detection rules. For specific instructions on each part of the process, refer to the linked documentation.
 
-NOTE: This procedure uses TLS certificate authentication to add remote clusters. {stack} 8.10.0 introduces an alternate method using {ref}/remote-clusters-api-key.html[API key authentication], but it is not yet supported for detection rules.
+. On the local cluster, establish trust and set up a connection to the remote cluster, using one of the following methods. With either method, note the unique name that you give to the remote cluster, because you'll need to use it throughout this process.
 
-. On the local cluster, {ref}/remote-clusters-cert.html[establish trust and set up a connection] to the remote cluster. Note the unique name that you give to the remote cluster, because you'll need to use it throughout this process.
+* {ref}/remote-clusters-api-key.html[Add remote clusters using API key authentication] — Clusters must be on {stack} version 8.14 or later. 
+
+* {ref}/remote-clusters-cert.html[Add remote clusters using TLS certificate authentication]
 
 . On both the local and remote clusters, {ref}/remote-clusters-cert.html#clusters-privileges-ccs-kibana-cert[create a
 role for cross-cluster search privileges], and make sure the two roles have
@@ -56,7 +58,9 @@ IMPORTANT: The rule preview uses the current user's cross-cluster search privile
 [[update-api-key]]
 === Update a rule's API key
 
-When a user creates a new rule or saves edits to an existing rule, their current privileges are saved to {kibana-ref}/alerting-setup.html#alerting-authorization[the rule's API key]. If that user's privileges change in the future, the rule *_does not_* automatically update with the user's latest privileges — you must update the rule's API key to update its privileges.
+Each detection rule has its own {kibana-ref}/alerting-setup.html#alerting-authorization[API key], which determines the data and actions the rule is allowed to access. When a user creates a new rule or changes an existing rule, their current privileges are saved to the rule's API key. If that user's privileges change in the future, the rule *_does not_* automatically update with the user's latest privileges — you must update the rule's API key if you want to update its privileges.
+
+IMPORTANT: A rule's API key is different from the API key you might have created for <<set-up-ccs-rules,authentication between local and remote clusters>>.
 
 To update a rule's API key, log into the local cluster as a user with the privileges you want to apply to the rule, then do either of the following: