Add network policy filtering for user-v2 networking

[skaegi]

Implements egress traffic filtering with:

• Protocol, port, IP/CIDR, and domain-based rules
• DNS packet snooping for domain-to-IP tracking
• ICMP support (ICMPv4/ICMPv6) - partial - awaiting gvisor fix
• Policy validation with strict error checking
• DNS tracker with 10k domain limit and TTL expiration

Usage: limactl network create NAME --policy policy.yaml

Signed-off-by: Simon Kaegi simon.kaegi@gmail.com

[skaegi]

Apologies in advance for dropping a jumbo PR. This is a new feature that I'm interested in continuing to work on in particular for use with AI coding assistants. I recognize there is still polish work to do here but I wanted to get it out shortly after 2.0 as I'm hoping it could be considered for the roadmap.

[AkihiroSuda]

No bandwidth to investigate much during KubeCon, but we should look into whether we can reuse or mimic some existing format in the field of SDN.

We may also want to set up policy for accepting AI-generated codes.
Especially how to ensure that the code is verified by the human submitter, in both technological and legal aspects.

[skaegi]

Sounds good. I'm happy to join an effort to help develop a process for accepting AI-assisted code, as I expect it to become increasingly common. Ultimately, I believe submitters are responsible for every line they submit and should have reviewed it all thoroughly. A checklist and process would be helpful here.

Re: format — The format is quite similar to Calico with a bit of Cilium, as I'm very familiar with those. I didn't go with K8s NetworkPolicy because it lacks "deny," which I've found to be very valuable in the past. I use "priority" vs. "order" as it makes better sense to me. I also made "ips" and "ports" more general to accept common formats instead of breaking things out into more fields.

Another gotcha: I (gulp) used reflection to access the gvproxy stack. I tried many different approaches beforehand, and this was the cleanest in the end, but it would be good to work with the team to expose a public method there.

[AkihiroSuda]

Would it be possible to implement this as a third-party plugin?

Maybe the user-v2 switch Lima should speak OpenFlow to delegate the filter rules to an OpenFlow controller running as a separate process?

[skaegi]

Would it be possible to implement this as a third-party plugin?

Maybe the user-v2 switch Lima should speak OpenFlow to delegate the filter rules to an OpenFlow controller running as a separate process?

I'll certainly look and think about it. Another alternative maybe worth considering is an in-process plugin(?) I end up doing one call to augment the underlying VirtualNetwork in gvproxy.go; perhaps that could be the plugin extension point.
(After trying this out -- in-process plugin wouldn't work on windows and also sort of painful)

[skaegi]

After playing around here this we could implement a --filter plugin similar to --interface with a grpc unix-socket and allow plugging in of any policy engine. I could create a separate PR for this quite easily as most of the heavy lifting here is already sorted. I'd have to try things out, but It would look something like this ...

Protocol:

  service FilterService {
    rpc CheckEgress(CheckRequest) returns (CheckResponse);
  }

  message CheckRequest {
    string dst_ip = 1;
    uint32 dst_port = 2;
    string protocol = 3;
    repeated string dst_domains = 4;  // we track domains and provide this context in the check
  }

  message CheckResponse {
    bool allowed = 1;
    uint32 ttl_seconds = 2;  // we cache decisions for the ttl to keep things performant
  }

Configuration:

  # Start filter plugin
  my-filter-plugin --policy my-policy.yaml --socket /var/run/lima/my-filter.sock &

  # Create network pointing to filter socket
  limactl network create my-filtered-network \
    --gateway 192.168.123.1/24 \
    --filter unix:///var/run/lima/my-filter.sock

Is this the sort of thing you had in mind?

[alexandear]

Please fix the lint issues.

[AkihiroSuda]

Please fix the lint issues.

Let's discuss the design before the lint issues.
The filter gRPC looks fine to me, but basically we should try to avoid reinventing an existing wheel

[skaegi]

Sorry for the delay guys... will look at this and update over the holidays.

[AkihiroSuda]

@lima-vm/maintainers The proposed gRPC looks good?
#4326 (comment)

[AkihiroSuda]

ping @lima-vm/maintainers

Can we ask @skaegi to continue with his gRPC proposal? #4326 (comment)

The proposed API looks good to me, at least as an experimental feature

[AkihiroSuda]

@skaegi Could you try implementing a POC with your proposed gRPC?
Not sure if we can merge it in v2.1 (next month), but this proposal seems definitely useful, e.g., for sandboxing AI agents' communications