Skip to content

feat(fleet): add Azure.Fleet.SecureBoot rule (AZR-000545)#3863

Open
l46983284-cpu wants to merge 4 commits into
Azure:mainfrom
l46983284-cpu:feat/fleet-secure-boot
Open

feat(fleet): add Azure.Fleet.SecureBoot rule (AZR-000545)#3863
l46983284-cpu wants to merge 4 commits into
Azure:mainfrom
l46983284-cpu:feat/fleet-secure-boot

Conversation

@l46983284-cpu

Copy link
Copy Markdown

PR Summary

Fixes: #3729

Adds Azure.Fleet.SecureBoot so Azure Fleet base VM profiles require Trusted Launch or Confidential VM with Secure Boot enabled.

Path checked:

  • properties.computeProfile.baseVirtualMachineProfile.securityProfile.securityTypeTrustedLaunch | ConfidentialVM
  • properties.computeProfile.baseVirtualMachineProfile.securityProfile.uefiSettings.secureBootEnabled = true

Mirrors existing Azure.VM.SecureBoot / Azure.VMSS.SecureBoot guidance for fleet profiles.

PR Checklist

  • PR has a meaningful title
  • Summarized changes
  • Change is not breaking
  • This PR is ready to merge and is not Work in Progress
  • Rule changes
    • Unit tests created/ updated
    • Rule documentation created/ updated
    • Link to a filed issue
    • Change log has been updated with change under unreleased section

@polatengin polatengin left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The rule matches issue #3729 and follows the existing VM and VMSS Secure Boot rules. The rule ID, 2026_09 rule set, metadata, messages, documentation, examples, and changelog all look correct.

I have one request about test coverage and one question about the generated mapping file.

Comment on lines +60 to 74
It 'Azure.Fleet.SecureBoot' {
$filteredResult = $result | Where-Object { $_.RuleName -eq 'Azure.Fleet.SecureBoot' };

# Fail
$ruleResult = @($filteredResult | Where-Object { $_.Outcome -eq 'Fail' });
$ruleResult | Should -Not -BeNullOrEmpty;
$ruleResult.Length | Should -Be 3;
$ruleResult.TargetName | Should -BeIn 'fleet-001', 'fleet-002', 'fleet-003';

# Pass
$ruleResult = @($filteredResult | Where-Object { $_.Outcome -eq 'Pass' });
$ruleResult | Should -Not -BeNullOrEmpty;
$ruleResult.Length | Should -Be 2;
$ruleResult.TargetName | Should -BeIn 'fleet-004', 'fleet-005';
}

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you add separate test cases for the two checks? The three failing fleets are missing the whole security profile, so they fail both checks at the same time. The test still passes if the secureBootEnabled assertion is removed.

Please add these cases:

  • TrustedLaunch with secureBootEnabled: false should fail.
  • An invalid or missing securityType with secureBootEnabled: true should fail.
  • ConfidentialVM with secureBootEnabled: true should pass.

This will confirm that both properties are checked and that ConfidentialVM is supported.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the full update to this generated mapping file needed in this PR? It changes 920 lines, but when the entries are compared without considering their order, the only new entry is Azure.Fleet.SecureBoot. What I understand from recent rule PRs have left this file to the separate mapping maintenance process.

@BernieWhite should we remove this file from the PR, or explain why it needs to be included?

What you think?

@l46983284-cpu
l46983284-cpu force-pushed the feat/fleet-secure-boot branch from eb9eeaa to b3603c9 Compare July 14, 2026 15:28
@l46983284-cpu

Copy link
Copy Markdown
Author

Thanks for the review — agreed on both points.

Updates on the latest head:

  1. Tests — added separate fleets so the two checks are not only covered together:
    • fleet-006: TrustedLaunch + secureBootEnabled: false → Fail
    • fleet-007: missing securityType + secureBootEnabled: true → Fail
    • fleet-008: ConfidentialVM + secureBootEnabled: true → Pass
  2. data/resource-type-mapping.json — removed the generated churn from this PR and restored main. Left mapping to the normal maintenance process.

Happy to adjust further if you’d like different fixture names/layout.

@polatengin

Copy link
Copy Markdown
Member

Thanks for the review — agreed on both points.

Can you also rebase your PR branch with the main, please?

Signed-off-by: Alex Chen <l46983284@gmail.com>
Signed-off-by: Alex Chen <l46983284@gmail.com>
Signed-off-by: Alex Chen <l46983284@gmail.com>
Signed-off-by: Alex Chen <l46983284@gmail.com>
@l46983284-cpu
l46983284-cpu force-pushed the feat/fleet-secure-boot branch from 496e1a5 to 28db766 Compare July 14, 2026 18:09
@l46983284-cpu

Copy link
Copy Markdown
Author

Rebased onto latest main.

Head is now 28db76665108 (clean rebase, no other changes).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[RULE] Azure Fleets should use secure boot

2 participants