If you mean traffic from outside of the cluster, there is no reason for their cluster nodes to have public IP addresses, so they wouldn't even be routable from

If you mean traffic from outside of the cluster, there is no reason for their cluster nodes to have public IP addresses, so they wouldn't even be routable from outside the VPC. I would expect this controller to run on the control plane and probably not be Internet-accessible by any means, but even if it were, I'm sure the security group only allows UDP port 6666 from inside the cluster, presumably based on source security group, not IP, so even if you could somehow spoof a private IP address and get it into the VPC, it would still not be accepted. If you mean malicious traffic coming from their own pods, they could simply add Kubernetes network policies not allowing UDP port 6666 egress from any pod since the traffic they're actually hoping for would always come from a kernel, not a pod, and thus egress from a different interface. So now you're left with the remaining attack vectors being spoofed IPs, or potentially even the correct IP but a spoofed packet, coming directly from EC2 instances in the same VPC, either by launching separate instances or compromising clusters nodes at the OS level. An insider with that level of access is always a threat pretty much no matter what you do because they could just delete your nodes through the EC2 service. You mitigate that with thorough audit logging, no shared or long-lived credentials, deep vetting of a very small number of personnel you give that level of access to, and the threat of near-certain jail time if someone does it on purpose anyway.