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

Abierto
  • ¿Algo no está bien?
#198 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
56/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
azure, powershell
Área
cloud, security

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
PowerShell
Estrellas
1.4k
Forks
144
Merge medio
1 d 21 h
PR fusionados (30 d)
1

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de silverhack/monkey365

Todos los issues de silverhack/monkey365

Issues similares

Más issues de Cloud

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.