As part of FIPS compliance, alternative analyzer docker images will be published. These images are larger and may not be appropriate for all customers. The vendored templates for analyzers need to know whether a customer wants a FIPS image or not.
Proposal
Introduce GITLAB_FIPS_MODE='true' as a GitLab predefined CI variable. This variable will be available in the templates and to the analyzers, and can be used in the vendored templates to switch which image a customer gets. This will allow GitLab to maintain a single vendored template, and also address the need for customers to get a FIPS docker image for each analyzer.
When FIPS mode is not enabled, the variable is missing rather than 'false' (as matches existing CI variable paradigms)
Detecting FIPS mode
This is developing, but other FIPS work can show current methods:
This issue was automatically tagged with the label groupstatic analysis by TanukiStan, a machine learning classification model, with a probability of 1.
If this label is incorrect, please tag this issue with the correct group label as well as automation:ml wrong to help TanukiStan learn from its mistakes.
This message was generated automatically.
You're welcome to improve it.
Certainly sounds useful! We could end up using it to programmatically specify different base images. It's a bit convoluted but something like this should work:
The name CI_FIPS_REQUIRED suggests that this is a predefined variable. As the name implies, these are preset based on various attributes many of which (all?) don't take user input.
a GitLab configuration variable
Where would its value come from?
One thought that I had is that instead of creating a dedicated FIPS variable, we could publish the compliance frameworks applied to the project.
For example, GITLAB_FEATURES is preset with a comma-separated list of features. We could have a CI_COMPLIANCE_FRAMEWORKS or CI_PROJECT_COMPLIANCE_FRAMEWORKS that behave in the same way, but populated via the compliance labels.
The rule that @theoretick suggested would still work, but it would look for FIPS within CI_PROJECT_COMPLIANCE_FRAMEWORKS instead.
Repeating my comment from the other issue which sounds similar to this proposal:
We might look for possibly reusing an instance wide setting instead of introducing a Sec specific toggle. E.g. if the rails monolith ends up having an additional admin setting or a configuration option, we might be able to fetch this and expose it within the CI jobs context (like we can expose enabled features for instance).
@thiagocsf Your are correct that it would be a predefined variable, I've updated the issue description to clarify. I've also updated the variable name to be more inline with what I see in the predefined variables page.
Michael Eddingtonchanged title from Provide CI variable to require FIPS analyzer images to Predefined CI variable to indicate FIPS mode for security analyzers
changed title from Provide CI variable to require FIPS analyzer images to Predefined CI variable to indicate FIPS mode for security analyzers
Michael Eddingtonchanged the descriptionCompare with previous version
I'm not aware of any besides the issues already linked in this thread. Looks like we're all at least on the same page within Sec in this issue. Add a FIPS mode configuration setting (#353009 - closed) in particular was the issue we were referred to last time we asked the broader FIPS group about the process for a user to enable FIPS mode.
I'll mention @twoodham here too, since I know he will want to stay in sync and he drafted a lot of the content at &6479 (closed).
@mikeeddington@sethgitlab - We're not likely to be able to support this soon but it looks like there's already an MR open. Do you need grouppipeline execution to implement or review or other here?
@jheimbuck_gl Validation of our proposal, variable name, and proposed values to would be great in the short term. A review of the MR would also be great when one is available. The referenced MR is not an implementation, just a reference for how fips detection might work.
A couple trivial comments on the implementation to better align it with existing CI variables (if you disagree with any, please feel free to comment on the MR)
Renamed GITLAB_FIPS_MODE to CI_GITLAB_FIPS_MODE (namespacing predefined CI variables)
Changed value from enabled|disabled to true|false (many predefined only appear if enabled, I don't know if we see value in exposing the falsey state)
Thank you @theoretick for creating this MR. It sounds like we're covered here but if there is a need for an additional review of the proposal, please let me know and I can ask a team member to review as well.
Introduce GITLAB_FIPS_MODE=[enabled|disabled] as a GitLab predefined CI variable. This variable will be available in the templates and to the analyzers, and can be used in the vendored templates to switch which image a customer gets.
Introduce GITLAB_FIPS_MODE=[enabled|disabled] as a GitLab predefined CI variable. This variable will be available in the templates and to the analyzers, and can be used in the vendored templates to switch which image a customer gets.
Within groupstatic analysis we had specific issues for introducing a standalone FIPS template (#355518 (closed)) rather than setting it dynamically. Do we have a proposal for how this variable will be used within templates yet?
@theoretick I'm reading !83891 (diffs) correctly, is CI_GITLAB_FIPS_MODE is "true" when FIPS mode is enabled, otherwise it's not set. If that's the case, then we should update this issue to reflect this – I'd be happy to do it.
@fcatteau thanks for the callout. I captured that in the above comment #353523 (comment 893543572) but waited too long for feedback prior to updates. Issue is now accurate!