Skip to content

security: narrow internal ingress CIDR (JIRA-4521)#523

Open
dylanratcliffe wants to merge 1 commit into
mainfrom
security/jira-4521-narrow-internal-cidr-20260611-141153
Open

security: narrow internal ingress CIDR (JIRA-4521)#523
dylanratcliffe wants to merge 1 commit into
mainfrom
security/jira-4521-narrow-internal-cidr-20260611-141153

Conversation

@dylanratcliffe

Copy link
Copy Markdown
Member

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

Copy link
Copy Markdown

Caution

[High Risk] New external whitelist rule will expose the public API instance directly on HTTPS

The change adds a new tcp/443 ingress rule for 203.0.113.156/32 to the shared security group 540044833068.eu-west-2.ec2-security-group.sg-03cf38efd953aa056 (customer-api-access). That group is already attached to 540044833068.eu-west-2.ec2-instance.i-08370f7d3e016a56a through eni-06e938e1d4cc985ec, and the instance currently has public IP 13.134.236.98. This means the new rule will immediately create direct external HTTPS reachability from that source IP to the instance itself.

That is a real segmentation failure, not just a policy concern. Other API traffic in this environment is fronted by api-207c90ee-alb, but this instance is directly internet-addressable and the change does not add any compensating control such as WAF, CloudFront, or removal of the public endpoint. Because the rule is being added to a shared whitelist SG already in use on a live production instance, it expands the attack surface and bypasses the normal perimeter layer for backend access.
View reasoning tree here.

Caution

[High Risk] Tightened shared security group CIDR will block existing monitoring and health-check traffic from the 10.50.0.0/16 monitoring VPC

The change narrows ingress on the shared internal-services security group sg-089e5107637083db5 from 10.0.0.0/8 to 10.0.0.0/16 for ports 8080, 443, and 9090. That security group is attached to production instances and is explicitly used for health checks, monitoring, and internal mesh traffic. Current blast-radius data shows the monitoring NLB mon-internal-terraform-example and its target group live in VPC 10.50.0.0/16, while one of the protected targets at 10.0.101.219:9090 is currently healthy and has sg-089e5107637083db5 attached.

After the change, traffic originating from the monitoring VPC's 10.50.0.0/16 addresses will no longer match the new ingress CIDR. That will cut off the existing healthy monitoring path on port 9090, and the same CIDR reduction also applies to 8080 and 443, so internal health checks and service-to-service HTTPS from other 10.x.x.x networks outside 10.0.0.0/16 will be blocked as well. This will create false unhealthy states and monitoring blind spots on a shared high-fanout security group, making the operational impact high.
View reasoning tree here.

Signals

Routine → Multiple network and compute resources are showing unusual routine changes at only 1-2 events/week for the last 4-5 months, while one resource recorded 2 events/day for the last day.

Additional Change Details: Items 50 Edges 114 model|risks_v6 ✨Encryption Key State Risk ✨KMS Key Creation

View in Overmind

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant