Because it sounds like something spamming UDP packets with IP spoofing could take down all kubernetes nodes.
Maybe signing the kernel panic message could help too.
Because it sounds like something spamming UDP packets with IP spoofing could take down all kubernetes nodes.
Maybe signing the kernel panic message could help too.
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.
There’s no spoofing happening here…