Before you submit
Type of issue
Missing information
What documentation page or section is affected
https://www.elastic.co/docs/deploy-manage/tools/cross-cluster-replication/_configure_privileges_for_cross_cluster_replication_2
What happened?
The CCR privileges document proposes a configuration that follows the legacy authorization mechanism used with Remote Clusters with TLS certificate-based authentication (already deprecated, although functional).
I assume CCR supports RCS2.0 (API key-based authentication), in such case the authorization model is incorrect and we would need something different.
This doc should be reviewed, with the help of devs and admin-docs.
Ideally the doc should tell the user how to configure authorization for CCR in both cases:
- If the user configured the connection between the clusters with the legacy method.
- If the user configured the connection between the clusters with the new API key-based authentication (in this case authorization is performed in the local cluster (but setting the privileges in a different way!), and the API key used for the connection also needs to have certain privileges).
PS - the current doc has a small comment about API keys, with probably good intention, but feels misleading.
^^ That previous comment is misleading because it's not clear if it refers to an API being used to connect both clusters (RCS2.0) or an API key used by the end user when creating the CCR follower (which I don't know if it's even supported in legacy RCS).
If that means real API key authentication on remote clusters setup the sentence would still feel incorrect.
Before you submit
Type of issue
Missing information
What documentation page or section is affected
https://www.elastic.co/docs/deploy-manage/tools/cross-cluster-replication/_configure_privileges_for_cross_cluster_replication_2
What happened?
The CCR privileges document proposes a configuration that follows the legacy authorization mechanism used with Remote Clusters with TLS certificate-based authentication (already deprecated, although functional).
I assume CCR supports RCS2.0 (API key-based authentication), in such case the authorization model is incorrect and we would need something different.
This doc should be reviewed, with the help of devs and admin-docs.
Ideally the doc should tell the user how to configure authorization for CCR in both cases:
PS - the current doc has a small comment about API keys, with probably good intention, but feels misleading.
^^ That previous comment is misleading because it's not clear if it refers to an API being used to connect both clusters (RCS2.0) or an API key used by the end user when creating the CCR follower (which I don't know if it's even supported in legacy RCS).
If that means real API key authentication on remote clusters setup the sentence would still feel incorrect.