Update FIPS ingest docs for native Go FIPS 140-3 - #7818
Open
macdewee wants to merge 3 commits into
Open
Conversation
- Update framing from FIPS 140-2 (BoringCrypto) to FIPS 140-3 capable with Go's native FIPS module (GOFIPS140=v1.0.0, CMVP cert #5247) - Add EDOT (OpenTelemetry mode) limitations section covering Azure, Kafka, MongoDB, MySQL, SQL Server, Kerberos, API key auth, and GPG upgrade verification - Add sections for Auditbeat, Heartbeat, Packetbeat, and Winlogbeat (single limitation each: Azure/AWS PKCS#12 cert auth not supported) - Remove "OpenTelemetry mode not yet supported" — EDOT is now supported with documented limitations - Scope Fleet-managed integrations list explicitly; cross-reference EDOT - Clean up process language throughout (not yet, currently, for now) - Add TLS minimum key length and scope Kerberos section explicitly Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Contributor
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. |
Contributor
🔍 Preview links for changed docs |
Contributor
✅ 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. |
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
shainaraskas
reviewed
Aug 6, 2026
shainaraskas
left a comment
shainaraskas
left a comment
Member
There was a problem hiding this comment.
in what stack version do we become fips 140-3 compliant? this doc applies to all 9.x versions of the product, so I think we need to rethink how we're editing it so it serves all of our audiences.
adding ski docs as well because they have more ingest context
shainaraskas
reviewed
Aug 6, 2026
Comment on lines
2
to
3
| applies_to: | ||
| deployment: ga |
Member
There was a problem hiding this comment.
spare key here - we need to delete these lines
applies_to:
deployment: ga
shainaraskas
reviewed
Aug 6, 2026
Member
There was a problem hiding this comment.
this needs to be populated (I realize this was before your edits)
| - linking against a FIPS certified cryptographic library | ||
| - using only FIPS approved cryptographic functions | ||
| - ensuring that the configuration of the component is FIPS 140-2 compliant. | ||
| {{agent}}, {{fleet}}, {{filebeat}}, {{metricbeat}}, and {{apm-server}} are FIPS 140-3 capable. They use Go's native FIPS 140-3 module (`GOFIPS140=v1.0.0`, CMVP Certificate [#5247](https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/5247)) for cryptographic operations. Specific components and configurations that fall outside the certified boundary are documented in the limitations sections below. |
Member
There was a problem hiding this comment.
It's been a while since I've seen docs about FIPs, so take my suggestions with a grain of salt. From what I recall, FIPs-capable services or applications are slightly different from FIPs-compatible ones:
- FIPS capable: Underlying architecture supports FIPS encryption standards, but the service/app is not federally certified.
- FIPS compatible: Service/app can communicate with FIPS systems but might not be using FIPS encryption.
I've also seen these terms used interchangeably, so this might be a nitpicky observation on my part. Just wanted to raise this in case it really is something that needs to be consistent across these docs.
| ### TLS [ingest-limitations-tls] | ||
|
|
||
| Only FIPS 140-2 compliant TLS protocols, ciphers, and curve types are allowed to be used as listed below. | ||
| Only FIPS 140-3 compliant TLS protocols, ciphers, and curve types are allowed to be used as listed in the following section. |
Member
There was a problem hiding this comment.
Continuing this comment, FIPS-compliant means something different as well.
| * `TLS v1.2`: `ECDHE-RSA-AES-128-GCM-SHA256`, `ECDHE-RSA-AES-256-GCM-SHA384`, `ECDHE-ECDSA-AES-128-GCM-SHA256`, `ECDHE-ECDSA-AES-256-GCM-SHA384` | ||
| * `TLS v1.3`: `TLS-AES-128-GCM-SHA256`, `TLS-AES-256-GCM-SHA384` | ||
| * The supported curve types are `P-256`, `P-384` and `P-521`. | ||
| * The minimum key length is 2048 bits for RSA keys. EC key size is determined by the curve in use; see the supported curve types above. |
Member
There was a problem hiding this comment.
If you can link the docs that readers should refer to, that'd improve the UX here.
Suggested change
| * The minimum key length is 2048 bits for RSA keys. EC key size is determined by the curve in use; see the supported curve types above. | |
| * The minimum key length is 2048 bits for RSA keys. EC key size is determined by the curve in use. Refer to the supported curve types above. |
| Be sure to enforce security in your FIPS environments through other means, such as strict file permissions and access controls on the key file itself, for example. | ||
|
|
||
| These TLS related restrictions apply to all components listed--{{agent}}, {{fleet}}, {{filebeat}}, {{metricbeat}}, and {{apm-server}}. | ||
| These TLS related restrictions apply to all components listed in the preceding section. |
Member
There was a problem hiding this comment.
Same comment here about linking directly to the relevant docs instead of using directional language. (Only if possible ofc)
| ### General output and input limitations (Kerberos protocol) [ingest-inputoutput-limitations] | ||
|
|
||
| The Kerberos protocol is not supported for any output or input, which also impacts the available `sasl.mechanism` for the Kafka output where only `PLAIN` is supported. | ||
| The Kerberos protocol is not supported for outputs and inputs in Filebeat, Metricbeat, APM Server, and Fleet Server configurations. This also restricts the available `sasl.mechanism` for the Kafka output, where only `PLAIN` is supported. |
Member
There was a problem hiding this comment.
Suggested change
| The Kerberos protocol is not supported for outputs and inputs in Filebeat, Metricbeat, APM Server, and Fleet Server configurations. This also restricts the available `sasl.mechanism` for the Kafka output, where only `PLAIN` is supported. | |
| The Kerberos protocol is not supported for outputs and inputs in {{filebeat}}, {{metricbeat}}, {{apm-server}}, and {{fleet-server}} configurations. This also restricts the available `sasl.mechanism` for the Kafka output, where only `PLAIN` is supported. |
| * The [MySQL](beats://reference/metricbeat/metricbeat-module-mysql.md), [PostgreSQL](beats://reference/metricbeat/metricbeat-module-postgresql.md), [MSSQL](beats://reference/metricbeat/metricbeat-module-mssql.md) and [SQL](beats://reference/metricbeat/metricbeat-module-sql.md) modules are not supported. | ||
| * The [Oracle module](beats://reference/metricbeat/metricbeat-module-oracle.md) is not supported. | ||
|
|
||
| ### Elastic Agent and Fleet Server [ingest-limitations-agent] |
Member
There was a problem hiding this comment.
Suggested change
| ### Elastic Agent and Fleet Server [ingest-limitations-agent] | |
| ### {{agent}} and {{fleet-server}} [ingest-limitations-agent] |
| * Some Elastic Integrations are not FIPS compatible, as they depend on functionality that is not supported for FIPS configuration. In general, when using {{agent}} and {{fleet-server}}, the same restrictions listed previously for {{metricbeat}} and {{filebeat}} modules, inputs, and processors apply. | ||
| * Agent upgrade artifact verification uses GPG signature checking, which is outside Go's certified FIPS module boundary. | ||
|
|
||
| ### Elastic Agent in OpenTelemetry mode (EDOT) [ingest-limitations-edot] |
Member
There was a problem hiding this comment.
Suggested change
| ### Elastic Agent in OpenTelemetry mode (EDOT) [ingest-limitations-edot] | |
| ### {{agent}} in OpenTelemetry mode (EDOT) [ingest-limitations-edot] |
| ### Elastic Integrations that are not FIPS compatible [ingest-limitations-integrations] | ||
|
|
||
| These Elastic Integrations have components that are **not** FIPS compatible, and **cannot** be used in FIPS environments, even if combined with other ingest tools that offer FIPS mode. | ||
| The following Elastic Integrations (Fleet-managed) use cryptographic implementations outside Go's certified FIPS module boundary for core functionality and **cannot** be used in FIPS environments. For EDOT-specific limitations, see [Elastic Agent in OpenTelemetry mode (EDOT)](#ingest-limitations-edot). |
Member
There was a problem hiding this comment.
Suggested change
| The following Elastic Integrations (Fleet-managed) use cryptographic implementations outside Go's certified FIPS module boundary for core functionality and **cannot** be used in FIPS environments. For EDOT-specific limitations, see [Elastic Agent in OpenTelemetry mode (EDOT)](#ingest-limitations-edot). | |
| The following Elastic Integrations (Fleet-managed) use cryptographic implementations outside Go's certified FIPS module boundary for core functionality and **cannot** be used in FIPS environments. For EDOT-specific limitations, refer to [Elastic Agent in OpenTelemetry mode (EDOT)](#ingest-limitations-edot). |
| * **MongoDB receiver**: Not supported in FIPS mode. | ||
| * **MySQL receiver**: Not supported in FIPS mode. | ||
| * **Microsoft SQL Server receiver**: Not supported in FIPS mode. | ||
| * **Kerberos authentication for beat receivers**: Kerberos/GSSAPI authentication for beat receivers (Filebeat receiver, Metricbeat receiver) is not supported. |
Member
There was a problem hiding this comment.
Suggested change
| * **Kerberos authentication for beat receivers**: Kerberos/GSSAPI authentication for beat receivers (Filebeat receiver, Metricbeat receiver) is not supported. | |
| * **Kerberos authentication for beat receivers**: Kerberos/GSSAPI authentication for beat receivers ({{filebeat}} receiver, {{metricbeat}} receiver) is not supported. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Updates the FIPS ingest documentation from the previous BoringCrypto/CGo-based FIPS 140-2 implementation to the current native Go FIPS 140-3 module (
GOFIPS140=v1.0.0, CMVP Certificate #5247). The native Go module changes the compliance model from "component excluded entirely from FIPS builds" to "component available with specific configurations not supported."Key changes:
Pre-publish checklist:
Generative AI disclosure
Tool(s) and model(s) used: Claude Sonnet 4.6 (Claude Code)