Zay Hanlon
bbdd784b73
<!-- Add the related story/sub-task/bug number, like Resolves #123, or remove if NA --> **Related issue:** Resolves # # Checklist for submitter If some of the following don't apply, delete the relevant line. - [ ] Changes file added for user-visible changes in `changes/`, `orbit/changes/` or `ee/fleetd-chrome/changes`. See [Changes files](https://github.com/fleetdm/fleet/blob/main/docs/Contributing/guides/committing-changes.md#changes-files) for more information. - [ ] Input data is properly validated, `SELECT *` is avoided, SQL injection is prevented (using placeholders for values in statements), JS inline code is prevented especially for url redirects, and untrusted data interpolated into shell scripts/commands is validated against shell metacharacters. - [ ] Timeouts are implemented and retries are limited to avoid infinite loops - [ ] If paths of existing endpoints are modified without backwards compatibility, checked the frontend/CLI for any necessary changes ## Testing - [ ] Added/updated automated tests - [ ] Where appropriate, [automated tests simulate multiple hosts and test for host isolation](https://github.com/fleetdm/fleet/blob/main/docs/Contributing/reference/patterns-backend.md#unit-testing) (updates to one hosts's records do not affect another) - [ ] QA'd all new/changed functionality manually For unreleased bug fixes in a release candidate, one of: - [ ] Confirmed that the fix is not expected to adversely impact load test results - [ ] Alerted the release DRI if additional load testing is needed ## Database migrations - [ ] Checked schema for all modified table for columns that will auto-update timestamps during migration. - [ ] Confirmed that updating the timestamps is acceptable, and will not cause unwanted side effects. - [ ] Ensured the correct collation is explicitly set for character columns (`COLLATE utf8mb4_unicode_ci`). ## New Fleet configuration settings - [ ] Setting(s) is/are explicitly excluded from GitOps If you didn't check the box above, follow this checklist for GitOps-enabled settings: - [ ] Verified that the setting is exported via `fleetctl generate-gitops` - [ ] Verified the setting is documented in a separate PR to [the GitOps documentation](https://github.com/fleetdm/fleet/blob/main/docs/Configuration/yaml-files.md#L485) - [ ] Verified that the setting is cleared on the server if it is not supplied in a YAML file (or that it is documented as being optional) - [ ] Verified that any relevant UI is disabled when GitOps mode is enabled ## fleetd/orbit/Fleet Desktop - [ ] Verified compatibility with the latest released version of Fleet (see [Must rule](https://github.com/fleetdm/fleet/blob/main/docs/Contributing/workflows/fleetd-development-and-release-strategy.md)) - [ ] If the change applies to only one platform, confirmed that `runtime.GOOS` is used as needed to isolate changes - [ ] Verified that fleetd runs on macOS, Linux and Windows - [ ] Verified auto-update works from the released version of component to the new version (see [tools/tuf/test](../tools/tuf/test/README.md))
7.2 KiB
How Mollie manages endpoint compliance the same way it ships software
The challenge: an audit that never ends
Mollie is the Dutch fintech behind payment infrastructure used by 250,000 merchants across Europe. The company powers payments for online stores from independent shops to Spotify, and runs on a motto that everyone at Mollie can recite: always be shipping. Speed and quality, every day.
Shipping fast in a regulated European fintech creates a quieter obligation behind the scenes. PCI DSS, SOC 2, the Dutch National Bank, and EU resilience rules under DORA all require Mollie to prove the controls on every endpoint, every day, on demand. An audit, at its core, is straightforward: tell us what you do, show us how you do it, and prove you are doing it that way. The hard part is the proof - getting an accurate sample of the entire device population, with confidence, every time.
Compliance as code is really why we were attracted to Fleet. Endpoint is very scrutinized in audit - access management, controls, least privileged application usage. All of this can be demonstrated in code from an endpoint perspective.
Sam Clark
Senior Infrastructure Manager
For Mac, Mollie had Jamf. For Linux, which a growing share of engineers preferred, there was no real solution. Canonical Landscape gave Mollie some basic management, but not the depth or the visibility required to demonstrate PCI compliance for developers with access to cardholder data. Mollie needed a Linux platform that could run policies and scripts on demand, prove device state to an auditor, and remediate drift without manual intervention.
If Mollie ships software through code review, automation, and version control, the device fleet running that engineering needs to be managed the same way. A regulated fintech cannot run compliance through clickops.
We only have a daily recon for Jamf. To get data off a device through Fleet is much quicker - we can choose granularity down to five minutes. It gives us insight into the device we didn’t otherwise have.
Jacob Burley
Staff Engineer
EU data residency made the choice clear. As a fintech under DNB and DORA oversight, Mollie must host its critical infrastructure in Europe and answer for vendor lock-in as part of business continuity. Fleet’s self-hosting model meant Mollie could run the platform in its own GCP environment, on Kubernetes, with its own cloud identity and service account model. No sub-processor reviews. No reliance on a US vendor’s data residency roadmap. No feature gap between a SaaS edition and an on-prem one.
Being able to self-host Fleet means we're not locked in and can stay in control of our own resiliency, which is huge in the EU for fintechs. You have to answer for business continuity. Knowing there are real options out there gives a lot of peace of mind.
Sam Clarke
Senior Infrastructure Manager
The outcome: control, on Mollie’s terms
Fleet now sits at the center of Mollie’s endpoint compliance program. The team manages its Linux end-user devices on Fleet Premium, and runs Fleet’s community edition alongside Jamf on Mac to ship osquery telemetry into BigQuery for security reporting.
With Fleet, Mollie has:
- Linux device management that meets PCI requirements for developers with access to cardholder data
- Compliance policies versioned in Git, peer-reviewed, and deployed the same way Mollie ships product code
- Near real-time visibility into device state, with query granularity down to five minutes, instead of waiting on a daily recon
- Self-healing drift remediation, with signed policies enforced locally on each endpoint, even when air-gapped
- Fleet running on Mollie’s own GCP infrastructure in Europe, meeting DNB and DORA requirements without a third-party sub-processor in the path
What changed is not just the tooling. The IT team now operates the way Mollie’s product engineers operate: in code, in version control, in the same review and deployment workflow that built the rest of the business. Compliance is no longer a clickops problem.
Looking ahead
Mollie continues to expand its use of Fleet - new policy webhooks feeding real-time non-compliance alerts into Slack, deeper integration with platform SSO rollouts on Mac, and pull requests back to the project where the team needs something the wider community will benefit from too.
For a regulated EU fintech that has to prove compliance every day, the appeal of Fleet is in what it is not: not a black box, not a SaaS-only option, not a vendor that decides Mollie’s roadmap for it. Fleet is the platform Mollie controls, on infrastructure Mollie owns, working the way Mollie builds software.