Allow Filebeat modules to be excluded from FIPS-capable artifacts

[ycombinator]

Proposed commit message

This PR introduces a new type:

type FIPSAwareInput interface {
    IsFIPSCapable() bool
}

Filebeat inputs that wish to report if they are FIPS-capable (or not) are expected to implement this interface. Inputs that do not implement this interface are considered to be FIPS-capable.

For inputs that implement the above interface, FIPS-capable builds of Filebeat will check the input's FIPS-capability. If the input is not FIPS-capable, the input will fail to start with an error message and Filebeat will exit, e.g.:

{"log.level":"error","@timestamp":"2025-06-23T23:50:39.852-0700","log.origin":{"function":"github.com/elastic/beats/v7/libbeat/cmd/instance.handleError","file.name":"instance/beat.go","file.line":1355},"message":"Exiting: Failed to start crawler: starting input failed: input o365audit is not FIPS capable","service.name":"filebeat","ecs.version":"1.6.0"}
Exiting: Failed to start crawler: starting input failed: input o365audit is not FIPS capable

Checklist

• My code follows the style guidelines of this project
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• I have made corresponding change to the default configuration files
• I have added tests that prove my fix is effective or that my feature works
• I have added an entry in CHANGELOG.next.asciidoc or CHANGELOG-developer.next.asciidoc.

Disruptive User Impact

None; the changes in this PR merely allow for Filebeat modules to be excluded from FIPS-capable Filebeat artifacts; there are no modules being excluded in this PR.

How to test this PR locally

$ mage clean && FIPS=true mage build
$ cat <<EOF > filebeat-test.yml
filebeat.inputs:
- type: o365audit
  id: id-nofips
  enabled: true
  application_id: foo
  tenant_id: bar
  client_secret: qux

output.console:
  enabled: true
EOF
$ ./filebeat -c ./filebeat-test.yml -e

[elasticmachine]

Pinging @elastic/elastic-agent-data-plane (Team:Elastic-Agent-Data-Plane)

[github-actions]

🤖 GitHub comments

Expand to view the GitHub comments

Just comment with:

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

[cmacknz]

I don't love that we have to duplicate the input list twice, I think this is going to result in people forgetting to add new modules and inputs to the FIPS file or miss adding them to one of the non-FIPS platform specific files long term. There is a new and indefinite mental burden to maintaining and testing these variations in the Beats.

I think we can deal with this in a simpler way with less overhead. When Filebeat is told to run an input type it doesn't recognize, it just exits with an error. So we should be able to get the same effect by having a FIPS variant of the o365 (and other inputs we want to exclude) exit on startup rather than duplicating the entire input list.

For example if I create the following configuration:

filebeat.inputs:
- type: none
  id: id-none
- type: filestream
  id: my-filestream-id
  enabled: false
  paths:
    - /var/log/*.log

filebeat.config.modules:
  path: ${path.config}/modules.d/*.yml
  reload.enabled: false

setup.template.settings:
  index.number_of_shards: 1

output.elasticsearch:
  hosts: ["localhost:9200"]
  username: "elastic"
  password: "changeme"

This is what Filebeat logs at startup and then exits with a non-zero exit code.

...
{"log.level":"info","@timestamp":"2025-06-19T15:36:10.227-0400","log.logger":"monitoring","log.origin":{"function":"github.com/elastic/beats/v7/libbeat/monitoring/report/log.(*reporter).logTotals","file.name":"log/log.go","file.line":201},"message":"Uptime: 5.16567975s","service.name":"filebeat","ecs.version":"1.6.0"}
{"log.level":"info","@timestamp":"2025-06-19T15:36:10.227-0400","log.logger":"monitoring","log.origin":{"function":"github.com/elastic/beats/v7/libbeat/monitoring/report/log.(*reporter).snapshotLoop","file.name":"log/log.go","file.line":168},"message":"Stopping metrics logging.","service.name":"filebeat","ecs.version":"1.6.0"}
{"log.level":"info","@timestamp":"2025-06-19T15:36:10.227-0400","log.origin":{"function":"github.com/elastic/beats/v7/libbeat/cmd/instance.(*Beat).launch","file.name":"instance/beat.go","file.line":542},"message":"filebeat stopped.","service.name":"filebeat","ecs.version":"1.6.0"}
{"log.level":"error","@timestamp":"2025-06-19T15:36:10.227-0400","log.origin":{"function":"github.com/elastic/beats/v7/libbeat/cmd/instance.handleError","file.name":"instance/beat.go","file.line":1355},"message":"Exiting: Failed to start crawler: starting input failed: error while initializing input: Error creating input. No such input type exist: 'none'","service.name":"filebeat","ecs.version":"1.6.0"}
Exiting: Failed to start crawler: starting input failed: error while initializing input: Error creating input. No such input type exist: 'none'

[cmacknz]

We could go even simpler and just have the inputs log they don't support FIPS and do this with documentation. There is no requirement to exclude non-FIPS functionality from an application, it just helps people see which things are non-compliant more easily.

[efd6]

I'd like to see a simpler approach, and documentation would fit with that. The approach that has been taken has been pretty drastic; any reference to a package that is not FIPS compliant has been banished, even when the relevant part of the package is not called or the call is not in the context of cryptography or security. This approach in beats is at odds with the less draconian approaches used elsewhere.

[belimawr]

I agree with Craig, this should be on the input side, rather than we having to maintain a 'list' FIPS/non-FIPS input used to build Filebeat.

Documentation + having the input refusing to start (maybe even causing Filebeat to exit) looks to be the simplest, more maintainable, option to me.

[ycombinator]

Thanks for the feedback, @cmacknz @efd6 and @belimawr. I will rework this PR to allow FIPS-disabling from within the input so it's not duplicated and make sure its documented for each input as well.

[ycombinator]

@cmacknz @belimawr @efd6, Based on your feedback, I've reworked this PR and updated it's description to match.

Please review this approach and let me know what you think. If you're happy with it, I'll add tests and remove the example o365audit input implementation from this PR and move it to it's own PR, including a doc update for that input.

Thanks!

[belimawr]

LGTM, I like this approach! I just added a couple comments to document exported methods.

[cmacknz]

This is much nicer, my concerns from #44920 (comment) have been addressed. Thank you!

LGTM but I'll defer data plane approval to @belimawr here since he has open comments you don't need my approval specifically.