The risk comes from annotation semantics. One annotation replaces the default security group, while the other adds to it. If the default group already allows internet-wide access on the service port, adding a restrictive group does not remove that exposure. The result is an apparently locked down load balancer that still accepts traffic from anywhere.
Why a load balancer annotation mistake creates hidden exposure
The problem is not just that the wrong annotation makes a deployment less tidy. It changes which security group actually governs inbound access, and that can leave the original exposure in place even after a team believes it has applied a tighter rule set. In practice, the failure is semantic, not cosmetic: the annotation decides whether the load balancer uses a replacement group or an additional one, so the operator’s mental model can diverge sharply from the real traffic path.
That matters because load balancers sit at a trust boundary. If a service was already reachable from broad internet ranges, a restrictive group that is only added alongside the default group does not eliminate the broader path. Teams often look at the new annotation value and assume the previous exposure has been overwritten, when the platform has simply accumulated another control layer. The AWS documentation on load balancer security group behaviour is the right primary reference for understanding that distinction, especially when reviewing controller-managed ingress objects and how security groups are attached to an Application Load Balancer.
In practice, many security teams discover the real exposure only after they inspect live listener reachability rather than the manifest they believed was authoritative.
How the annotation semantics change the traffic path
The practical difference comes down to whether the annotation substitutes the security group or supplements it. If it substitutes, the load balancer’s inbound policy is effectively reset to the new group. If it supplements, the load balancer retains the existing group and gains another one, which means any permissive rule in the retained group remains part of the effective access path. That is why the outcome can be broader than the YAML appears to suggest.
This is especially easy to misread in environments where security groups are managed across multiple layers: a platform team may define a standard restrictive group, while application teams assume their annotation is authoritative. The controller, however, resolves the final state according to annotation semantics and the existing resource configuration, not human intent. The result can be a mixed posture where one group looks correct in isolation but the effective policy still admits traffic from anywhere on the exposed port.
A sensible review process is to verify the effective security group set on the load balancer, confirm which rules are active, and compare that live state with the intended ingress design. That check should happen after rollout, not just during code review, because the dangerous condition is a mismatch between declared intent and realised network policy. This is also why change control should focus on the resulting listener exposure, not only on whether the annotation parses cleanly.
- Check whether the annotation replaces or adds to the existing security group association.
- Review the live security group rules on the load balancer, not just the Kubernetes manifest.
- Confirm that any retained default group does not already permit the public path you are trying to close.
- Validate exposure from an external vantage point after deployment.
When the controller is not the source of truth for the full security posture, the guidance breaks down because the effective policy may be inherited from pre-existing infrastructure state.
Where teams overestimate how much the restrictive rule helps
Tighter annotation use often increases confidence faster than it reduces exposure, so teams have to balance declarative intent against inherited infrastructure state. The common mistake is to treat a new group as a replacement when it may only be an addition, particularly in shared clusters or long-lived services where the original group already has broad ingress.
There is also an operational edge case when multiple teams touch the same load balancer lifecycle. One team may harden the annotation while another keeps the original group for legacy connectivity, leaving the service reachable through a path nobody meant to preserve. Guidance on whether to allow shared group inheritance varies by platform design, but the consensus is clear that teams should not rely on annotation readability alone to infer effective exposure.
For practitioners, the key question is whether the load balancer is being governed as a fresh object or as a modified object with pre-existing access history. If it is the latter, the risk is usually larger than expected because the old trust boundary remains in force until someone proves otherwise. The safest interpretation is to assume the visible annotation is only part of the policy until the live network path has been checked.
Practitioner Guidance: Treat annotation changes as exposure changes, not just configuration changes, and verify the live security group association after every rollout that touches ingress. The first thing to confirm is whether the controller is replacing policy or layering policy, because that single distinction determines whether the old access path still survives.
Practitioner takeaway: The material risk is not the annotation syntax itself but the false assurance it creates when inherited ingress remains active behind a seemingly restrictive change.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 4 — Secure Configuration of Enterprise Assets and Software | Wrong annotations can leave insecure ingress configuration in place. |
| 6 — Access Control Management | The issue is effective network access, not just declared intent. | |
| Recommendation — Standardise and verify secure ingress configuration before promoting load balancer changes. Review and revoke unintended inbound access paths on exposed services. | ||
| NIST CSF 2.0 | PR.AC-5 — Network Integrity is Protected | The question is about preserving intended network boundary enforcement. |
| PR.AC-4 — Access Permissions and Authorizations are Managed | Effective permissions can persist when annotations add rather than replace. | |
| DE.CM-1 — The Network is Monitored to Detect Potential Incidents | Teams need visibility into whether exposure still exists after rollout. | |
| Recommendation — Validate that boundary controls enforce the intended reachable path after each deployment. Confirm the live authorization state matches the intended access model. Monitor externally reachable listeners and alert on unexpected public exposure. | ||
| MITRE ATT&CK | T1133 — External Remote Services | Public load balancer exposure creates an externally reachable access surface. |
| Recommendation — Hunt for unintended externally reachable services and close the exposed path. | ||
Related resources from NHI Mgmt Group
- Why do leaked credentials often create larger incidents than teams expect?
- Why do service principals create a larger escalation risk than many teams expect?
- What do security teams get wrong about AWS access-key exposure?
- Why do machine identities create larger lateral movement risk than teams expect?
