-
Notifications
You must be signed in to change notification settings - Fork 88
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
Add buildkite step to run unit tests that require fips provider #4617
base: main
Are you sure you want to change the base?
Add buildkite step to run unit tests that require fips provider #4617
Conversation
Add a buildkite step that runs FIPS=true make test-unit as these tests require msft/go and a FIPS provider.
This pull request is now in conflicts. Could you fix it @michel-laterman? 🙏
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@michel-laterman can you explain what is the goal of this PR is? Maybe I am not seeing what this setup would cover which isn't already covered with:
- Unit tests running with the strict go-1.24 FIPS mode enabled
- Plan to test more involved settings, eg. upgrade, gpg, TLS functionality through system tests with the
platform-ingest-fleet-server-ubuntu-2204-fips
image.
When running unit tests with go-microsoft, it would still fall back to std lib functionality rather than fail if non compliant algorithms are used.
This runs the unit tests with the microsoft/go toolchain that uses the FIPS enabled OpenSSL, this is basically a sanity check that everything will work on the VM and we can start enabling/developing more FIPS related e2e tests |
|
What is the problem this PR solves?
We need to be able to run tests on VMs that have a FIPS provider.
How does this PR solve the problem?
As a PoC, a buildkite step that runs
FIPS=true make test-unit
has been added to run on a new VM. Running this target requires msft/go (gathered by the newwith_msft_go
func added to common.sh) and a FIPS provider (supplied by VM).Design Checklist
I have ensured my design is stateless and will work when multiple fleet-server instances are behind a load balancer.I have or intend to scale test my changes, ensuring it will work reliably with 100K+ agents connected.I have included fail safe mechanisms to limit the load on fleet-server: rate limiting, circuit breakers, caching, load shedding, etc.Checklist
I have commented my code, particularly in hard-to-understand areasI have made corresponding changes to the documentationI have made corresponding change to the default configuration filesI have added an entry in./changelog/fragments
using the changelog tool