Skip to content

FIPS for ingest tools #2136

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 6 commits into
base: main
Choose a base branch
from
Open

FIPS for ingest tools #2136

wants to merge 6 commits into from

Conversation

karenzone
Copy link
Contributor

@karenzone karenzone commented Jul 15, 2025

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

Related:

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
    • User responsibilities
  • Redirects for FIPS topic and relocated ES and Kibana topics

Note to self @karenzone: Relocating ES and Kib might require redirects

Copy link
Contributor

@simitt simitt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.


FIPS mode binaries are available for {{agent}}, {{fleet}}, {{filebeat}}, {{metricbeat}}, {{agentbeat}}, and {{apm-server}}.

The requirements and scope for the listed beats, Elastic Agent, Fleet Server and APM Server are based on FIPS 140 compliance for Elastic Go applications and can be summarized as:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
The requirements and scope for the listed beats, Elastic Agent, Fleet Server and APM Server are based on FIPS 140 compliance for Elastic Go applications and can be summarized as:
Compliance with FIPS 140-2 requires using only FIPS approved / NIST recommended cryptographic algorithms. For the listed beats, Elastic Agent, Fleet Server and APM Server this can be summarized as:


The requirements and scope for the listed beats, Elastic Agent, Fleet Server and APM Server are based on FIPS 140 compliance for Elastic Go applications and can be summarized as:

Linking against a FIPS certified cryptographic library at compile time
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Linking against a FIPS certified cryptographic library at compile time
- Linking against a FIPS certified cryptographic library

The requirements and scope for the listed beats, Elastic Agent, Fleet Server and APM Server are based on FIPS 140 compliance for Elastic Go applications and can be summarized as:

Linking against a FIPS certified cryptographic library at compile time
Only using FIPS approved cryptographic functions at runtime
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Only using FIPS approved cryptographic functions at runtime
- Only using FIPS approved cryptographic functions




### APM Server [fips-apm-server]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remove this as there is nothing APM Server specific listed?

- Only fips compliant TLS options are accepted
- TLSv1.2 is the minimum supported version and validation fails otherwise
- Only compliant ciphers are allowed
- Only compliant curve types are allowed
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remove these

- TLSv1.2 is the minimum supported version and validation fails otherwise
- Only compliant ciphers are allowed
- Only compliant curve types are allowed

- Only compliant curve types are allowed
- TranslateLDAPAttribute Processor is disabled
- For Kafka output, SCRAM SASL is disabled as it was using a custom pbkdf2 functionality
- Non compliant crypto in fingerprint processor is disabled: md5 and sha1 disabled
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- Non compliant crypto in fingerprint processor is disabled: md5 and sha1 disabled

github.com/elastic/beats/v7/libbeat/processors/add_cloud_metadata
github.com/elastic/beats/v7/x-pack/filebeat/input/azureeventhub

We need to let our users know that they need to deploy their agent/beats in a fips environment if they were to use service providers like gcp/azure/mongo in order to be compliant.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This section needs to be rephrased, I'll set some time aside to make suggestions.


We need to let our users know that they need to deploy their agent/beats in a fips environment if they were to use service providers like gcp/azure/mongo in order to be compliant.

More detailed discussion on this issue can be found here elastic/ingest-dev#5039
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
More detailed discussion on this issue can be found here elastic/ingest-dev#5039

@simitt
Copy link
Contributor

simitt commented Jul 17, 2025

@karenzone as discussed, here a more detailed proposal for describing the Limitations (to replace how the limitations are currently listed):

Limitations

TLS

Only FIPS 140-2 compliant TLS protocols, ciphers and curve types can be used.

  • The supported TLS versions are TLS v1.2 and TLS v1.3.
  • The supported cipher suites are:
    • 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.

Support for encrypted private keys is not available, as the cryptographic modules used for decrypting password protected keys are not FIPS validated. If an output or any other component with an SSL key that is password protected is configured, the components will fail to load the key. When running in FIPS mode, non-encrypted keys must be provided.
Ensure to enforce security in your FIPS environments through other means, such as for example strict file permissions and access controls on the key file itself.

These TLS related restrictions apply to all components listed.

General Output & Input 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.

This impacts Filebeat, Metricbeat and APM server, as well as output configurations for Elastic Agent with Fleet Server.

APM Server

Filebeat

Metricbeat

Elastic Agent & Fleet Server

When using Elastic Agent and Fleet Server, the same restrictions as listed above for metricbeat and filebeat modules, inputs and processors apply to the respective Integrations.
Additionally, following limitations apply:

Co-authored by: Silvia Mitter <silvia.mitter@elastic.co>
- id: elastic-agent
- id: fleet
applies_to:
stack: ga 9.1
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure what these GA labels mean; generally we want to have these docs in place for

  • 8.19.0: functionality is in Tech Preview
  • 9.1.0: functionality is in Tech Preview

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here's how we're handing this for 9.1.0:
Screenshot 2025-07-17 at 6 59 14 PM

We'll handle messaging and content for 8.19.0 in a separate PR. I'll add it to our punch list.

Comment on lines 17 to 19
FIPS mode binaries are available for {{agent}}, {{fleet}}, {{filebeat}}, {{metricbeat}}, and {{apm-server}}.

Compliance with FIPS 140-2 requires using only FIPS approved/NIST recommended cryptographic algorithms. For {{agent}}, Fleet Server, the listed {{Beats}}, and APM Server, this can be summarized as:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@karenzone WDYT about replacing with this:

The {{agent}}, {{fleet}}, {{filebeat}}, {{metricbeat}}, and {{apm-server}} binaries are built and can be configured to use FIPS 140-2 compliant cryptography.

Generally speaking FIPS 140-2 requirements can be summarized at:

@tommyers-elastic
Copy link

tommyers-elastic commented Jul 18, 2025

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
Copy link
Contributor Author

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?

@karenzone karenzone marked this pull request as ready for review July 19, 2025 01:49
@karenzone karenzone requested review from a team as code owners July 19, 2025 01:49
@tommyers-elastic
Copy link

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants