-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Network Policy - Strict mode support #209
Conversation
pkg/rpc/rpc_handler.go
Outdated
} | ||
|
||
// RunRPCHandler handles request from gRPC | ||
// func RunRPCHandler(ebpfClient ebpf.BpfClient) error { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Need to remove the stale line
func (l *bpfClient) IsMapUpdateRequired(podIdentifier string) bool { | ||
mapUpdateRequired := false | ||
if _, ok := l.policyEndpointeBPFContext.Load(podIdentifier); !ok { | ||
l.logger.Info("No map instance found") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: Do we need this log line since the caller has log already?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
just a minor nit, rest lgtm
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
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,
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 localnode 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.