Azure CNI Powered by Cilium L7/CRD Network Policy

[chasewilson]

This issue is to track support for Azure CNI Powered by Cilium Network Policy capability expansions.

Expansions Include:

1. Layer 7 Network Policy support
2. Cilium Custom Network Policies
   • Currently, one of the most requisition options is DNS filtering based policy support

This feature has a some good support already tracked in this GitHub Issue.

[ghost]

@aanandr, @phealy would you be able to assist?

Issue Details

---

This issue is to track support for Azure CNI Powered by Cilium Network Policy capability expansions. Expansions Include: 1. Layer 7 Network Policy support 2. Cilium Custom Network Policies - Currently, one of the most requisition options is DNS filtering based policy support This feature has a some good support already tracked in [this GitHub Issue](https://github.com/Azure/AKS/issues/3450).

Author:	chasewilson
Assignees:	-
Labels:	`networking`, `networking/azcni`, `network-policies`
Milestone:	-

[Hanifff]

Hi, @phealy any updates?

[chasewilson]

Hey @Hanifff, thanks for commenting here. This Item is to track the request and interest for these features in Azure CNI Powered by Cilium. Right now there isn't a timeline but we are keeping an eye on what our customers want and would like it to build as needs arise.

Please feel free to provide feedback here about this and point others to add their reactions or feedback to make sure we're prioritizing our work correctly :)

[westleydion]

This would be really good to have.

[chasewilson]

This would be really good to have.

Which portion of this are you most interested in? The Cilium Specific policies or the L7 capabilities?

[EppO]

This would be really good to have.

Which portion of this are you most interested in? The Cilium Specific policies or the L7 capabilities?

My 2 cents here: both L3 DNS based rules and L7 policies, the former is actually a must-have. I guess both require Cilium Network Policies as the Kubernetes Network Policies don't support them.

[ebc92]

My team is also missing this feature, DNS based network policies is a must have for us.

[illrill]

Not stale. Lack of CiliumNetworkPolicy L3 FQDN rules is one of the reasons why we still need to BYOCNI, just to even use the most basic features of Cilium.

[EppO]

The issue is still relevant

[lieberlois]

Apparently, Azure will start supporting this in 1-2 months. Source: Talked to Isovalent employees at the KCD in Munich, Germany. Unfortunatley, Hubble UI integration etc. will take longer.

[chasewilson]

@lieberlois thanks for the input here. Would you mind clarifying in what scenario Isovalent was planning L7 support?

From our side, we currently have support for hubble relay with self-managed UI and we're not working on l7 quite yet but are working on supporting FQDN filtering hopefully by the end of this month.

[lieberlois]

@chasewilson This was in the context of layer 7 network policies 😄

[chasewilson]

@lieberlois sorry for the confusion 😆.

I was meaning, did they say specifically Azure CNI Powered by Cilum, The enterprise marketplace offering they have, or the OSS Cilium support?

[lieberlois]

@chasewilson As far as I understood yes, Azure CNI Powered by Cilium

[chasewilson]

@lieberlois thanks for the clarification.

As of right now, we're not on L7 yet as we've had more requests (though L7 is highly requested as well) for FQDN and will be aiming for L7 after we get that out. So, not in the next month or two but should have some updates on timelines within that period.

[lieberlois]

What exactly are you referring to then? Layer 7 network policies leverage FQDNs so what is missing then?

[chasewilson]

What exactly are you referring to then? Layer 7 network policies leverage FQDNs so what is missing then?

Good question.

Cilium L7 policies and FQDN policies both work at Layer 7, but they have different focuses. L7 policies give you detailed control over app-specific traffic, letting you set rules based on things like HTTP methods or gRPC services.

On the other hand, FQDN policies are about controlling outbound traffic based on domain names. This is helpful in dynamic environments where IP addresses of external services change, but domain names stay the same.

[lieberlois]

Okay you seem to have different naming than the typical Service Mesh terminology then 😄 I meant egress policies based on L7 Hostnames (FQDNs)

[chasewilson]

@lieberlois aaahhh gotcha ok and I'm referring to L7 as application operations traffic. PUTs, GETs, etc.

[siegenthalerroger]

Still relevant

[laurenbo]

still relevant also, we await eagerly for a public preview with the FQDN policies.

[maur1]

still relevant also, we await eagerly for a public preview with the FQDN policies