Skip to content

[9.5](backport #8230) [Asset Inventory][AWS] ELBv2: resolve IPAddresses from DNSName when API returns none - #8604

Merged
gurevichdmitry merged 1 commit into
9.5from
mergify/bp/9.5/pr-8230
Sep 27, 2026
Merged

gurevichdmitry merged 1 commit into
9.5from
mergify/bp/9.5/pr-8230

Conversation

@mergify

@mergify mergify Bot commented Sep 27, 2026

Copy link
Copy Markdown
Contributor

Summary

Stacked on #8229 (forward-port of #7277). Review #8229 first; this PR's diff shows only the ELBv2 DNS fallback on top of it.

Problem

entity.Details.IPAddresses is always empty for real-world ALBs and NLBs. The AWS API field AvailabilityZones[].LoadBalancerAddresses[].IpAddress is only populated for NLBs with explicitly assigned Elastic IPs — across 200 sampled internet-facing NLBs it was empty on all of them. The classic ELB (v1) fetcher was given a DNS-resolution fallback in #7277; ELBv2 was not.

Fix

Mirror the ELBv1 pattern in the elb_v2 package:

  • elb_v2.go: add unexported hostResolver interface (LookupHost) + resolver field on Provider; set net.DefaultResolver in NewElbV2Provider.
  • load_balancer_v2.go: add dnsResolvedIPs []string field; GetIPAddresses() returns it as a fallback when the API slice is empty; add NewElasticLoadBalancerInfo constructor for testability.
  • provider_v2.go: after listeners are fetched, if GetIPAddresses() is still empty, resolve DNSName via the injected resolver, sort the result, soft-fail on error (a DNS outage must not fail the fetch cycle).
  • provider_v2_test.go: add per-case resolver column with four cases: DNS fallback used + sorted, resolver error soft-fail, API IPs win (resolver not called), and the existing error path.
  • fetcher_elb_test.go: switch ELBv2 case to NewElasticLoadBalancerInfo with pre-resolved IPs; assert IPAddresses in expected Details.

Caveat

DNS-resolved IPs are point-in-time. ALB/NLB addresses rotate and vary by resolver vantage point. This matches what the classic ELB fetcher already does and what InfoSec's legacy scripts do — parity, not a new compromise.

Related

Checklist

…PI returns none (#8230)

## Summary

Stacked on #8229 (forward-port of #7277). **Review #8229 first; this
PR's diff shows only the ELBv2 DNS fallback on top of it.**

### Problem

`entity.Details.IPAddresses` is always empty for real-world ALBs and
NLBs. The AWS API field
`AvailabilityZones[].LoadBalancerAddresses[].IpAddress` is only
populated for NLBs with explicitly assigned Elastic IPs — across 200
sampled internet-facing NLBs it was empty on all of them. The classic
ELB (v1) fetcher was given a DNS-resolution fallback in #7277; ELBv2 was
not.

### Fix

Mirror the ELBv1 pattern in the `elb_v2` package:

- **`elb_v2.go`**: add unexported `hostResolver` interface
(`LookupHost`) + `resolver` field on `Provider`; set
`net.DefaultResolver` in `NewElbV2Provider`.
- **`load_balancer_v2.go`**: add `dnsResolvedIPs []string` field;
`GetIPAddresses()` returns it as a fallback when the API slice is empty;
add `NewElasticLoadBalancerInfo` constructor for testability.
- **`provider_v2.go`**: after listeners are fetched, if
`GetIPAddresses()` is still empty, resolve `DNSName` via the injected
resolver, sort the result, soft-fail on error (a DNS outage must not
fail the fetch cycle).
- **`provider_v2_test.go`**: add per-case `resolver` column with four
cases: DNS fallback used + sorted, resolver error soft-fail, API IPs win
(resolver not called), and the existing error path.
- **`fetcher_elb_test.go`**: switch ELBv2 case to
`NewElasticLoadBalancerInfo` with pre-resolved IPs; assert `IPAddresses`
in expected `Details`.

### Caveat

DNS-resolved IPs are point-in-time. ALB/NLB addresses rotate and vary by
resolver vantage point. This matches what the classic ELB fetcher
already does and what InfoSec's legacy scripts do — parity, not a new
compromise.

### Related

- Closes https://github.com/elastic/security-team/issues/18294
- Stacked on: #8229

## Checklist

- [x] Tests added (DNS fallback, soft-fail, API-wins paths)
- [x] Mocks updated (`mockHostResolver` added to `elb_v2_mock.go`)

(cherry picked from commit d05cca1)
@mergify mergify Bot added the backport label Sep 27, 2026
@mergify
mergify Bot requested a review from a team as a code owner September 27, 2026 14:40
@mergify mergify Bot added the backport label Sep 27, 2026
@gurevichdmitry
gurevichdmitry added this pull request to the merge queue Sep 27, 2026
@mergify

mergify Bot commented Sep 27, 2026 •

Copy link
Copy Markdown
Contributor Author

This pull request does not currently match the merge queue conditions, so it cannot be queued from here. The box comes back if it matches again.

Merged via the queue into 9.5 with commit b5a596b Sep 27, 2026
15 checks passed
@gurevichdmitry
gurevichdmitry deleted the mergify/bp/9.5/pr-8230 branch September 27, 2026 15:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants