Rehome CCS/CCR permissions - #6934
Conversation
Elastic Docs AI PR menuCheck the box to run an AI review for this pull request.
Powered by GitHub Agentic Workflows and docs-actions. For more information, reach out to the docs team. |
✅ Elastic Docs Style Checker (Vale)No issues found on modified lines! The Vale linter checks documentation changes against the Elastic Docs style guide. To use Vale locally or report issues, refer to Elastic style guide for Vale. |
There was a problem hiding this comment.
Docs review summary
Focus areas
- Style and clarity: One typo and one Vale wordiness suggestion in the new CCS section (see inline comments). Other Vale findings in changed files (
may,disabled,Disable,and/or, menu arrows) are all in pre-existing, untouched lines. - Jargon: No new jargon issues.
CCS,CCR,API key, andTLSare all adequately contextualised in the new content. - Frontmatter and applies_to: The CCR file's
applies_tochange from the verbosedeployment: eck/ess/ece/selftostack: allis valid and consistent with repo usage. Inline{applies_to}directives on the deprecated TLS cert sections are correctly applied. - Content type fit: The restructuring works. The CCS page was already a reference/how-to hybrid; adding the privilege section fits its existing shape and reader needs.
- Parent issue satisfaction: Based on the PR description, the stated goals (move privilege config out of setup pages into feature pages, slim down setup pages, update links) appear satisfied. The detection rules link update introduces a content accuracy issue worth fixing before merge (see inline comment on line 30).
Nits
cross-cluster-search.mdline 133: Therun_asprivilege in the new TLS cert subsection is plain backtick text, while the parallel CCR file links it to the privilege docs (`(reference/redacted) Consider linking for consistency.cross-cluster-search.mdline 110: "Note that you only need to create this user on the local cluster." uses informal prose while line 176–178 uses a formal::::{note}admonition for the same information in the adjacent TLS section. Minor inconsistency.
Generated by Docs review agent for issue #6934 · 419.8 AIC · ⌖ 25.4 AIC · ⊞ 32.8K
eedugon
left a comment
There was a problem hiding this comment.
I've only had time to review the snippet. Sharing a comment about it. As it's a snippet used in a lot of pages I think we should give a bit of extra love to it, and also mention the TLS cert-based authentication possibility.
eedugon
left a comment
There was a problem hiding this comment.
I've suggested some changes, I think it's a good time to refine and enhance some of the content at the same time as doing this movement.
I think the suggested changes are low effort, but feel free to ignore any of them as we could leave them for a later stage.
| anchors: | ||
| 'enable-elastic-capabilities': 'elastic-capabilities' | ||
|
|
||
| # Rehome CCS and CCR privileges from remote-clusters-cert.md |
There was a problem hiding this comment.
Impressive work with redirections here!
There was a problem hiding this comment.
Was really easy to do with Cursor, so I'm afraid I can't take much credit for this specific task. Previous encounters with redirects gave me nightmares 😂
|
Hi @eedugon, thank you so much for your insightful review, really appreciate it! 💡 🙏 I think I've addressed your feedback and this is ready for another round of reviews whenever you get the chance. Many thanks in advance! 😸 |
eedugon
left a comment
There was a problem hiding this comment.
Looks great! I've added one suggestion to remove the note, that IMO doesn't add any value on the TLS cert-based auth.
I've tested the flow completely in a lab (2 ECK clusters) with TLS cert based auth, and the suggested roles work perfectly fine.
If you want me to test the setup with RCS 2.0 (API key based auth) let me know but that should wait until next week.
Besides that I think we need to create a separate issue to enrich this with API key based requests (note that I'm not talking here about how remote cluster is set up, but about how the end user trying CCS is running the request. All our examples (role + user creation) consider user based auth, and not API key based auth). We should tell users if CCS also work with API keys and how to set up the API key in that case (again not the "remote cluster API key", but the user API key).
I've opened #7064 for this. Please feel free to add to it/edit the description to refine it further, @eedugon |
leemthompo
left a comment
There was a problem hiding this comment.
Edu has forgotten more about these topics than I will ever know, so I defer to his approval TBH. I made one minor suggestion about dropdown-ing the deprecated TLS approach :)
| Certificate based authentication is deprecated. Configure [API key authentication](/deploy-manage/remote-clusters/remote-clusters-api-key.md) instead or follow a guide on how to [migrate remote clusters from certificate to API key authentication](/deploy-manage/remote-clusters/remote-clusters-migrate.md). | ||
| ::: | ||
|
|
||
| After [connecting remote clusters](/deploy-manage/remote-clusters/remote-clusters-self-managed.md), create matching user roles on both the local and remote clusters and assign the necessary privileges. With TLS-based authentication, the local user's role names are forwarded to the remote cluster, which authorizes the request by evaluating roles with the same names defined locally. |
There was a problem hiding this comment.
I'd consider whacking all this in a dropdown to underline the "are you sure?" messaging and slimming the page down a bit :)
There was a problem hiding this comment.
Love this! If it's deprecated it should be prioritised less. 👍
I'll add this suggestion to #7064 as there's a few more improvements that could be applied to some of the sections. I'll implement this as part of 7064
Summary
Fixes #436 and #6810
This PR moves the cross-cluster privilege configuration out of the remote cluster setup pages and into the feature pages of CCR and CCS where readers actually need it.
Generative AI disclosure
Used Cursor's Auto Agent mode to validate some concepts and find links to update. Also super handy way to create the necessary redirects.