security: narrow internal ingress CIDR (JIRA-4521)

[dylanratcliffe]

Summary

• Narrow internal ingress CIDR used for service/monitoring access.

Context

• JIRA-4521: Reduce internal exposure based on audit feedback.

Testing

• Terraform plan reviewed in CI.

Rollout / Risk

• If any internal tooling relies on the broader range, it may lose access; monitor health checks and alarms after merge.

[github-actions]

Open in Overmind ↗

---

model|risks_v6
✨Encryption Key State Risk ✨KMS Key Creation

🟢 Change Signals

Routine 🟢 ▁▂ Ingress resources showing regular updates with 1 event/day for the last 6 weeks and 2 events/day for the last day.

View signals ↗

---

🔥 Risks

Narrowing sg-089e5107637083db5 ingress to 10.0.0.0/16 will block 10.50.0.0/16 NLB health checks and metrics on port 9090 ❗Medium Open Risk ↗
The internal-services security group is changing its ingress from 10.0.0.0/8 to 10.0.0.0/16 for ports 8080, 443, and 9090. A monitoring VPC in 10.50.0.0/16 reaches targets in the workloads VPC over an active VPC peering connection. Its internal NLB (mon-internal-terraform-example) uses the target group api-health-terraform-example (TCP/9090) to probe IP 10.0.101.222, which belongs to ENI eni-0fe5a958a733a13fe protected by sg-089e5107637083db5. The target is currently healthy, confirming cross‑VPC connectivity on 9090.

When the CIDR is narrowed to 10.0.0.0/16, traffic sourced from 10.50.0.0/16 will no longer match the ingress rule and will be dropped. The NLB health checks and metrics scraping on port 9090 will fail, the target will be marked unhealthy and deregistered, and cross‑VPC monitoring/observability for that service will break. Similar 443/8080 flows from 10.50.0.0/16 would also be blocked.

---

🧠 Reasoning · ✖ 1 · ✔ 1

Ingress CIDR narrowing from 10.0.0.0/8 to 10.0.0.0/16 blocking internal/peered traffic

Observations 26

Hypothesis

Security group sg-089e5107637083db5 (and similar groups) has ingress CIDR blocks narrowed from 10.0.0.0/8 to 10.0.0.0/16 for internal service ports such as 8080, 443, and 9090. This reduces the allowed internal source IP range and can block legitimate traffic from hosts in 10.0.0.0/8 but outside 10.0.0.0/16, including other VPCs, peered VPCs (e.g., 10.50.0.0/16), on‑prem networks, and other 10.x clients that previously relied on the broader /8. Affected resources include ENIs such as eni-00100c6bffbdc9755 (private IP 10.0.101.150) and services fronted by associated public EIPs, as well as peers like ENIs in 10.50.0.0/16 (e.g., 10.50.101.182). Likely impacts include failed ELB and other load balancer health checks on targets (for example the API health target group on port 9090) leading to target deregistration and traffic disruption, broken monitoring and Prometheus scraping, loss of service‑mesh and internal HTTPS connectivity, and general cross‑VPC/peering communication failures and observability gaps for instances and ENIs protected by this security group.

Investigation

I inspected the diff and the current state. The change narrows sg-089e5107637083db5 ingress on ports 8080/443/9090 from 10.0.0.0/8 to 10.0.0.0/16. Today, that group allows sources from 10.50.0.0/16 because it’s within 10/8. There is an active VPC peering between the 10.0.0.0/16 VPC (vpc-02901bcbb89561298) and the 10.50.0.0/16 VPC (vpc-096b686376892bb49). In the 10.50.0.0/16 VPC, the internal NLB mon-internal-terraform-example has the target group api-health-terraform-example (TCP/9090, target type ip) targeting 10.0.101.222. That IP is ENI eni-0fe5a958a733a13fe in the 10.0.0.0/16 VPC, and that ENI is attached to sg-089e5107637083db5. The target health is currently healthy, proving traffic from 10.50.0.0/16 to 10.0.101.222:9090 is flowing. After narrowing to 10.0.0.0/16, sources from 10.50.0.0/16 will be excluded and dropped by the ENI’s security group, so the NLB health checks and any scraping/traffic from the monitoring VPC will fail. This is direct evidence of a real break in cross‑VPC traffic caused solely by the proposed change.

✔ Hypothesis proven

---

Expanded security group ingress to new external IP on TCP 443

Observations 2

Hypothesis

Security group ingress rules are being expanded to allow inbound TCP 443 from external CIDR 203.0.113.137/32 (e.g., on security group sg-03cf38efd953aa056). This loosens previously stricter CIDR restrictions and could permit unintended external access to production API endpoints and other HTTPS services. If the newly allowed IP is malicious, compromised, or misconfigured, it may expose sensitive services or data and bypass existing network-based controls that relied on tighter source IP ranges.

Investigation

The diff shows a single new CIDR 203.0.113.137/32 on TCP 443 being added to security group sg-03cf38efd953aa056 with description "NewCo 37". The current state of that security group already contains numerous /32 customer entries on port 443 and is explicitly described as "Customer IP whitelist for API access - updated frequently". This indicates the design intent is to allow direct HTTPS access from specific external customer IPs. The group is attached to the production API instance i-084178432f016fcd2, which has a public EIP 13.134.236.98; adding one more /32 simply continues the existing pattern and does not broaden access beyond a single host. No evidence of an overly broad CIDR, unintended attachment, or policy bypass was found. The internet-facing ALB remains separate and continues to front HTTP/80 with its own SG, so this change does not alter ALB exposure. Given this is a routine whitelist extension consistent with current architecture, there is insufficient evidence of a new, specific failure or exposure beyond existing risk management processes. The hypothesis is therefore not a real risk for this change.

✖ Hypothesis disproven

---

💥 Blast Radius

Items 94

Edges 302

[github-actions]

✅ Auto-Approved

---

🟢 Decision

Auto-approved: All safety checks passed

---

📊 Signals Summary

Routine 🟢 +2

---

🔥 Risks Summary

High 0 · Medium 1 · Low 0

---

💥 Blast Radius

Items 94 · Edges 302

---

View full analysis in Overmind ↗