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

Aperta
  • Qualcosa non va?
#198 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
56/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
azure, powershell
Ambito
cloud, security

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
PowerShell
Stelle
1.4k
Fork
144
Merge medio
1g 21h
PR unite (30g)
1

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di silverhack/monkey365

Tutte le issue di silverhack/monkey365

Issue simili

Altre issue su Cloud

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.