bfc986df7e5117e2ebdd61589d908da2e4a58dab
154
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
|
|
19aac451e1 |
Fix Windows CSP bypass issue (#48843)
<!-- Add the related story/sub-task/bug number, like Resolves #123, or remove if NA --> **Related issue:** Resolves #48752 Stacked PR. Needs 48349-windows-modify branch to merge first. # Checklist for submitter If some of the following don't apply, delete the relevant line. - [x] 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. ## Testing - [x] Added/updated automated tests - [x] QA'd all new/changed functionality manually <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit ## Summary by CodeRabbit * **Bug Fixes** * Fixed a Windows MDM loophole where scope-less or differently formatted `LocURI` values could bypass Fleet restrictions. * Strengthened detection and enforcement for reserved Windows targets, including OS updates, remote wipe premium gating, and BitLocker restrictions. * Improved `LocURI` handling to be resilient to whitespace and alternate formatting, including more consistent SCEP profile processing. * **Tests** * Added regression coverage for reserved `LocURI` matching, OS-update targeting, and premium detection for wipe commands (including scope-less cases). <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
|
7b950c64a6 |
Add duplicate patch policy check to GitOps (#48896)
<!-- Add the related story/sub-task/bug number, like Resolves #123, or remove if NA --> **Related issue:** Resolves #46193 Adds a client-side check for duplicate patch policies, similar to the existing policy name and label duplicate checks. # Checklist for submitter If some of the following don't apply, delete the relevant line. - [x] 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 - [x] 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) - [x] QA'd all new/changed functionality manually Adding two patch policies for the same fma slug results in this error: ``` Error: 1 error occurred: * Couldn't add multiple policies with type "patch" for "fleet_maintained_app_slug": "google-chrome/darwin". ``` <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Added validation to GitOps application checks to prevent multiple patch policies from targeting the same app slug. * Improved error reporting when patch policy slugs are duplicated or missing from the configured app list. * **Bug Fixes** * Prevented duplicate patch policies from being silently accepted, reducing the risk of one policy overwriting another. * Existing valid combinations, such as different patch slugs or certain mixed policy types, continue to work as expected. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
|
8cf1796a7d |
Support advanced options for script-only packages (#48315)
**Related issue:** Resolves #42797 Adds support for pre-install query, post-install script, and uninstall script on script-only packages (`.sh` and `.ps1`) across the API, UI, and GitOps; previously these were silently stripped. The install script remains the uploaded file's contents (file-driven) and is shown read-only. Automatic install stays unsupported for script-only packages. - **API** (`POST`/`PATCH /software/package`): stop stripping the fields; validate post-install and uninstall scripts for script packages - **GitOps**: allow `uninstall_script`/`post_install_script`/`pre_install_query` paths inline in the team YAML for script-only packages - **UI**: show advanced options for `.sh`/`.ps1`; install script shown read-only # Checklist for submitter - [x] Changes file added for user-visible changes in `changes/`. - [x] 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. ## Testing - [x] Added/updated automated tests - [x] QA'd all new/changed functionality manually <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Script-only packages (`.sh`/`.ps1`) now expose advanced options—pre-install query, post-install script, and uninstall script—consistently across the UI, REST API, and GitOps. * Script-only packages display advanced options in the UI, and the “Install script” editor can be made read-only where appropriate. * **Bug Fixes** * Preserved advanced option values for script-only packages during upload, edits, and synchronization (including replace-file scenarios). * Improved YAML generation and validation so supported fields are included while unsupported ones are correctly rejected/omitted. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
|
e14f6e67c1 |
fix gitops relative paths for unassigned and org_settings (#47512)
<!-- Add the related story/sub-task/bug number, like Resolves #123, or remove if NA --> **Related issue:** Resolves #45661 I couldn't really find another good solution that would solve it all, as the path resolution is spread out, plus unassigned merging into global config definitely makes it more complex (root cause of the issue). # Checklist for submitter If some of the following don't apply, delete the relevant line. - [x] 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. - [x] 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. - [x] Timeouts are implemented and retries are limited to avoid infinite loops - [x] If paths of existing endpoints are modified without backwards compatibility, checked the frontend/CLI for any necessary changes ## Testing - [x] Added/updated automated tests - [x] QA'd all new/changed functionality manually <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Bug Fixes** * Fixed GitOps relative path resolution so controls and nested organization settings correctly resolve referenced files from their source directory, including cases with `unassigned.yml`. * Corrected macOS setup assistant uploads to use the base filename instead of the full configured path/URL. * **Tests** * Added regression coverage for GitOps relative path handling across working-directory and nested-file scenarios. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
|
dcf5029da5 |
BYOF: API & GitOps support (#47506)
<!-- Add the related story/sub-task/bug number, like Resolves #123, or remove if NA --> **Related issue:** Resolves #45600 I could see the contributor endpoint was not updated, so I just included it in this PR, and since it's a contributor one I think we are fine updating ahead of release. # 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. (Part of previous PR) - [x] 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. - [x] Timeouts are implemented and retries are limited to avoid infinite loops - [x] If paths of existing endpoints are modified without backwards compatibility, checked the frontend/CLI for any necessary changes ## Testing - [x] Added/updated automated tests - [x] QA'd all new/changed functionality manually <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit ## Release Notes * **New Features** * Added support for Apple Business Manager BYOD team assignments, including saving/loading BYOD default team selections and exposing BYOD team details via the API for personal mobile devices. * **Refactor** * Updated GitOps key handling for BYOD assignments to use `byod_fleet`, with migration/aliasing from the older `byod_team` key. * **Tests** * Expanded GitOps and ABM token tests/fixtures to cover BYOD team behavior, including defaults, clearing/reset behavior, and error/validation scenarios. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
|
0e9b27fd3c |
validate os updates and os profiles on dry-run for empty setup (#47408)
<!-- Add the related story/sub-task/bug number, like Resolves #123, or remove if NA --> **Related issue:** Resolves #47364 Unreleased bug for 4.87 - [x] QA'd all new/changed functionality manually <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Bug Fixes** * Enhanced validation to detect and prevent conflicting OS update configurations when both managed updates and custom configuration profiles attempt to manage OS updates. * **Tests** * Added automated tests covering detection of conflicts between managed OS updates and configuration profile contents for macOS/iOS and Windows. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> |
||
|
|
89b2a5e470 |
Change self-service categories GitOps to not require dedicated key (#47439)
<!-- 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. - Not needed - [ ] 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 - [x] 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) - [x] QA'd all new/changed functionality manually <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Batch software installer and app-association endpoints now return the list of referenced self-service categories. * Category fields support an “omit when unset” JSON behavior so omitted vs empty categories are distinguishable. * **Bug Fixes** * Improved category validation (trim + case-insensitive dedupe) and GitOps reconciliation to remove unused categories. * **Chores** * GitOps schema simplified: no separate top-level self_service_categories; categories are defined inline with packages. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
|
ffbbb9e866 |
Validate SSO settings correctly for GitOps (#46487)
<!-- Add the related story/sub-task/bug number, like Resolves #123, or remove if NA --> **Related issue:** Resolves #43371 # Details * Ensures that if `enable_sso: true` is set in a global config, then all required sso keys (`entity_id`, `idp_name` and one of `metadata`/`metadata_url`) are provided * Ensures that if `end_user_authentication: true` is set on a fleet, then all required sso keys (`entity_id`, `idp_name` and one of `metadata`/`metadata_url`) are provided, _even if the fleet's config file is not provided in the gitops run_. * Ensures that if `end_user_authentication: true` is set in a fleet config in a gitops run, then all required sso keys (`entity_id`, `idp_name` and one of `metadata`/`metadata_url`) are provided, _even if the global config file is not provided in the gitops run_. # Checklist for submitter If some of the following don't apply, delete the relevant line. - [X] 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. ## Testing - [X] Added/updated automated tests - [X] QA'd all new/changed functionality manually ### Org SSO — gitops client validation (`fleetctl gitops`) - [x] `enable_sso: true` with **empty `metadata` and `metadata_url`** → fails (metadata-or-url) - [x] `enable_sso: true` with **empty `idp_name`** → fails (idp_name) - [x] `enable_sso: true` with **empty `entity_id`** → fails (entity_id) - [x] Multiple fields missing at once → **one error line per missing field** - [x] `enable_sso: true` + complete IdP (`metadata_url`) → succeeds - [x] `enable_sso: true` + complete IdP using inline `metadata` (no url) → succeeds - [x] `enable_sso: false` + empty IdP fields → succeeds - [x] `sso_settings` key **omitted entirely** → succeeds, and apply **clears** stored SSO - [x] The literal `generate-gitops` output (`metadata: # TODO: ...`) applied as-is → **rejected** ### MDM EUA — gitops group cross-file validation - [x] Team file enables EUA **+** global file **omits** the EUA IdP block → fails - [x] **#43371 core repro:** stored team EUA on, file NOT in run, global-only run blanks metadata → fails, names the team - [x] Same but the team's file **is** in the run with EUA `false` → succeeds - [x] EUA disabled everywhere + **empty** stored IdP → succeeds ### `--delete-other-fleets` - [x] Run with `--delete-other-fleets` degrading the IdP while a stored not-in-run team has EUA on → succeeds - [x] Confirm the omitted team is actually deleted on apply - [x] Known corner: `--delete-other-fleets` + omitted ABM/VPP team with EUA on + degraded IdP → fails at apply time ### Server-side backstop (REST API) - [x] `PATCH /config` (overwrite=false), `enable_sso:true`, metadata omitted, existing has metadata → **200**, metadata preserved - [x] `PATCH /config?overwrite=true`, `enable_sso:true` + empty metadata/url → **422** field `metadata` - [x] `?overwrite=true`, metadata_url set, empty `entity_id`/`idp_name` → **422** both `required` - [x] `?overwrite=true`, `enable_sso:false` → **200** (no IdP required when disabled); `sso_settings` omitted entirely → clears (covered by gitops POS-2) ### Server-side EUA (`euaStrict` keyed on incoming global flag only) - [x] `?overwrite=true` + incoming **global** EUA enabled + incomplete IdP → **422** `entity_id`/`idp_name` - [x] `?overwrite=true` + global EUA **off** + stored team EUA + payload degrades IdP → **succeeds** (via gitops #43371-OVERRIDE) - [x] `?overwrite=true` + global EUA off + payload **fully clears** IdP while a team has EUA → **422** `end_user_authentication` (IsEmpty guard) ### Regression / false-positive guards - [x] Multi-file gitops `--dry-run` configuring IdP AND enabling team EUA (empty stored IdP) → dry-run passes (EE dry-run skip) - [x] A previously-working gitops run with a complete SSO/EUA config → still applies cleanly ### End state verification - [x] After any **rejected** run, stored SSO/EUA config **unchanged** - [ ] After a valid complete-IdP run, SSO login + ADE/EUA enrollment works end-to-end (live device) <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Bug Fixes** * GitOps now validates SSO and MDM end-user authentication (EUA) configs before applying changes, rejecting incomplete settings when SSO/EUA are enabled globally or for any team. Overwrite (GitOps) mode enforces stricter validation than standard updates; dry-run behavior adjusted to avoid spurious EUA rejections. * **Tests** * Added comprehensive tests covering SSO/EUA validation, overwrite vs patch semantics, cross-file EUA scenarios, and delete-other-fleets behavior. * **Refactor** * Reorganized validation and config-parsing helpers for reuse in GitOps checks. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Lucas Manuel Rodriguez <lucas@fleetdm.com> |
||
|
|
e34126ab3a |
Merge branch 'main' of github.com:fleetdm/fleet into feat/39018-self-service-categories
Bump migration, fix failing test and nilaway check |
||
|
|
a3338d032e |
Self service categories - GitOps support (#46671)
<!-- Add the related story/sub-task/bug number, like Resolves #123, or remove if NA --> **Related issue:** Resolves #46392 A few things in this PR: - updated the conversion from old default category to the new ones with the emoji included that was introduced in the feature branch. It takes into account what exists in the database now so if an admin wants to add for example "Productivity" without the emoji as a category it won't get overwritten. - updated a few places to ignore missing categories rather than error (what we do for adding a single FMA currently) - updated permissions for "gitops" users - added everything needed for gitops, generate-gitops support using the existing endpoints from the last PR. Didn't add logs like "[+] applied X self service categories" since it wasn't mentioned in the docs, but wouldn't be too hard to add. # Checklist for submitter ## Testing - [x] 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) - [x] QA'd all new/changed functionality manually ## New Fleet configuration settings - [x] Verified that the setting is exported via `fleetctl generate-gitops` - [x] 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) - [x] 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 - Currently missing, at least on this branch |
||
|
|
356caea6fd |
42508 Rename abm to ab in API (#46657)
<!-- Add the related story/sub-task/bug number, like Resolves #123, or remove if NA --> **Related issue:** Resolves #42508 Renames abm/apple_business_manager to ab/apple_business in API and fleetctl. Uses existing renameto logic with a slight twist: added "inline" option to handle cases particularly where a single object tree has renames in multiple versions so that we don't break backwards compatibiility since the default behavior when you have multi-level renames is a new/old split at the top level # Checklist for submitter If some of the following don't apply, delete the relevant line. - [x] 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. - [x] 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. - [x] Timeouts are implemented and retries are limited to avoid infinite loops - [x] If paths of existing endpoints are modified without backwards compatibility, checked the frontend/CLI for any necessary changes ## Testing - [x] Added/updated automated tests - [x] 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) - [x] QA'd all new/changed functionality manually <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Canonical Apple Business (AB) API endpoints and CLI: /api/v1/fleet/ab_tokens, /api/v1/fleet/mdm/apple/ab_public_key, plus new fleetctl get mdm-ab and fleetctl generate mdm-ab * New GitOps/config key: mdm.apple_business * Admin UI updated to show Apple Business tokens with fleet-based associations and updated labels * **Deprecations** * Legacy ABM endpoints, CLI aliases, and config keys remain supported but emit deprecation warnings pointing to the new AB equivalents <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
|
6d004b98bc |
Update error message in GitOps when unknown env vars are encountered (#46476)
<!-- Add the related story/sub-task/bug number, like Resolves #123, or remove if NA --> **Related issue:** Resolves #44053 # Checklist for submitter If some of the following don't apply, delete the relevant line. - [X] 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. ## Testing - [X] Added/updated automated tests - [X] QA'd all new/changed functionality manually <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Bug Fixes** * Error messages for undefined environment variables in GitOps configurations now include clearer, actionable guidance with examples of how to escape literal dollar-sign syntax (e.g., showing escaped forms). This improves clarity when a variable is missing and helps users distinguish between intended variable references and literal values, reducing confusion. <!-- review_stack_entry_start --> [](https://app.coderabbit.ai/change-stack/fleetdm/fleet/pull/46476?utm_source=github_walkthrough&utm_medium=github&utm_campaign=change_stack) <!-- review_stack_entry_end --> <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
|
1072c852e8 |
Added support for validating Microsoft Entra v2 access tokens (#46416)
<!-- Add the related story/sub-task/bug number, like Resolves #123, or remove if NA --> **Related issue:** Resolves #46388 Video demo: https://www.youtube.com/watch?v=t3yuGh0kwP8 Docs PR: https://github.com/fleetdm/fleet/pull/46483 # Checklist for submitter If some of the following don't apply, delete the relevant line. - [x] Changes file added for user-visible changes in `changes/`, `orbit/changes/` or `ee/fleetd-chrome/changes`. - [x] 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. ## Testing - [x] Added/updated automated tests - [x] QA'd all new/changed functionality manually ## Database migrations - [x] Checked schema for all modified table for columns that will auto-update timestamps during migration. - [x] Confirmed that updating the timestamps is acceptable, and will not cause unwanted side effects. ## New Fleet configuration settings If you didn't check the box above, follow this checklist for GitOps-enabled settings: - [x] Verified that the setting is exported via `fleetctl generate-gitops` - [x] 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) - [x] 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) - [x] Verified that any relevant UI is disabled when GitOps mode is enabled <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * UI to add/remove Entra application (client) IDs for Windows automatic enrollment; add/delete modals and list management. * **Enhancements** * Activity feed entries for added/removed Entra client IDs. * Entra client ID allowlist surfaced in GitOps and persisted config; client IDs normalized (trim/lowercase) and de-duplicated. * **Documentation** * Note: from July 1, 2026 new on‑prem Windows MDM apps receive Entra v2 tokens with aud = client ID; v1 tokens remain supported. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
|
64f601891e |
Fix fleetctl apply ignoring spec.fleet (#44894)
**Related issue:** Resolves #44892 Claude also added tests, since this wasn't covered before, but I've kept them in a separate commit in case they're not needed. # Checklist for submitter ## Testing - [x] Added/updated automated tests - [ ] QA'd all new/changed functionality manually <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Bug Fixes** * Improved spec parsing to correctly accept resources declared as either team or fleet, handling nested spec keys consistently and preserving backward-compatible behavior. * **Tests** * Added and updated tests and fixtures to validate parsing across both team/fleet variants and to assert specific conflict/reporting behavior when both keys are present. <!-- review_stack_entry_start --> [](https://app.coderabbit.ai/change-stack/fleetdm/fleet/pull/44894?utm_source=github_walkthrough&utm_medium=github&utm_campaign=change_stack) <!-- review_stack_entry_end --> <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Scott Gress <scott@fleetdm.com> |
||
|
|
484adf3494 |
Fix GitOps policy install software parse function setting the wrong FMA slug field. (#46167)
<!-- Add the related story/sub-task/bug number, like Resolves #123, or remove if NA --> **Related issue:** Resolves #46164 The policy does parse correctly into a GitOpsPolicySpec struct, but because there were two fields called `fleet_maintained_app_slug` it wasn't obvious that this would happen. # Checklist for submitter If some of the following don't apply, delete the relevant line. - [x] 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. ## Testing - [x] 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) - [x] QA'd all new/changed functionality manually <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Bug Fixes** * Fixed an issue where patch policies with different software application slugs were incorrectly using the slug from the install automation setting instead of the patch policy's own configured slug, causing incorrect policy queries and validation. <!-- review_stack_entry_start --> [](https://app.coderabbit.ai/change-stack/fleetdm/fleet/pull/46167?utm_source=github_walkthrough&utm_medium=github&utm_campaign=change_stack) <!-- review_stack_entry_end --> <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
|
4676042542 |
Update note about no-teams -> unassigned (#45486)
On my Fleet instance, "No team" was automatically named "Unassigned" in the UI. If this isn't the case for a user, they need to rename the fleet in the UI first, before changing the name in git. Reference: https://github.com/fleetdm/fleet/blob/main/docs/Configuration/yaml-files.md#:~:text=When%20renaming%20a,g.%20software%20packages > When renaming a fleet, first update the name in the UI, then update your YAML. # Checklist for submitter ## Testing - [ ] Added/updated automated tests - [ ] QA'd all new/changed functionality manually <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Updated deprecation warning message for legacy configuration files to provide clearer migration instructions, guiding users to update fleet names and rename files to align with new naming conventions. <!-- review_stack_entry_start --> [](https://app.coderabbit.ai/change-stack/fleetdm/fleet/pull/45486) <!-- review_stack_entry_end --> <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
|
c77d1b4ff4 |
allow gitops mode to be set in yaml (#45537)
<!-- Add the related story/sub-task/bug number, like Resolves #123, or remove if NA --> **Related issue:** Resolves #45330 # Checklist for submitter If some of the following don't apply, delete the relevant line. - [X] 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. ## Testing - [X] Added/updated automated tests so many - [X] QA'd all new/changed functionality manually - [X] was able to set gitops mode to enabled via `fleetctl gitops` - [X] attempting to set gitops mode w/out repository_url in `fleetctl gitops` failed w/ helpful error - [X] attempting to set gitops mode w/ invalid repository_url in `fleetctl gitops` failed w/ helpful error - [X] attempting to set gitops exceptions in `fleetctl gitops` failed w/ helpful error - [X] was able to unset gitops mode via `fleetctl gitops` - [X] leaving `gitops:` blank in `fleetctl gitops` left the mode untouched (it would retain its previous value) ## 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` it is not, but it's not a requirement here and leaving it out is a no-op - [x] 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) it is not, nor should it be, as that would clear gitops mode on every customer currently using it - [ ] Verified that any relevant UI is disabled when GitOps mode is enabled n/a, you still need to be able to do gitops mode in the UI <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * GitOps mode and repository URL can now be set via GitOps YAML. * **Bug Fixes** * Server preserves existing GitOps settings during config updates; requires repository URL when enabling and rejects unsupported exceptions in GitOps YAML. * **Tests** * Added tests covering apply behavior, YAML validation, activity emission on mode changes, and license-restricted rejection on free tier. <!-- review_stack_entry_start --> [](https://app.coderabbit.ai/change-stack/fleetdm/fleet/pull/45537) <!-- review_stack_entry_end --> <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
|
55636b3ef6 |
iOS/iPadOS managed config: GitOps (#43969) (#44933)
Part of #38790. Stacked on top of #44932. Closes #43969. `fleetctl gitops` reads `configuration.path` for iOS / iPadOS VPP apps and in-house `.ipa` apps, validates the file via `fleet.ValidateAppleAppConfiguration`, and stores the bytes through the service layer. `fleetctl generate-gitops` emits `configuration.path` for apps that have a stored configuration, writing the XML to `lib/<team>/software/<app-slug>-config.xml`. Apps without configuration omit the block entirely. Round-trip integration tests (`cmd/fleetctl/integrationtest/gitops/software_test.go`) cover apply + generate for both VPP and in-house, plus a negative case for invalid configuration content. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit ## Release Notes * **New Features** * Added managed app configuration support for enterprise software deployments through GitOps * Configurations now support platform-specific formats: XML for iOS/iPadOS, JSON for Android * Configuration validation ensures compatibility and prevents invalid variable references * **Tests** * Added integration tests for configuration handling in software deployment workflows [](https://app.coderabbit.ai/change-stack/fleetdm/fleet/pull/44933) <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: jkatz01 <yehonatankatz@gmail.com> |
||
|
|
fe16654729 |
Allow glob literals in filenames (#44547)
<!-- Add the related story/sub-task/bug number, like Resolves #123, or remove if NA --> **Related issue:** Resolves #43598 # Checklist for submitter If some of the following don't apply, delete the relevant line. - [X] 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. ## Testing - [X] Added/updated automated tests - [X] QA'd all new/changed functionality manually - [X] added a script file `some-*-script[].sh` and referred to it in a gitops file using `path:`. Failed on main; on this branch it successfully uploaded the script - [X] still got expected error message when using `path: ` with a value that had glob characters that _didn't_ match an actual file - [X] `paths:` still worked and uploaded multiple files, including `some-*-script[].sh` <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Bug Fixes** * Fixed path validation in fleetctl gitops so path values containing glob metacharacters (e.g., brackets, asterisks, question marks) are accepted when a literal file with that name exists on disk; missing files still produce the appropriate error. * **Tests** * Added regression tests covering glob metacharacter handling in path validation. [](https://app.coderabbit.ai/change-stack/fleetdm/fleet/pull/44547) <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
|
c7364d555c |
Officially deprecated setup_experience.software (#44549)
<!-- Add the related story/sub-task/bug number, like Resolves #123, or remove if NA --> **Related issue:** Resolves #42503 # Checklist for submitter If some of the following don't apply, delete the relevant line. - [X] 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. ## Testing - [X] Added/updated automated tests - [X] QA'd all new/changed functionality manually - [X] setting `software:` under `macos_setup` or `setup_experience` triggers the expected warning. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Deprecations** * Using setup_experience.software or macos_setup.software now emits a deprecation warning. Migrate by setting setup_experience: true on individual software items (packages, App Store apps, or fleet-maintained apps). * **Tests** * Added test coverage to verify the deprecation warning is emitted when applicable and absent otherwise. [](https://app.coderabbit.ai/change-stack/fleetdm/fleet/pull/44549) <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com> |
||
|
|
348fa47c84 |
Improve name key validation in GitOps (#44553)
<!-- 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. - [X] 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. ## Testing - [X] Added/updated automated tests - [X] QA'd all new/changed functionality manually - [X] omitted `name:` from a file without `org_settings:`, got: ``` * No `name` was provided in /tmp/testback/fleets/third-fleet.yml. If this file is intended to define org-level settings, add `org_settings:` as a top-level key. Otherwise, use `name` to specify the fleet name. ``` - [X] omitted `name:` from a file with `org_settings:`, got no error. - [X] omitted `name:` from `no-team.yml`, got: ``` * `name` must be `No Team` for `no-team.yml` ``` - [X] omitted `name:` from `unassigned.yml`, got: ``` * `name` must be `Unassigned` for `unassigned.yml` ``` <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Bug Fixes** * Improved error messages when GitOps YAML files omit the required `name` field, with specific remediation guidance tailored to each configuration file type * Enhanced validation error messaging when top-level `org_settings` is missing or incorrectly placed, providing clearer instructions on required YAML structure <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
|
f5c59ae3b4 |
Fix google calendar key validation (#44556)
<!-- Add the related story/sub-task/bug number, like Resolves #123, or remove if NA --> **Related issue:** Resolves #42886 # Checklist for submitter If some of the following don't apply, delete the relevant line. - [X] 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. ## Testing - [X] Added/updated automated tests - [X] QA'd all new/changed functionality manually - [X] gitops run with extra keys (besides `client_email` and `private_key` in `api_key_json` fails on main, passes on this branch - [X] gitops run with missing `client_email` or `private_key` in `api_key_json` still fails gitops (including dry run) - [X] gitops run with extra keys sibling to api_key_json still fails as expected <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Bug Fixes** * Corrected GitOps validation so Google Calendar API key JSON no longer rejects valid nested keys; required-field validation for the integration still enforced. * **Tests** * Added test coverage to ensure nested unknown keys are accepted while sibling-level unknown fields are reported as validation errors. [](https://app.coderabbit.ai/change-stack/fleetdm/fleet/pull/44556) <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> Co-authored-by: Tim Lee <timlee@fleetdm.com> |
||
|
|
89517cce2f |
Warn when labels key appears in no-team/unassigned GitOps files (#44865)
Closes #42522 ## Changes When `labels:` appears in a no-team/unassigned GitOps file, log a warning and skip label parsing. This matches the existing pattern used by `agent_options` and `reports` in no-team files. A warning (not an error) is used intentionally to avoid breaking existing customer GitOps pipelines that may already have `labels:` in their no-team file. **After fix:** ``` [!] 'labels' is not supported in unassigned.yml. This key will be ignored. ``` ## Testing ### Manual testing Built `fleetctl` from the fixed branch against a local Fleet server (premium license). | Scenario | Result | |---|---| | `unassigned.yml` dry-run | Warning printed, succeeds | | `unassigned.yml` real run | Warning printed, succeeds | | `no-team.yml` dry-run | Warning printed, succeeds | | `no-team.yml` real run | Warning printed, succeeds | | `unassigned.yml` without labels | No warning, succeeds (no regression) | ### Unit tests - **`TestLabelsIgnoredInNoTeamFile`**: Sub-tests for both `no-team.yml` and `unassigned.yml` assert: (1) no error, (2) `LabelsPresent` is true, (3) no labels parsed, (4) warning logged. --------- Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> |
||
|
|
c85d40636e |
Fix gitops controls set criteria (#45007)
<!-- Add the related story/sub-task/bug number, like Resolves #123, or remove if NA --> **Related issue:** Resolves #NA Found this while just browsing the codebase and testing some gitops stuff. # Checklist for submitter If some of the following don't apply, delete the relevant line. - [x] 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. - [x] 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. - [x] Timeouts are implemented and retries are limited to avoid infinite loops - [x] If paths of existing endpoints are modified without backwards compatibility, checked the frontend/CLI for any necessary changes ## Testing - [x] QA'd all new/changed functionality manually <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Bug Fixes** * Fixed GitOps controls detection to correctly identify when controls are set with specific configurations, including BitLocker PIN requirements. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
|
1c522097d0 |
Fix missing GitOps label validation for invalid field combinations (#44410)
**Related issue:** Closes #34229 - [x] 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. - [x] 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. ## Testing - [x] Added/updated automated tests - [x] QA'd all new/changed functionality manually --- `fleetctl gitops` silently accepted labels with invalid parameter combinations (e.g. manual labels with query/criteria/platform). Added per-type field validation in a centralized `fleet.ValidateLabelMembershipFields` function, called from the GitOps parser, `ApplyLabelSpecs`, and `NewLabel`. | Type | Allowed | Now rejects | |------|---------|-------------| | `manual` | `name`, `description`, `hosts` | `query`, `criteria`, `platform` | | `dynamic` | `name`, `description`, `query`, `platform` | `criteria`, `hosts`; validates platform value | | `host_vitals` | `name`, `description`, `criteria` | `query`, `platform`, `hosts` | ### Automated tests - `TestLabelInvalidFieldCombinations` in `pkg/spec/gitops_test.go` — 17 sub-tests covering every invalid combination per label type, plus 3 valid happy-path cases. - `TestNewLabelFieldValidation` in `server/service/labels_test.go` — 4 cases for NewLabel validation. - `TestApplyLabelSpecsManualLabelNilHosts` — 10 sub-cases for ApplyLabelSpecs field validation. - `TestWhenCreatingNewLabelsPlatformIsValidated` — platform validation across NewLabel and ApplyLabelSpecs. All existing `pkg/spec` and `server/service` label tests pass. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Bug Fixes** * Labels now reject invalid field combinations for manual, dynamic, and host_vitals types with clear error responses instead of failing silently. * **Tests** * Added comprehensive tests covering valid and invalid label configurations across membership types. * **Documentation** * Changelog entry describing the behavioral fix. * **Chores** * Removed an unnecessary platform constraint from a label configuration. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --- ### Manual test results Ran against a local Fleet server with the built binary. **API - NewLabel (POST /api/latest/fleet/labels)** | Test | Input | Expected | Result | |------|-------|----------|--------| | 1 | manual + platform=darwin | 422, field=`platform` | PASS | | 2 | dynamic + platform=invalidplatform | 422, field=`platform` | PASS | | 3 | dynamic + platform=darwin + query | 200 | PASS | | 4 | manual (no platform) | 200 | PASS | | 5 | host_vitals + platform=darwin | 422, field=`platform` | PASS | | 6 | dynamic + whitespace-only query | 422, field=`query` | PASS | **API - ApplyLabelSpecs (POST /api/latest/fleet/spec/labels)** | Test | Input | Expected | Result | |------|-------|----------|--------| | 7 | manual + query | 422, field=`query` | PASS | | 8 | dynamic + hosts | 422, field=`hosts` | PASS | | 9 | valid dynamic | 200 | PASS | **Round-trip: get labels --yaml then apply** | Test | Scenario | Result | |------|----------|--------| | 10 | Legacy manual label with platform=darwin in DB | Platform stripped from YAML, re-apply succeeds — PASS | | 11 | Dynamic label with platform=darwin | Platform preserved in YAML, re-apply succeeds — PASS | **GitOps parser (fleetctl gitops --dry-run)** | Test | Input | Result | |------|-------|--------| | 12 | manual + query + platform + criteria | All 3 errors surfaced at once — PASS | | 13 | valid manual label | No validation errors — PASS | | 14 | dynamic + invalid platform | Error surfaced — PASS | --- ### Code walkthrough **`server/fleet/labels.go`** — Added `ValidateLabelMembershipFields(*LabelSpec) *InvalidArgumentError`. This is the single source of truth for label field validation, returning field-specific errors (`platform`, `query`, `criteria`, `hosts`). Lives here because this package defines the label types both callers import. Also uses `strings.TrimSpace` to reject whitespace-only queries. **`server/service/labels.go`** — Three changes: (1) Removed the early blanket platform check from `NewLabel` that ran before the membership type was known. (2) Added `ValidateLabelMembershipFields` call in `NewLabel` after type inference, so the API rejects invalid combos at creation time. (3) Replaced three incomplete inline checks in `ApplyLabelSpecs` with a single call to the centralized function, using `err.WithStatus(422)` to preserve field-specific error shape in the API response. **`pkg/spec/gitops.go`** — Replaced the inline validation switch and a standalone `ValidLabelPlatformVariants` check with a call to `ValidateLabelMembershipFields`. Unwraps the returned errors individually into `multiError` so all validation problems are reported to the user at once. **`cmd/fleetctl/fleetctl/generate_gitops.go`** — Gated platform emission on `LabelMembershipTypeDynamic` so legacy manual/host_vitals labels with a stored platform don't produce YAML that fails re-import. **`cmd/fleetctl/fleetctl/get.go`** — Added `stripMismatchedLabelFields` which clears type-inappropriate fields (query, platform, criteria, hosts) per membership type before YAML output. Called in both code paths: listing all labels and fetching a single label by name. Ensures the `get labels --yaml` → `apply` round-trip works for legacy data. **`server/datastore/mysql/labels.go`** — Added missing `l.criteria` column to `GetLabelSpec` SELECT, matching `GetLabelSpecs`. Without it, host_vitals labels fetched by name lost their criteria in the YAML output, causing re-import to fail with the new validation. |
||
|
|
f2b2e23b0a |
GitOps changes for custom org's logo uploads (#44550)
<!-- Add the related story/sub-task/bug number, like Resolves #123, or remove if NA --> **Related issue:** Resolves #44333 # Checklist for submitter - [x] 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. ## Testing - [x] Added/updated automated tests. Also added some integration tests as a follow-up of the first PR (https://github.com/fleetdm/fleet/pull/44390). - [x] QA'd all new/changed functionality manually #### generate-gitops - Branched off to main, no URLs set, then ran generate-gitops on this branch. Deprecated keys gone, new keys present. <img width="447" height="170" alt="nourls_new" src="https://github.com/user-attachments/assets/61931615-d61b-44d3-8095-f7a2b9bd8871" /> - Branched off to main, set external URLs for both light and dark modes, then ran generate-gitops on this branch. Deprecated keys gone, new keys set with the external URLs. <img width="637" height="471" alt="externalurl_main" src="https://github.com/user-attachments/assets/c3782756-acc2-4b99-812d-86e145f11ad5" /> <img width="459" height="168" alt="externalurl_new" src="https://github.com/user-attachments/assets/aa2d8825-3c47-40ba-ab91-bb8202afe81a" /> - Within this branch, after uploading a custom logo for light mode, ran generate-gitops. The logo was saved in lib/org_logo/light.webp <img width="1510" height="639" alt="Screenshot 2026-05-04 at 4 06 59 PM" src="https://github.com/user-attachments/assets/13318c24-8fa4-4e29-b629-ff723d4afe5a" /> <img width="786" height="172" alt="Screenshot 2026-05-04 at 4 07 30 PM" src="https://github.com/user-attachments/assets/b46bd1df-7dcd-4489-b7da-4cbad77b25b8" /> #### gitops - Applied gitops with two external URLs. Verified in the UI that those are still present <img width="944" height="189" alt="Screenshot 2026-05-04 at 7 54 53 AM" src="https://github.com/user-attachments/assets/a34813ca-beb1-403e-9793-d42cc9c72f8b" /> <img width="637" height="259" alt="Screenshot 2026-05-04 at 8 01 04 AM" src="https://github.com/user-attachments/assets/74c2cd56-ab1d-4ddd-9b8e-22c49e9ae9d5" /> - Applied gitops with "" as the URLs to clear them. Verified the default fleet logo is shown. <img width="460" height="201" alt="Screenshot 2026-05-04 at 8 15 11 AM" src="https://github.com/user-attachments/assets/dcbafea3-b4ea-44aa-9045-08c4f5a64e98" /> <img width="648" height="269" alt="Screenshot 2026-05-04 at 8 15 50 AM" src="https://github.com/user-attachments/assets/451a28f9-e929-4b84-93d3-a7dd9afd5eca" /> - Applied gitops with a custom logo for light theme, using **org_logo_path_light_mode**: <img width="948" height="207" alt="Screenshot 2026-05-04 at 4 10 05 PM" src="https://github.com/user-attachments/assets/b1418cd4-31cc-4e53-b566-9af11ec21970" /> <img width="774" height="168" alt="Screenshot 2026-05-04 at 4 10 35 PM" src="https://github.com/user-attachments/assets/63f596eb-308f-4122-ad86-e1d718e9b525" /> ## New Fleet configuration settings - [x] Verified that the setting is exported via `fleetctl generate-gitops` - [x] 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) - See https://github.com/fleetdm/fleet/pull/43808. - [x] 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) - [x] Verified that any relevant UI is disabled when GitOps mode is enabled <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * GitOps support for uploading custom org logos (dark/light) via local files. * `fleetctl generate-gitops` exports Fleet-hosted logos as local files and inserts path references. * New API endpoints to upload, delete, and fetch org logos. * **Deprecated** * Legacy logo keys consolidated into mode-specific URL keys (`org_logo_url_dark_mode`, `org_logo_url_light_mode`). * **Bug Fixes / Validation** * Validation/error when both a path and URL are provided for the same mode; file size and image-format checks enforced. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
|
2ee5404ed3 |
Validate label platform during gitops --dry-run (#42477) (#44594)
Resolves #42477 Move the platform check into pkg/spec parseLabels so both --dry-run and apply hit the same validation and surface the same error. |
||
|
|
5da912a33e |
Bugfix: escape characters not supported in JSON when resolving variables (#43955)
<!-- Add the related story/sub-task/bug number, like Resolves #123, or remove if NA --> **Related issue:** Resolves #38013 # Checklist for submitter - [x] 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. - [x] 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. ## Testing - [x] Added/updated automated tests - [x] QA'd all new/changed functionality manually See https://drive.google.com/file/d/1zeFNLuf_rT5FWzDiYyL2_hbIBW2neba-/view?usp=drive_link <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Bug Fixes** * GitOps variables in JSON configuration profiles (Apple DDM declarations and Android profiles) are now automatically escaped for JSON special characters, ensuring proper handling of sensitive values. * **Tests** * Added JSON configuration profile escaping validation to the enterprise GitOps integration test suite. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
|
39e4f616ea |
macOS managed local account foundations (#43381)
Implements both #42942 and #42943 Co-authored-by: jkatz01 <yehonatankatz@gmail.com> |
||
|
|
7d9c134942 |
Allow icon in team level yaml for script-only packages (#43783)
<!-- Add the related story/sub-task/bug number, like Resolves #123, or remove if NA --> **Related issue:** Resolves #43142 Since script-only packages have to be specified as a path, add some logic to allow icon to be set as a path in that situation. # Checklist for submitter If some of the following don't apply, delete the relevant line. - [x] 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 - [x] Added/updated automated tests - `TestSoftwarePackagesPathWithInline` checks custom package yml path so there is no regression, added `TestScriptOnlyPackagesPathWithInline` to test script-only package path. - [ ] 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) - [x] QA'd all new/changed functionality manually - Tested .sh and .ps1 script-only packages with icon path specified in the team level yaml. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Bug Fixes** * Fixed custom icon handling for script-only packages (e.g., .sh and .ps1), allowing icons to be set and resolved correctly for packages referenced by path. * **Tests** * Added test coverage validating custom icon functionality and path resolution for script-only packages; included a sample script used by the test. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
|
15b0cf4277 |
Do not replace EVs in script-only packages (#43606)
<!-- Add the related story/sub-task/bug number, like Resolves #123, or remove if NA --> **Related issue:** Resolves #43311 # Checklist for submitter If some of the following don't apply, delete the relevant line. - [x] 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. - [x] 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. - [x] Timeouts are implemented and retries are limited to avoid infinite loops ## Testing - [x] Added/updated automated tests - [x] QA'd all new/changed functionality manually <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Bug Fixes** * Made environment-variable expansion conditional by package type: script-only packages no longer expand host env vars during parsing, while YAML packages still have env vars expanded (expansion errors are recorded and parsing continues). * **Tests** * Added a test to confirm script packages do not expand standard shell variables during parsing. * **Chores** * Updated changelog entry describing the script-only package fix. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
|
ce21d9172a |
Add python to allowed script extensions (#43467)
Fixes #43334 |
||
|
|
3ae98ee01d |
Clean up Gitops tests and add deprecation tests (#43039)
<!-- Add the related story/sub-task/bug number, like Resolves #123, or remove if NA --> **Related issue:** For #40015 * Moves repeated empty mocks into a new `setupEmptyGitOpsMocks` method * Adds new "deprecation" tests: * In TestGitOpsFullGlobal, TestGitOpsFullTeam and TestGitOpsFullGlobalAndTeam tests "kitchen sink" with both new and deprecated keys * Added keys and checks to verify `setup_experience`, `apple_business_manager` and `volume_purchasing_program` configs * Consolidated map of deprecated -> new GitOps keys in one place |
||
|
|
1eabb85a5a |
Activate deprecation warnings (#41449)
<!-- Add the related story/sub-task/bug number, like Resolves #123, or remove if NA --> **Related issue:** Resolves #40015 # Details Activates deprecation warnings for old API params and CLI args, updates tests that would generate warnings (except for tests explicitly designed to generate warnings). The expectation from here on is that Fleet UI usage should not generate any deprecation warnings in the server logs, nor should the output from `generate-gitops` generate any warnings when fed into `gitops`. # Checklist for submitter If some of the following don't apply, delete the relevant line. - [X] 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. ## Testing - [X] Added/updated automated tests - [ ] QA'd all new/changed functionality manually - [X] clicked around in an mdm-enabled instance, turned setup experience features on and off, saw no server warnings - [X] did `fleetctl generate-gitops` on mdm-enabled instance, saw no server or cli warnings - [X] did `fleetctl gitops` on mdm-enabled instance, saw no server or cli warnings |
||
|
|
c4aa6f5529 |
Use fleetctl new templates for new instances (#42768)
<!-- Add the related story/sub-task/bug number, like Resolves #123, or remove if NA --> **Related issue:** Resolves #41409 # Details This PR updates the `ApplyStarterLibrary` method and functionality to rely on the same templates and mechanisms as `fleetctl new`. The end result is that running `fleetctl new` and `fleetctl gitops` on a new instance should be a no-op; no changes should be made. Similarly, changing the templates in a Fleet release will automatically affect `fleetctl new` and `ApplyStarterLibrary` in the same exact way for that release. > Note that this moves the template files out of `fleetctl` and into their own shared package. This move comprises the majority of the file changes in the PR. # Checklist for submitter If some of the following don't apply, delete the relevant line. - [X] 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. ## Testing - [X] Added/updated automated tests Note that <img width="668" height="44" alt="image" src="https://github.com/user-attachments/assets/066cd566-f91d-4661-84fc-2aabbfce2ef9" /> will fail until the 4.83 Fleet docker image is published, since it's trying to push 4.83 config (including `exceptions`) to a 4.82 server. - [X] QA'd all new/changed functionality manually - [X] Created a new instance and validated that the fleets, policies and labels created matched the ones created by `fleetctl new` - [X] Ran `fleetctl new` and verified that it created the expected folders and files - [X] Ran `fleetctl gitops` with the files created by `fleetctl new` and verified that the instance was unchanged. - [X] Ran `fleetctl preview` successfully using a dev build of the Fleet server image (since it won't work against the latest published build, which doesn't support `exceptions`). Verified it shows the expected teams, policies and labels |
||
|
|
d4f48b6f9c |
ACME MDM -> main (#42926)
<!-- Add the related story/sub-task/bug number, like Resolves #123, or remove if NA --> **Related issue:** The entire ACME feature branch merge # Checklist for submitter If some of the following don't apply, delete the relevant line. - [x] 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. - [x] 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. - [x] Timeouts are implemented and retries are limited to avoid infinite loops ## Testing - [x] Added/updated automated tests - [x] 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) - [x] QA'd all new/changed functionality manually --------- Co-authored-by: Jordan Montgomery <elijah.jordan.montgomery@gmail.com> Co-authored-by: Martin Angers <martin.n.angers@gmail.com> Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com> Co-authored-by: Gabriel Hernandez <ghernandez345@gmail.com> Co-authored-by: Sarah Gillespie <73313222+gillespi314@users.noreply.github.com> |
||
|
|
07a8378a68 |
Implement FMA software policy automation (#42533)
<!-- Add the related story/sub-task/bug number, like Resolves #123, or remove if NA --> **Related issue:** Resolves #36751 # Checklist for submitter If some of the following don't apply, delete the relevant line. - [X] 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. ## Testing - [X] Added/updated automated tests - [X] QA'd all new/changed functionality manually - [X] Verified that `fleetctl generate-gitops` correctly outputs policies with `install_software.fleet_maintained_app_slug` populated when the policies have FMA automation - [X] Verified that running `fleetctl gitops` using files with `install_software.fleet_maintained_app_slug` creates/updates FMA policy automation correctly - [X] Verified no changes to the above for custom packages or VPP apps - [X] Verified that when software is excepted from GitOps, FMA policy automations still work (correctly validates FMAs exist before applying) ## 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: - [X] 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) checking on this - [X] 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) - [X] Verified that any relevant UI is disabled when GitOps mode is enabled |
||
|
|
6598b608b7 |
Enforce GitOps exceptions (#42191)
<!-- Add the related story/sub-task/bug number, like Resolves #123, or remove if NA --> **Related issue:** Resolves #42180 <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Enhanced GitOps exception handling for labels, secrets, and software with clearer enforcement and omission semantics. * Server-side prefetch of team software so omitted team software can preserve existing installers during validation. * Presence flags track whether top-level keys (labels, secrets, software) were provided versus omitted. * **Behavior Changes** * Omitted vs empty sections are now distinguished: omission can mean “no-op” or “delete-all” depending on exception settings. * GitOps YAML can define and manage labels directly; validations now reject YAML that includes keys marked as excepted. <!-- end of auto-generated comment: release notes by coderabbit.ai --> # Checklist for submitter If some of the following don't apply, delete the relevant line. - [X] 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. ## Testing - [X] Added/updated automated tests - [X] QA'd all new/changed functionality manually * **Labels** - [ ] Validated that with label exceptions off, omitting `labels:` key from default.yml clears all global labels - [ ] Validated that with label exceptions off, omitting `labels:` key from a fleet .yml clears all labels for that fleet - [ ] Validated that with label exceptions off, setting empty `labels:` key from default.yml clears all global labels - [ ] Validated that with label exceptions off, setting empty `labels:` key from a fleet .yml clears all labels for that fleet - [ ] Validated that with label exceptions on, omitting `labels:` key from default .yml leaves existing global labels as-is - [ ] Validated that with label exceptions on, omitting `labels:` key from a fleet .yml leaves existing labels as-is - [ ] Validated that with label exceptions on, setting `labels:` key on default .yml generates an error - [ ] Validated that with label exceptions on, setting `labels:` key on a fleet .yml generates an error - [ ] Validated that with label exceptions on, a policy using `labels_include_any` referencing an existing label succeeds without `labels:` key - [ ] Validated that with label exceptions on, a query using `labels_include_any` referencing an existing label succeeds without `labels:` key - [ ] Validated that with label exceptions on, an MDM profile using `labels_include_any` referencing an existing label succeeds without `labels:` key - [ ] Validated that with label exceptions on, a software package using `labels_include_any` referencing an existing label succeeds without `labels:` key (requires software exceptions off) - [ ] Validated that with label exceptions on, an app store app using `labels_include_any` referencing an existing label succeeds without `labels:` key (requires software exceptions off) - [ ] Validated that with label exceptions on, a fleet maintained app using `labels_include_any` referencing an existing label succeeds without `labels:` key (requires software exceptions off) * **Secrets** - [ ] Validated that with secrets exceptions off, omitting `secrets:` key from default.yml clears all global secrets - [ ] Validated that with secrets exceptions off, omitting `secrets:` key from a fleet .yml clears all secrets for that fleet - [ ] Validated that with secrets exceptions on, omitting `secrets:` key from default .yml leaves existing global secrets as-is - [ ] Validated that with secrets exceptions on, omitting `secrets:` key from a fleet .yml leaves existing secrets as-is - [ ] Validated that with secrets exceptions on, setting `secrets:` key on default .yml generates an error - [ ] Validated that with secrets exceptions on, setting `secrets:` key on a fleet .yml generates an error * **Software** - [ ] Validated that with software exceptions off, omitting `software:` key from no-team.yml/unassigned.yml clears all software for "no team" - [ ] Validated that with software exceptions off, omitting `software:` key from a fleet .yml clears all software for that fleet - [ ] Validated that with software exceptions off, setting empty `software:` key on a fleet .yml clears all software for that fleet - [ ] Validated that with software exceptions off, setting empty `software:` key on no-team.yml/unassigned.yml clears all software for "no team - [ ] Validated that with software exceptions on, omitting `software:` key from a fleet .yml leaves existing software as-is - [ ] Validated that with software exceptions on, setting `software:` key on a fleet .yml generates an error - [ ] Validated that with software exceptions on, omitting `software:` key from no-team.yml/unassigned.yml leaves existing software as-is for "no team" - [ ] Validated that with software exceptions on, setting `software:` key on no-team.yml/unassigned.yml generates an error - [ ] Validated that with software exceptions on, a policy using `install_software.hash_sha256` referencing an existing package succeeds without `software:` key - [ ] Validated that with software exceptions on, a policy using `install_software.app_store_id` referencing an existing VPP app succeeds without `software:` key - [ ] Validated that with software exceptions on, a patch policy using `fleet_maintained_app_slug` referencing an existing FMA succeeds without `software:` key - [ ] Validated that with software exceptions on, `setup_experience.software` referencing existing software succeeds without `software:` key (server-side validation fallback) - [ ] Validated that with software exceptions on, omitting `software:` from no-team.yml/unassigned.yml preserves existing no-team software - [ ] Validated that with software exceptions on, a policy in no-team.yml/unassigned.yml using `install_software.hash_sha256` referencing existing no-team software succeeds without `software:` key For unreleased bug fixes in a release candidate, one of: - [X] Confirmed that the fix is not expected to adversely impact load test results I don't think so. There is a bit of overhead when this feature is used since we have to fetch software from the server, but it would be done in a specific test, so even if there is an impact it should affect existing load testing, only new, specific tests. |
||
|
|
91362ba2ca |
Add fleetctl new command (#41909)
<!-- Add the related story/sub-task/bug number, like Resolves #123, or remove if NA --> **Related issue:** Resolves #41345 # Details This PR: * Adds a new `fleetctl new` command which creates a starter GitOps repo file structure * Adds support for file globs for the `configuration_profiles:` key in GitOps, to support its use in the `fleetctl new` templates. This involved moving the `BaseItem` type and `SupportsFileInclude` interface into the `fleet` package so that the `MDMProfileSpec` type could implement the interface and do glob expansion. # Checklist for submitter If some of the following don't apply, delete the relevant line. - [X] 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. ## Testing - [X] Added/updated automated tests - [X] added unit and intg tests for globbing profiles - [ ] added tests for `fleetctl new` - [X] QA'd all new/changed functionality manually - [X] `fleetctl new` with no args prompted for org name and created a new `it-and-security` folder under current folder w/ correct files - [X] `fleetctl new --dir /tmp/testnew` created correct files under `/tmp/testnew` - [X] `fleetctl new --dir /tmp/testexisting --force` with an existing `/tmp/testexisting` folder created correct files under `/tmp/testexisting` - [X] `fleetctl new --org-name=foo` created correct files under `it-and-security` without prompting for org name - [X] `paths:` in `configuration_profiles` picks up multiple matching profiles - [X] `paths:` + `path:` in `configuration_profiles` will error if the same profile is picked up twice <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Added `fleetctl new` command to initialize GitOps repository structure via CLI. * Added glob pattern support for `configuration_profiles` field, enabling flexible profile selection. * **Chores** * Updated CLI dependencies to support enhanced user interactions. * Removed legacy website generator configuration files. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
|
40e91c0ece |
Allow hosts key to be empty for manual labels (#42022)
<!-- Add the related story/sub-task/bug number, like Resolves #123, or remove if NA --> **Related issue:** Resolves #41672 # Details Updates GitOps label functionality so that omitting the `hosts:` key under a manual label will _not_ clear hosts from that label, but will instead preserve the existing membership. This allows users to manage manual hosts with an external system (via the labels API), while still managing the labels themselves in GitOps. # Checklist for submitter If some of the following don't apply, delete the relevant line. - [X] 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. ## Testing - [X] Added/updated automated tests - [X] QA'd all new/changed functionality manually - [X] verified that you can still add a manual label with `hosts:` - [X] verified that leaving `hosts:` off a manual label doesn't change the host assignment - [X] verified that putting `hosts:` with no value on a manual label clears the hosts - [X] verified that you can still add a dynamic label - [X] verified that generate-gitops still exports manual hosts --------- Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> |
||
|
|
02a9eb8769 | merge main | ||
|
|
ba04887100 |
Backend: Support labels_include_all for installers/apps (#41324)
<!-- Add the related story/sub-task/bug number, like Resolves #123, or remove if NA --> **Related issue:** Resolves #40721 # Checklist for submitter If some of the following don't apply, delete the relevant line. - [x] 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. - [x] 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 ## Testing - [x] Added/updated automated tests - [x] 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 I (Martin) did test `labels_include_all` for FMA, custom installer, IPA and VPP apps, and it seemed to all work great for gitops apply and gitops generate, **except for VPP apps** which seem to have 2 important pre-existing bugs, see https://github.com/fleetdm/fleet/issues/40723#issuecomment-4041780707 ## New Fleet configuration 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 --------- Co-authored-by: Jahziel Villasana-Espinoza <jahziel@fleetdm.com> |
||
|
|
52822be6d4 |
Trim spaces on Fleet's names (36312)
Resolves #36312 - Validate and trim fleet names in NewTeam, ModifyTeam, and ApplyTeamSpecs - Trim fleet names in gitops YAML parsing (parseName) - Disable submit button in CreateTeamModal and RenameTeamModal when name is whitespace-only |
||
|
|
2abacc577e |
Feat/31914 patch policy (#41518)
Implements patch policies #31914 - https://github.com/fleetdm/fleet/pull/40816 - https://github.com/fleetdm/fleet/pull/41248 - https://github.com/fleetdm/fleet/pull/41276 - https://github.com/fleetdm/fleet/pull/40948 - https://github.com/fleetdm/fleet/pull/40837 - https://github.com/fleetdm/fleet/pull/40956 - https://github.com/fleetdm/fleet/pull/41168 - https://github.com/fleetdm/fleet/pull/41171 - https://github.com/fleetdm/fleet/pull/40691 - https://github.com/fleetdm/fleet/pull/41524 - https://github.com/fleetdm/fleet/pull/41674 --------- Co-authored-by: Jonathan Katz <44128041+jkatz01@users.noreply.github.com> Co-authored-by: jkatz01 <yehonatankatz@gmail.com> Co-authored-by: RachelElysia <71795832+RachelElysia@users.noreply.github.com> Co-authored-by: Jahziel Villasana-Espinoza <jahziel@fleetdm.com> |
||
|
|
759c95100a |
Add aliases for more multi-platform setup experience fields (#41599)
<!-- Add the related story/sub-task/bug number, like Resolves #123, or remove if NA --> **Related issue:** Resolves #41091 # Details Implements the following config key aliases: - [x] Add a second name for `bootstrap_package`: `macos_bootstrap_package` - Support `bootstrap_package` for backwards compatibility - [x] Add a second name for `manual_agent_install`: `macos_manual_agent_install` - Support `manual_agent_install` for backwards compatibility - [x] Add a second name for `enable_release_device_manually `: `apple_ enable_release_device_manually ` - Support `enable_release_device_manually` for backwards compatibility - [x] Add a second name for `script`: `macos_script` - Support `script` for backwards compatibility Also cleans up some error messages missed in previous alias PRs. # Checklist for submitter If some of the following don't apply, delete the relevant line. - [X] 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. ## Testing - [X] Added/updated automated tests - [X] QA'd all new/changed functionality manually ran gitops successfully with new keys |
||
|
|
2bf46b14ad |
Detect unknown keys in top-level GitOps settings (#41303)
<!-- Add the related story/sub-task/bug number, like Resolves #123, or remove if NA --> **Related issue:** Resolves #41280 # Details Phase 2 of the "detect unknown keys in GitOps" work. The `org_settings` and `settings` top-level keys mainly shadow the `fleet.AppConfig` and `fleet.TeamConfig` types, but they have a couple of extra GitOps-only fields, so we add new GitOps-specific types for them (similar to what we already have for `GitOpsControls` and `GitOpsSoftware`. The `org_settings:` case is further complicated by the fact that its extra fields are themselves `any` types which we need to parse, so we add those to the `anyFieldTypes` registry in the validator to tell it what types to check them against. Also had to add some new logic to handle the GoogleCalendarAPI case which doesn't expose its keys as `json` tags at all, since we use a special method to obfuscate the values. I've tested this by routing the output from `fleetctl generate_gitops` back through `fleetctl gitops`, which is how I caught the `end_user_license_agreement` issue. # 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. n/a - already added in previous PR ## Testing - [X] Added/updated automated tests - [X] QA'd all new/changed functionality manually Did the `fleetctl generate-gitops` -> `fleetctl gitops` loop as mentioned above. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit ## Release Notes * **New Features** * Added support for managing secrets and certificate authorities through GitOps configuration * Improved detection of configuration errors with clear error messages when using unknown or misspelled settings keys, including suggestions for common typos * Enhanced error reporting for nested configuration files with precise location information <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Ian Littman <iansltx@gmail.com> |
||
|
|
056e567bab |
Implement webhooks_and_tickets_enabled flag for policies in GitOps (#41183)
<!-- Add the related story/sub-task/bug number, like Resolves #123, or remove if NA --> **Related issue:** Resolves #40627 # Details This PR updates the way we enable failed policy reporting (via webhook or ticket integration) for individual policies in GitOps. The existing method is to declare a `policy_ids` key underneath `failing_policies_webhook:` in either the global or a fleet .yml file, and specify a list of policy IDs to enable the automation for. This PR maintains this feature for backwards compatibility, and adds a new feature where you can set `webhook_and_tickets_enabled: true` key in the policy declaration itself. If _both_ these methods are used, the GitOps run will fail. **Implementation note:** Because we're keeping the old way of doing this until Fleet 5, I took the easy route and just translated the new way into the old way; that is, we gather up the list of policies with `webhook_and_tickets_enabled: true`, get their IDs and send that list to the server under the same config we did previously. This works fine and there's nothing _wrong_ with it but ideally this flag would work the same as other per-policy flags like `calendar_events_enabled` that are stored on the policy record. That requires a migration and more new code that we'd have to maintain alongside the existing code (or translate the old strategy to the new one). I'm taking the lower-touch path here. # Checklist for submitter If some of the following don't apply, delete the relevant line. - [X] 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. ## Testing - [X] Added/updated automated tests - [X] QA'd all new/changed functionality manually - [x] Verified that `generate-gitops` outputs the new `webhooks_and_tickets_enabled` flag instead of outputting `policy_ids` under `failing_policies_webhook` - [X] Verified that using the new flag in a fleet .yml file results in the specified policies being enabled in the "other" automations for policies (whether the webhook automation is enabled or not) - [X] Verified the same for a global .default.yml file - [X] Verified that using the old `failing_policies_webhook.policy_ids` a fleet .yml file results in the specified policies being enabled in the "other" automations for policies (whether the webhook automation is enabled or not) - [X] Verified the same for a global .default.yml file - [X] Verified that trying to use both `webhooks_and_tickets_enabled` and `failing_policies_webhook.policy_ids` at the same time results in an error. ## 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: - [x] 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) see https://github.com/fleetdm/fleet/issues/40627#issuecomment-4024988552 - [x] 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) - [x] Verified that any relevant UI is disabled when GitOps mode is enabled <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit ## Release Notes * **New Features** * Added configuration flag to enable webhooks and tickets for policies in GitOps settings. * System automatically resolves and assigns policy IDs when using the new flag. * **Tests** * Added comprehensive test coverage for webhook and ticket enablement in GitOps workflows, including conflict detection and policy ID assignment validation. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
|
63be71fd72 |
require controls on either global or no-team (#41350)
<!-- Add the related story/sub-task/bug number, like Resolves #123, or remove if NA --> **Related issue:** Resolves #41307 # Details * Fixes a potential issue where running `fleetctl gitops` with only the global file, with no controls provided, could wipe out global controls that are provided in the "no team" file. * Fixes error message when controls are missing. # Checklist for submitter ## Testing - [X] Added/updated automated tests - [X] QA'd all new/changed functionality manually - [x] `fleetctl gitops -f /path/to/default.yml` without controls, gives `error: 'controls' must be set on global config, no-team.yml or unassigned.yml` - [x] `fleetctl gitops -f /path/to/default.yml` with empty controls works - [x] `fleetctl gitops -f /path/to/default.yml -f /path/to/no-team.yml` without controls, gives `error: 'controls' must be set on global config or no-team.yml` - [x] `fleetctl gitops -f /path/to/default.yml -f /path/to/unassigned.yml` without controls, gives `error: 'controls' must be set on global config or unassigned.yml` - [x] `fleetctl gitops -f /path/to/default.yml -f /path/to/no-team.yml` with empty controls in no-team.yml works - [x] `fleetctl gitops -f /path/to/default.yml -f /path/to/unassigned.yml` with empty controls in unassigned.yml works - [x] `fleetctl gitops -f /path/to/no-team.yml` gives error `global config must be provided alongside no-team.yml` - [x] `fleetctl gitops -f /path/to/no-team.yml` gives error `global config must be provided alongside unassigned.yml` - [x] `fleetctl gitops -f /path/to/some-real-team.yml` with no controls works For unreleased bug fixes in a release candidate, one of: - [X] Confirmed that the fix is not expected to adversely impact load test results |
||
|
|
9715f75f9a |
Add glob support to more labels, policies and reports (#41141)
<!-- Add the related story/sub-task/bug number, like Resolves #123, or remove if NA --> **Related issue:** Resolves #41006 # Checklist for submitter If some of the following don't apply, delete the relevant line. - [X] 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. ## Testing - [X] Added/updated automated tests Added tests for using path, paths and inline declaration for reports, policies and labels. - [X] QA'd all new/changed functionality manually - [x] tested that `path:` works for policies - [x] tested that `paths:` works for policies - [x] tested that incline declaration works for policies - [x] tested that `path:` works for reports - [x] tested that `paths:` works for reports - [x] tested that incline declaration works for reports - [x] tested that `path:` works for labels - [x] tested that `paths:` works for labels - [x] tested that incline declaration works for labels <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Added support for glob patterns in path specifications within reports, labels, and policies configuration sections. * Enhanced validation and error handling for external file references. * Improved logging and error messages during configuration parsing. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
|
9c4d5ce97e |
Make most GitOps top-level optional (#41138)
<!-- Add the related story/sub-task/bug number, like Resolves #123, or remove if NA --> **Related issue:** Resolves #41012 # Details This PR makes it allowable to leave out almost all top-level keys from GitOps files. The only required keys are _either_ `name:` (for a fleet settings file) or `org_settings:` (for a global settings file). Omitting a key is identical to supplying it with no value. # Checklist for submitter If some of the following don't apply, delete the relevant line. - [X] 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. ## Testing - [X] Added/updated automated tests Updated the "missing all global keys test", and added some new tests to verify that omitting the key was the same as supplying it with an empty value. - [X] QA'd all new/changed functionality manually 1. Ran `fleetctl generate-gitops` to get a clean set of GitOps yml files 2. Removed all removable keys from default.yml and ran `fleetctl gitops` 3. Ran `fleetctl generate-gitops` again into a different dir 4. Ran `fleetctl gitops` with the original files to get back to original state 5. Cleared out all now-removable keys and replaced them with empty value (e.g. `reports:` with nothing under it) 6. Ran `fleetctl generate-gitops` again into a third dir 7. Compared the files from the second and third generate-gitops runs to verify that omitting the key had the same result as supplying it with an empty value 8. Did the above steps with a fleet (i.e. non-global) .yml file. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit ## Release Notes * **New Features** * GitOps files now support omitting top-level configuration keys instead of requiring them to be explicitly set to empty values. * org_settings is now required when team name is not specified. * **Tests** * Added integration tests validating behavior when omitting top-level keys in global and team-level GitOps configurations. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |