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]

Caution

[High Risk] New API server will become a direct public EC2 endpoint and fail internal health checks

The new module.api_access[0].aws_instance.api_server is being given Elastic IP 13.134.236.98 and attached to the shared customer allowlist security group sg-03cf38efd953aa056, which is also being widened with a new external /32 on port 443. Even though subnet-07b5b1fb2ba02f964 does not auto-assign public IPs, the explicit EIP association makes this instance directly internet-reachable from every CIDR in that shared allowlist. That creates a direct public EC2 endpoint instead of keeping access behind a load balancer, which violates the organization’s network-access policy and expands the blast radius of a shared security-group exception.

At the same time, the instance’s port 9090 health server is protected by sg-089e5107637083db5, and this change narrows that ingress from 10.0.0.0/8 to 10.0.0.0/16. The monitoring target group api-health-terraform-example sits behind the internal NLB in VPC 10.50.0.0/16, so its health checks to the new attached target will be blocked. The target will register but remain unhealthy, causing monitoring and health-based routing for the new API server to fail.
_{View reasoning tree here.}

Caution

[High Risk] EIP cutover points traffic at a new instance that is not configured for the production ALB path

This change creates a new EC2 instance for API access in the public subnet subnet-07b5b1fb2ba02f964, then prepares to rebind the production Elastic IP 13.134.236.98 to it. The new instance’s bootstrap only starts a simple HTTP server on port 9090, and the only new load balancer attachment in the plan registers it to the separate target group api-health-terraform-example on port 9090. The existing public ALB api-207c90ee-alb still uses target group api-207c90ee-tg, which health-checks /health on port 80, and no diff updates that production target group or adds the new instance to it.

If traffic or operational access is cut over to the new instance via the EIP, consumers will land on a host that is not configured like the current production ALB target path. Direct callers tied to the old address pattern will see endpoint changes, and the new host will not satisfy the production ALB’s current port 80 health model. This creates a real availability risk during cutover, and it also extends an already noncompliant pattern of exposing EC2 instances with public IPs directly to the internet.
_{View reasoning tree here.}

Signals

Routine → Multiple AWS infrastructure resources showing unusual infrequent update patterns, with load balancer target attachment resources at 1 event/week for the last 3 months and 2 events/week for the last 3 weeks, API server instance resources at 2 events/week for the last 3 months, and an elastic IP resource at 1 event/week for the last 3 months, which is rare compared to typical patterns.

_{Additional Change Details:} Items 66 Edges 140 model|risks_v6 ✨Encryption Key State Risk ✨KMS Key Creation