VPC CNI recently introduced support for Kubernetes Network policies using eBPF data plane. Current implementation of Network policy feature does not gate pod launch until policies are reconciled against it and so there can be a time window between when the Pod moves to Ready state and when the network policies are reconciled and configured against the pod during which no policies are enforced against either ingress or egress traffic from the pod. Network Policy controller will start the reconciliation process for a new pod after an IP address is assigned to the Pod.
We plan to introduce a new mode, Strict mode, that will gate pod launch until active network policies are enforced against a newly launched pod. We attempt to program relevant firewall entries for this pod, if the local node agent is aware of the policies configured against it. For example, if this is a new replica of an existing pod/deployment then the local
node agent will have the policy information available to it in it's cache. If not, we will leave the pod in default deny state
until the Network Policy controller reconciles existing policies against this pod.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.
Issue #, if available: NA
Description of changes:
VPC CNI recently introduced support for Kubernetes Network policies using eBPF data plane. Current implementation of Network policy feature does not gate pod launch until policies are reconciled against it and so there can be a time window between when the Pod moves to Ready state and when the network policies are reconciled and configured against the pod during which no policies are enforced against either ingress or egress traffic from the pod. Network Policy controller will start the reconciliation process for a new pod after an IP address is assigned to the Pod.
We plan to introduce a new mode,
Strictmode, that will gate pod launch until active network policies are enforced against a newly launched pod. We attempt to program relevant firewall entries for this pod, if the local node agent is aware of the policies configured against it. For example, if this is a new replica of an existing pod/deployment then the local node agent will have the policy information available to it in it's cache. If not, we will leave the pod in default deny state until the Network Policy controller reconciles existing policies against this pod.By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.