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 module.api_access[0].aws_security_group.customer_access showing 1 event/day for the last 2 months, which is infrequent compared to typical patterns.
Policies 🔴 ▃▂▁ Multiple policy violations detected, including missing tags and lack of server-side encryption on S3 buckets, and security risks from open SSH access.

View signals ↗

---

🔥 Risks

Tip

✔ All risks disproven

We investigated 2 potential risks across 9 resources and verified each was safe. See the investigation details below.

---

🧠 Reasoning · ✖ 2 · ✔ 0

Expanded external security group ingress CIDR increasing exposure on TCP 443

Observations 2

Hypothesis

Changes to AWS security group sg-03cf38efd953aa056 are widening external ingress by adding CIDR 203.0.113.154/32 on TCP port 443. This expands the set of external IPs that can reach resources using this security group and increases network exposure. If the CIDR is misconfigured, unexpected, or controlled by an untrusted party, it could allow unauthorized access to HTTPS endpoints, increasing the risk of compromise or data exfiltration.

Investigation

What’s actually changing is a single-host IPv4 CIDR 203.0.113.154/32 being added to inbound TCP 443 on security group sg-03cf38efd953aa056. The group’s description is “Customer IP whitelist for API access - updated frequently,” and its current rules already include many customer-labeled single-IP entries (NewCo 1..53) on port 443. Adding NewCo 54 keeps the same pattern of tightly scoped, single-IP access rather than broadly widening exposure. The associated EC2 instance (production-api-server) uses this security group and already exposes 443 to other whitelisted IPs; this change simply authorizes one additional, explicitly named client. Separately, the only other planned change narrows internal access on a different SG (from 10.0.0.0/8 to 10.0.0.0/16), which reduces exposure, not increases it.

From AWS documentation, security groups are stateful and evaluate explicit allow rules; adding a specific CIDR for a single IP on a specific port is the least-privilege approach compared to broad sources like 0.0.0.0/0, which AWS warns against when not required. There’s no evidence here that the new CIDR is unintended or untrusted—no broad ranges, no 0.0.0.0/0, and naming matches the existing convention—so the hypothesis is speculative rather than a concrete risk. (docs.aws.amazon.com)

✖ Hypothesis disproven

---

Narrowed internal security group CIDRs potentially blocking legitimate internal traffic and monitoring

Observations 3

Hypothesis

Ingress CIDR ranges for internal traffic are being narrowed from 10.0.0.0/8 to 10.0.0.0/16, including in security group sg-089e5107637083db5 for ports 8080, 443, and 9090. This reduces the allowed internal source IP range and may block legitimate hosts in 10.0.0.0/8 but outside 10.0.0.0/16 from reaching services behind these security groups. Impacted traffic can include health checks, internal HTTPS traffic, monitoring, and Prometheus scraping, leading to failed connectivity, degraded observability, false alerts, or service disruption for instances and services that previously depended on 10.0.0.0/8 access.

Investigation

What’s changing: sg-089e5107637083db5 narrows three ingress rules (8080, 443, 9090) from 10.0.0.0/8 to 10.0.0.0/16. The only other planned change is sg-03cf38efd953aa056 adding a new customer /32 on port 443; nothing there widens or restricts internal access. Evidence from current state: the VPC’s CIDR is 10.0.0.0/16 and the instance’s private IP is 10.0.101.129 in subnet 10.0.101.0/24, all within 10.0.0.0/16 (540044833068.eu-west-2.ec2-vpc.vpc-02901bcbb89561298; 540044833068.eu-west-2.ec2-subnet.subnet-07b5b1fb2ba02f964; 540044833068.eu-west-2.ec2-instance.i-09722f3f74d541ec3). There is no evidence of VPC peering, Transit Gateway, VPN/Direct Connect, or secondary VPC CIDR blocks that would introduce legitimate 10.0.0.0/8 sources outside this /16. On this ENI, port 443 also remains allowed for numerous external customer IPs via sg-03cf38efd953aa056, so customer access is unaffected. By AWS design, security group rules are allow-only and the rules of multiple SGs on an interface are aggregated, so restricting sg-089e5107637083db5 to the VPC’s CIDR will still allow all in-VPC traffic that previously depended on it while not impacting the separate customer whitelist SG. This aligns ingress to the actual VPC address space and reduces unnecessary exposure rather than causing breakage. Documentation: VPC CIDR defines the in-VPC private address range (10.0.0.0/16 here), and multiple SGs on an ENI are evaluated as a union of allows. (docs.aws.amazon.com)

✖ Hypothesis disproven

---

💥 Blast Radius

Items 9

Edges 34

[github-actions]

⛔ Auto-Blocked

---

🔴 Decision

Auto-blocked: Routine score (-5) is below minimum (-1)

---

📊 Signals Summary

Routine 🔴 -5

---

🔥 Risks Summary

High 0 · Medium 0 · Low 0

---

💥 Blast Radius

Items 17 · Edges 97

---

View full analysis in Overmind ↗

[github-actions]

⛔ Auto-Blocked

---

🔴 Decision

Auto-blocked: Policy signal (-3) is below threshold (-2); Routine score (-5) is below minimum (-1)

---

📊 Signals Summary

Routine 🔴 -5

Policies 🔴 -3

---

🔥 Risks Summary

High 0 · Medium 0 · Low 0

---

💥 Blast Radius

Items 9 · Edges 34

---

View full analysis in Overmind ↗