docs: Secure communication

[bmorelli25]

Summary

This is a mostly structural PR that combines our multiple "Secure" documentation topics into one.

I'm looking for feedback on if this structure makes sense:

• Secure communication
  • With APM agents
  • With the Elastic Stack -- Probably not the best descriptor. Any ideas?

Preview this PR -- use the links above!

Out of scope

Once we nail down a layout, some content in this section needs to be updated. Reviewing this content is out of scope for this PR and will be addressed in a follow-up PR:

• Create a writer user: privileges out of date
• Create an API Key user: open issue docs: Update standalone apm server API key required privileges #10057 for updating privileges
• Create a central config user: needs to be updated to reflect the changes to central config
• Grant access using API keys: still reference old apm-* indices and not the correct privileges

[mergify]

This pull request does not have a backport label. Could you fix it @bmorelli25? 🙏
To fixup this pull request, you need to add the backport labels for the needed
branches, such as:

• backport-7.x is the label to automatically backport to the 7.x branch.
• backport-7./d is the label to automatically backport to the 7./d branch. /d is the digit

NOTE: backport-skip has been added to this pull request.

[apmmachine]

💚 Build Succeeded

the below badges are clickable and redirect to their specific view in the CI or DOCS

Expand to view the summary

Build stats

• Start Time: 2023-05-22T02:10:07.779+0000

• Duration: 3 min 49 sec

🤖 GitHub comments

Expand to view the GitHub comments

To re-run your PR in the CI, just comment with:

• /test : Re-trigger the build.

• /package : Generate and publish the docker images.

• /test windows : Build & tests on Windows.

• run elasticsearch-ci/docs : Re-trigger the docs validation. (use unformatted text in the comment!)

[axw]

seccomp configuration is unrelated to communication with the stack

I think we should just remove the seccomp section altogether. The only time we fork/exec is for the java attacher, and disallowing those syscalls will break that feature. Otherwise if you want to disallow syscalls it's better to apply seccomp rules in the calling environment, e.g. using systemd sandboxing or Docker seccomp config.

[axw]

@bmorelli25 did you see this comment?

[bmorelli25]

Whoops. Thanks for the bump on this! Removed.

[axw]

👍

@simitt please shout if you think we should still document seccomp. You may recall we disabled it by default a while back. I think it's still possible to configure, but as mentioned above I think we should guide users to external configuration for this, if needed at all.

[mergify]

This pull request is now in conflicts. Could you fix it @bmorelli25? 🙏
To fixup this pull request, you can check out it locally. See documentation: https://help.github.com/articles/checking-out-pull-requests-locally/

git fetch upstream
git checkout -b ft-secure-pt2 upstream/ft-secure-pt2
git merge upstream/main
git push upstream ft-secure-pt2