add flag which indicates if an integration package policy template is FIPS compatible

[tommyers-elastic]

add flag which indicates if an integration package is allowed to be installed in our ECH FedRAMP High environment

[jsoriano]

Have we considered other options for this setting? Maybe we should add a section with lists of supported certifications? To avoid having to add in the future more allowed_in_* variables.

Maybe we could add a section certifications, as a list, something like:

    certifications:
      - fedramp_high

[tommyers-elastic]

this PR is purely to start the discussion, so this suggestion is much appreciated 🙂

this sounds like a good idea. the only issue i have is that disallowed packages will be the exception, not the rule. so i don't want a setting that we need to add to every package. this will likely just be a handful of package that we want to add the flag to to denote that they are not allowed.

[simitt]

I would avoid the term certifications. For the avoidance of doubt, integrations themselves won't be certified, so there is no guarantee about compliance. But certain integrations have known violations and will therefore be excluded by default.
@tommyers-elastic I wonder whether the term fedramp_high or fips or more specific fips-140-2 and fips-140-3 should be used here. And

I also wonder if a simple boolean flag is enough - how does this work if an integration is disabled for fips for a certain version but then made available later? Given that integrations are mostly configs, and the violation more likely lies in some module code of the underlying beat, would it be possible to tie such a change to a beats version?

[tommyers-elastic]

how about

fips:
  compliant: false

or

fips:
  compliant: true
  minimum_agent_version: 1.3

where fips.minimum_agent_version is a required field if fips.compliant is true

[tommyers-elastic]

and if there is no fips.* section, it's assumed to be compliant in all versions

[tommyers-elastic]

i think based on discussions outside of this PR, we don't need to rely on the package to inform us of agent compatibility requirements. do we agree that a boolean is sufficient for now?

i think in the future having more stack compatibility versions would be great for cases like this, but it's not a blocker.

since we only have one field, i think avoiding nesting is preferable, so are we happy with fips_compatible, which defaults to true?

[cmacknz]

Makes sense to me, agree having the default be true is simpler to manage.

[nimarezainia]

Integrations that don't have this flag would then not be assignable to agent policies that contain fips agents.

@cmacknz @kpollich can agents be assigned but left impaired or in an unhelathy state? I don't think blocking enrollment would present the best UX. Imagine if the user doesn't know what has gone wrong and why the agent is not enrolling.

[cmacknz]

Maybe just clearly showing which agents are FIPS vs non-FIPS is enough? It's in the agent metadata so Fleet will be able to tell.

IMO we should just model this after what we did for unprivileged agents where there is a warning in the UI when enrolling but it doesn't stop you.

[kpollich]

Agree - I see this as essentially the same as unprivileged agents and we should make the experience consistent across both cases.

[tommyers-elastic]

based on feedback, i have renamed the flag as discussed above, and moved it into the policy template section.

[elasticmachine]

💚 Build Succeeded

• Buildkite Build
• Commit: ba5c13c

History

• 💚 Build #1126 succeeded e5c7691
• 💚 Build #1125 succeeded 95b0cda