[Bug]: Cosmos DB private endpoint rule aborts rule evaluation ("Argument types do not match") and never recognises approved private endpoints

Offen
  • Stimmt etwas nicht?
#198 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
56/100
Issue-Typ
Bug
Klarheit
Klar beschrieben
Aktivitätsstatus
Aktiv
Tech-Stack
azure, powershell
Bereich
cloud, security

Rechercherichtung

Start by reading Get-MonkeyAzCosmosDBInfo.ps1, Get-MonkeyAzGenericPrivateEndpoint, Resolve-Filter.ps1, and the Cosmos DB rule azure-cosmosdb-lacks-private-endpoint.json. Reproduce the reported PowerShell 7.6.9 list behavior, then compare the rule's property path with the storage account rule. Done means evaluation completes and accounts with approved private endpoints pass without false findings; consider whether the shared filter affects other helpers.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

bug status/needs-triage

What happened?
Two problems with the rule "Ensure that Cosmos DB uses Private Endpoints where possible" (azure-cosmosdb-lacks-private-endpoint.json, path az_cosmosdb, whereObject = networking.privateEndpointConnections).

Problem 1: rule evaluation throws "Argument types do not match".
Get-MonkeyAzCosmosDBInfo.ps1 assigns the result of Get-MonkeyAzGenericPrivateEndpoint to networking.privateEndpointConnections. That function returns its list with Write-Output $allPrivateEndpoints -NoEnumerate, so the stored value is a List[Object] wrapped in a PSObject. The filter generated by Resolve-Filter.ps1 evaluates

@($_.networking.privateEndpointConnections).Where({$null -ne $_.id -and $_.privateLinkServiceConnectionState.status -eq 'Approved'})

On the PSObject-wrapped list, .Where() throws Argument types do not match. This happens for an empty list, for the placeholder entry (no private endpoint) and for real private endpoints. Out-MonkeyData writes the error with Write-Error; with $ErrorActionPreference = 'Stop' the whole scan stops.

Problem 2: approved private endpoints are never matched.
The rule checks privateLinkServiceConnectionState.status on the entry itself. Get-MonkeyAzGenericPrivateEndpoint stores the ARM data under properties (properties.privateLinkServiceConnectionState.status). With a workaround for problem 1, an account with an approved private endpoint still gets no match and, because of shouldExist: true, is reported as a finding (false positive).

How to reproduce it
Minimal repro for problem 1 (PowerShell 7.6.9):

function Get-Pe { $l = [System.Collections.Generic.List[System.Object]]::new(); [void]$l.Add([pscustomobject]@{ id = $null }); Write-Output $l -NoEnumerate }
$o = [pscustomobject]@{ networking = [pscustomobject]@{ privateEndpointConnections = $null } }
$o.networking.privateEndpointConnections = Get-Pe
@($o.networking.privateEndpointConnections).Where({ $null -ne $_.id })   # Argument types do not match
$o.networking.privateEndpointConnections = @(Get-Pe)
@($o.networking.privateEndpointConnections).Where({ $null -ne $_.id })   # works

With Monkey365: run Invoke-Monkey365 -Instance Azure against a subscription that contains a Cosmos DB account.

Expected behavior
The rule evaluates without error; accounts with an approved private endpoint pass.

Suggested fix

  • Problem 1: $cosmosDBObject.networking.privateEndpointConnections = @(Get-MonkeyAzGenericPrivateEndpoint @p) (this is the workaround we use).
  • Problem 2: use properties.privateLinkServiceConnectionState.status in the rule condition (the storage account rule already uses this path), or flatten the property in the helper.

From where are you running Monkey365?

  • Resource: Docker container
  • OS: Linux (Ubuntu 24.04)
  • PowerShell Version: 7.6.9
  • Monkey365 Version: 1.0.5 (PowerShell Gallery)
  • Others: app-only authentication with access tokens

Additional context
In 1.0.0 this did not show up for us because Cosmos DB accounts without a diagnostic setting were dropped before evaluation (#196, fixed in 1.0.5). Other helpers also return lists with -NoEnumerate; any whereObject filter on such a property would fail the same way. A generic fix could be in Resolve-Filter.ps1 or in the helpers.

Vorherrschende Sprache
PowerShell
Sterne
1.4k
Forks
144
Ø Merge
1 T. 21 Std.
Gemergte PRs (30 T.)
1

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus silverhack/monkey365

Alle Issues in silverhack/monkey365

Ähnliche Issues

Weitere Issues zu Cloud

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.