Why you should consider implementing egress NetworkPolicy
Most people see the value of ingress NetworkPolicy, but convincing them to implement egress NetworkPolicy tends to be a little more difficult. The thinking seems to be “since ingress NetworkPolicies stop the ‘bad guys’ from getting to my app, why do I need to do anything else? Besides, egress NetworkPolicies are (usually) harder to implement and maintain”.
One flaw in this logic is that while ingress NetworkPolicies are very important, they don’t stop ‘bad guys’ who can use the exposed application ports to exploit the application via a vulnerability like log4shell. A good “defence in depth” strategy (of which egress NetworkPolicies can be an important component) can significantly increase the security of your applications.
The principle of least privilege doesn’t apply just to privileges associated with userids, but also to the “privilege” of network connectivity. If your application can’t make connections other than what you have specifically defined, the chance that an exploit will result in significant data exfiltration is signficantly reduced.
You may even protect yourself from some inadvertent application configuration errors (e.g. oops, “we deployed the dev configuration to the production Namespace and and because the password is different the userid got locked out…“. The password is different between dev and prod, right? Right???)
