FIPS for ingest tools

[karenzone]

PREVIEWS:
https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/2136/deploy-manage/security/fips
https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/2136/deploy-manage/security/fips-es
https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/2136/deploy-manage/security/fips-kib
https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/2136/deploy-manage/security/fips-ingest

Related:

• [FIPS] Collect user facing documentation notes ingest-docs#1735
• (fips): Document FIPS apm-server#15878

Checklist

• Vet approach. Is this content heading in the right direction?
• Vet basic structure
  • Broke out ES and KIB for scan-ability
  • Set up structure for scaling as we add more FIPS-compatible deliverables
  • Moved FIPS topic from Deploy and Manage > Security > Secure your cluster or deployment to Deploy and Manage > Security to allow for expansion, SEO, and findability.
• Align on terminology
  • FIPS compliant?
  • FIPS compatible?
  • FIPS mode?
• Add binary location and explain what they're getting (https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/2136/deploy-manage/security/fips-ingest#fips-binaries)
  • User responsibilities
• Redirects for FIPS topic and relocated ES and Kibana topics (if needed)
• Replace "above" and "below" links with more descriptive text (for better SEO ranking and for readability).
  Might happen in another PR.

[simitt]

Thanks @karenzone for the initial architecture; the split into product categories looks good to me.

Left some initial comments, but I will need to spend more time on finding some more user friendly wording for the removed/changed functionality.

As a general guideline, I would suggest we list the removed functionality as limititation, but do not list configuration options that themselves are just not FIPS compliant. We can do an overall callout on these but would keep this separated from functional limitations. I'll provide more thorough suggestions for this.

[tommyers-elastic]

i think it might be good to add a section to the 'FIPS for ingest tools' page for "Integrations".

we have several integrations which are currently not FIPS compatible. calling these out here would avoid suprises for customers who don't learn they're unsupported until they try to install them. we list the equivalent metricbeat modules, so it makes sense to also list the Integrations that depend on them.

you can see which packages are currently not FIPS compatible by checking the for fips_compatible: false in the package manifest file - https://github.com/search?q=repo%3Aelastic%2Fintegrations%20%22fips_compatible%3A%20false%22&type=code

cc @shmsr

[karenzone]

i think it might be good to add a section to the 'FIPS for ingest tools' page for "Integrations".

we have several integrations which are currently not FIPS compatible. calling these out here would avoid suprises for customers who don't learn they're unsupported until they try to install them. we list the equivalent metricbeat modules, so it makes sense to also list the Integrations that depend on them.

@tommyers-elastic @shmsr (and others who are interested):
Does the treatment of the new content make it obvious that we're not guaranteeing that other integrations are compliant--only that we can guarantee that these seven are not?

[tommyers-elastic]

@karenzone by default we are saying that intergrations are compatible. but the boolean flag itself doesn't really make any promises about compliance - this is handled at the beats level (hence 'compatible', not 'compliant'). the flag is really like a hint for fleet so we can say to the customer "hey this integration isn't gonna work because it depends on modules that are not in the FIPS version of agent".

hope that makes sense.

[simitt]

Did another round of review and left some small comments.

[simitt]

@karenzone as just discussed, added some missing imitations.

[karenzone]

@karenzone by default we are saying that intergrations are compatible. but the boolean flag itself doesn't really make any promises about compliance - this is handled at the beats level (hence 'compatible', not 'compliant'). the flag is really like a hint for fleet so we can say to the customer "hey this integration isn't gonna work because it depends on modules that are not in the FIPS version of agent".

hope that makes sense.

Thanks for the suggestion. We worked the content into https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/2136/deploy-manage/security/fips-ingest#ingest-limitations-agent. The query you provided was helpful in compiling the list and links. Thank you!

[simitt]

LGTM - thanks for all the work on putting this together!

[kilfoyle]

LGTM! 🏎️
Very nice work @karenzone!

[karenzone]

Note to reviewers and others who are interested

We are still collecting info and feedback for a quick-follow PR.