[DOCS] Clarify security aspects for CCR

[tahaderouiche]

Description: Explain how security/trust works between a local(follow) cluster and remote (leader) cluster.

Similar to what is being done in CCS, it would be great to clarify how security works for CCR.
Both rely on the same mechanism, so it would be about rephrasing for the CCR context.

[elasticmachine]

Pinging @elastic/es-distributed

[jrodewig]

[docs issue triage]

Leaving open. This is still relevant.

[elasticmachine]

Pinging @elastic/es-security (:Security/Security)

[lockewritesdocs]

@tahaderouiche, are the steps for configuring security between the cluster containing the leader index and the remote clusters the same as configuring security for clusters using CCS? You mentioned that both rely on the same mechanism, so perhaps we can clean up and clarify the instructions for Configuring security for CCS and then share much of that information with a new page for configuring security for CCR.

[ywangd]

@lockewritesdocs Both CCS and CCR have two steps for their configuration. The first step is to setup the general trust relationship between the two clusters. The second step is about actually setting up the permissions around them.

The first step is the same for both CCS and CCR. Hence their security concern is also the same and this includes permissions to `PUT _cluster/settings' and relevant TLS trust setup at transport layer.

The second step is different and CCS is simpler compared to CCR. One thing in common is that they both require the same role names on both local and remote clusters to be used for their configuration. Please note what really matters is the role names, actual definitions of the role can be different on different clusters and in fact they are often different.

CCS

• Assume the same role name ccs_role is used for both clusters.
• On local cluster, an user just need to have the ccs_role. The role itself can be empty (suggested by our doc) or even non-exisit.
• On remote cluster, the ccs_role needs to be defined to have read and read_cross_cluster privileges for the target indices.
• Other than the user and role, there is no extra steps for setup CCS.
• Please note that we are reviewing the read_cross_cluster privilege (Review read_cross_cluster privilege #58476) and may decide to deprecate it so that only read is required (v8.0)

CCR

• Assume the same role name ccr_role is used for both clusters.
• On the local cluster, an user needs to be created with the ccr_role. The ccr_role needs to be defined with manage_ccr cluster privilege and monitor, read, write, manage_follow_index index privileges for the follower indices.
• On the remote cluster, the ccr_role needs to be defined with read_ccr cluster privilege and monitor, read index privileges for the leader indices. Please note, this is suggested by our doc. But the code currently requires an extra indices:admin/seq_no/renew_retention_lease privilege is required for users on the remote cluster. I consider this is a bug of the code and raised CCR exception on retention lease renewal #61308 for it.
• Once the user and role is configured, the actual CCR needs to be configured with the user on the local/follower cluster using something like PUT /follower-index/_ccr/follow ...