Introduction

If an ALB-backed ingress is public by default, the safest fix is not a vague hardening checklist. You need to decide whether the load balancer should be internal only, internet-facing but IP-restricted, or internet-facing with authentication in front of the app. On AWS ALB ingress, those choices are controlled primarily by scheme, network access, and listener-level auth.

Start with the load balancer scheme

The strongest protection is to avoid creating a public ALB at all. In the AWS Load Balancer Controller, an internal ALB is the normal way to keep endpoints off the public internet:

1apiVersion: networking.k8s.io/v1
2kind: Ingress
3metadata:
4  name: internal-app
5  annotations:
6    alb.ingress.kubernetes.io/scheme: internal
7spec:
8  ingressClassName: alb

An internal ALB is reachable only inside the VPC and connected private networks. If your endpoints are meant only for internal services, VPN users, or corporate networks, this is the cleanest solution.

Restrict inbound CIDRs when public exposure is unavoidable

Sometimes the ALB must remain internet-facing, but only a known address range should reach it. In that case, narrow the frontend exposure instead of leaving the default wide open:

1metadata:
2  annotations:
3    alb.ingress.kubernetes.io/scheme: internet-facing
4    alb.ingress.kubernetes.io/inbound-cidrs: 203.0.113.0/24,198.51.100.10/32

This is a network-layer restriction. It stops unwanted clients before the request even reaches your backend service.

If you manage security groups directly through controller annotations or surrounding infrastructure, remember that the effective AWS security-group rules are what ultimately matter. Always verify the created ALB and target rules, not just the YAML.

Add authentication at the ALB when appropriate

For endpoints that must be reachable from outside but only by authenticated users, ALB listener authentication can help. The AWS load balancer integration supports authentication flows such as Cognito or OIDC before forwarding traffic.

That is useful for:

• internal admin tools
• dashboards
• restricted partner portals

The key point is that listener auth happens before your application receives the request, which reduces accidental exposure of unauthenticated backend routes.

Path rules are routing, not protection

A common misconception is that putting a sensitive app under /admin or /internal makes it protected. It does not. Path rules only decide where the ALB sends traffic.

Real protection comes from:

• internal scheme
• restricted inbound CIDRs or security groups
• ALB authentication
• application-level authorization

If the ALB is internet-facing and unauthenticated, a path rule does not make the backend private.

Use defense in depth

Even with an internal or restricted ALB, keep authorization inside the service. Ingress-level controls reduce network exposure, but they do not replace business-level permission checks.

A practical layered model often looks like:

1. internal ALB whenever possible
2. explicit CIDR restrictions when public reachability is required
3. HTTPS listeners
4. optional ALB auth for user-facing restricted tools
5. backend authorization inside the application

This approach prevents one bad annotation or one mistaken DNS record from becoming a full public exposure incident.

Common Pitfalls

The biggest mistake is leaving the ALB internet-facing with default ingress exposure and assuming the app is private because nobody knows the hostname. If the ALB is reachable, the endpoint is exposed.

Another mistake is relying only on path routing to protect sensitive endpoints. Routing is not access control.

Developers also forget that controller-managed security groups and ALB annotations interact. The final AWS resource state is what counts, not only the Ingress manifest.

Finally, do not skip backend authorization just because the ALB is internal. Internal-only access reduces attack surface, but it does not define who is actually allowed to use the endpoint.

Summary

• The safest way to keep ALB ingress endpoints private is usually to use an internal scheme.
• If public reachability is required, restrict inbound CIDRs or security groups deliberately.
• Use ALB authentication for externally reachable but user-restricted services.
• Path-based routing does not secure an endpoint by itself.
• Combine ALB-level controls with application authorization instead of treating them as substitutes.