We're in the process of implementing CiliumClusterwideNetworkPolicies with a default-deny rule for incoming traffic in our app namespaces. Currently, we have specific allow policies set for each of our services, like backend and frontend applications, which are defined by source namespaces and relevant ports.
Now I'm wondering how much detail I should go into. For instance, should I also tighten access for infrastructure namespaces like gateway-system, monitoring, and kube-system? Or would that be excessive since they're managed by the platform team?
Regarding egress, is it beneficial to limit outbound traffic for each service, or would a combination of default-deny ingress and allow-list suffice for most threat scenarios? Has anyone experienced regrets from being overly granular, spending more time on debugging policy issues than gaining security benefits? I'm trying to balance being "secure enough for SOC2/compliance" with not causing deployment issues every time.
3 Answers
The key thing to remember is to only make your policies as detailed as necessary to meet your requirements. More granularity means more complexity, and complexity can be problematic.
Ultimately, it's about the effort you're willing to invest. If your egress is set properly, enforcing ingress becomes less critical. You should be careful with how broad your egress rules are since that can open up unexpected access paths. If egress isn't well-managed, restricting ingress could be your backup for protecting services. But in most cases, if you've got egress figured out, those infrastructure namespaces shouldn't be too concerning.
You should determine what needs open access and what should be restricted. For example, your monitoring system should have access to all workloads across any port. Always deny all incoming internet traffic, if possible. Use a single identity-aware proxy for all incoming internet traffic to communicate with your services instead of allowing direct access to them. As for egress, think about default-deny if you really need that level of security—otherwise, it might be more effort than required. It's best to leave system namespaces alone to prevent disruption to the cluster.
Great point! It's important to note that ingress and egress rules in Cilium are independent. Denying ingress doesn't prevent egress, so you need to manage both carefully. I've found that consistently denying both ingress and egress is a sound approach, especially in regulated environments, although it can lead to service disruptions.