ECH PrivateLink: warn that Cloud ID encodes non-VPCE URL - #8034
Conversation
The Cloud ID always encodes the public (found.io-based) endpoint domain, not the PrivateLink-compatible elastic-cloud.com domain. Customers who derive their PrivateLink URL from the Cloud ID get a TLS cert mismatch. - private-connectivity-aws.md: add note in Test the connection (ECH) - find-cloud-id.md: add note warning PrivateLink users away from Cloud ID Related: elastic/support-tech-lead#1921
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. |
🔍 Preview links for changed docs |
✅ 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. |
kunisen
added
supportability
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
There was a problem hiding this comment.
Docs review summary
Focus areas
- Style and clarity: New notes are clear and correctly scoped, but one uses directional language ("as shown above") flagged by Vale — see inline comment. "e.g" and "towards" flagged by Vale in unrelated, pre-existing lines are not part of this diff.
- Jargon: No unexplained Elastic-internal jargon in the new content; "Cloud ID", "PrivateLink", and "TLS certificate" are used correctly and match established page terminology.
- Frontmatter and applies_to: No frontmatter changes in this PR; existing
applies_toscoping (ess: ga) is preserved and the new notes don't require additional scoping since they apply uniformly within theirapplies-itemblocks. - Content type fit: Both files remain how-to/reference style pages; the added notes fit the existing structure and don't disrupt the surrounding content type.
- Contradictions: No contradictions found between the two changed files or against published docs — the added notes are consistent with each other and reinforce the existing PrivateLink guidance.
- Parent issue satisfaction: Satisfied. The PR adds a warning in both
find-cloud-id.mdandprivate-connectivity-aws.mdaddressing the reported issue that the Cloud ID encodes the public endpoint domain and shouldn't be used to derive PrivateLink URLs.
Nits
private-connectivity-aws.mdline 55 and line 65 have pre-existing Vale findings (e.gandtowards) outside the diff; not blocking for this PR.
Notes
- Reviewed only the two eligible changed markdown files per
repo-wide-markdownscope.
Generated by Docs review agent for #8034 · sonnet50 · 32.3 AIC · ⌖ 3.95 AIC · ⊞ 17.6K
| ::: | ||
|
|
||
| :::{note} | ||
| The Cloud ID for your deployment encodes the public (non-PrivateLink) endpoint domain. Do not use URLs derived from the Cloud ID for PrivateLink connections — they will not match the TLS certificate served at the PrivateLink endpoint and the connection will fail with a certificate hostname mismatch. Always construct your private URL manually as shown above. Review [our KB article](https://ela.st/avoid-using-cloudid-for-privatelink-deployment) for more guidance. |
There was a problem hiding this comment.
Use descriptive link text instead of "our KB article". Text like [Avoid using the Cloud ID for PrivateLink deployments](https://ela.st/avoid-using-cloudid-for-privatelink-deployment) tells readers what the link leads to before they click it, following the accessibility guidance against non-descriptive link text.
Also confirm the KB article is publicly accessible without a support login; if it requires an active support contract, link to a public resource instead or note that support access is required.
There was a problem hiding this comment.
no we may have to change the KB title later due to whatever reason so I want to keep things more generic and flexible.
rahulranjan22
left a comment
rahulranjan22
left a comment
There was a problem hiding this comment.
One minor comment regarding use of dash.
AlexP-Elastic
left a comment
AlexP-Elastic
left a comment
There was a problem hiding this comment.
LGTM - thanks for making the change <3
(now we just have to remember to change it back when we finally do get round to fixing VPCE naming in cloud id :) )
3 participants
The Cloud ID always encodes the public (found.io-based) endpoint domain, not the PrivateLink-compatible elastic-cloud.com domain. Customers who derive their PrivateLink URL from the Cloud ID get a TLS cert mismatch.
Related: elastic/support-tech-lead#1921
Summary
Generative AI disclosure
Claude