I have been busy creating lots of content recently, if not on my personal blog. I’ve been creating a few videos for some of the work I am doing at Isovalent. Most of them are short videos (under 15 minutes) we have named “Cilium Flash” where we go through a particular feature.
The first one is only 3 minutes long and covers the official support of Cilium with AKS Bring Your Own CNI (Container Network Interface).
Why wouldn’t you want a CNI ? Well, by default, Azure provides two networking options for AKS – Kubenet (basic) and Azure CNI (advanced). And while the Azure CNI has some good capabilities compared to Kubenet, it’s still not as powerful as Cilium (for example, you can’t do Layer 7 network policies).
You could do CNI chaining (put a CNI on top another one) to get the extra functionality of a CNI on top of another one but it’s harder to operate and troubleshoot.
Before the Bring Your Own CNI option, we had to deploy a cluster with the Azure CNI and use taints to install Cilium:
It’s a pretty common Kubernetes deployment model and why tools like taints exist in the first place. But as you can see, there were a number of steps required, including creating and deleting nodepools and taints to prevent applications from being scheduled until Cilium was ready.
There was no option to deploy a cluster without any CNI until this feature came along.
Now, it’s pretty straight-forward with the BYOCNI option of deploying a cluster without a CNI:
I admit that Azure, out of the 3 main clouds is the one I have the least played with. But as you’ll see in the short video above (or in the event shorter GIF below), creating clusters on AKS was pretty straightforward with the Azure CLI and deploying clusters without a CNI was super easy.
Thanks for reading.
Reference: This blog post from Pixel Robots nicely walks through the installation but as you can see, it’s very straight-forward.
nicovibert.com 
Created AKS cluster with the BYOCNI preview. Now having IP issues.
Having issues with publishing external LoadBalancer IP – the address is left empty on the created Ingress with ingressClassName=Cilium
LikeLike
Thank you for the response.
Sorry Nico, your reply got bumped to my junk mail. The issue I was having was resolved – and not related to BGP. I had to reset the demon to force all my reconfigurations.
Now that I have passed that. I’m trying to get AuthN with OpenID Connect (Okta). CiliumNetworkPolicy does not include the
envoy – “type.googleapis.com/envoy.extensions.filters.http.jwt_authn.v3.JwtAuthentication.” It has only AuthZ. I used oauth2-proxy now for authentication. However, looking for a surface in the network policy configuration to extract the jwt-token.
My goal is ZeroTrust endpoint policy control – to authenticate with Okta IdP, introspect the jwt and qualify the claims – all in cilium. Do you have any example of this using Cilium?
Thank you for the reply!
LikeLike
If I understand your requirement correctly, this type of network policy based on dynamic certificates – SPIFFE for example – is something we are working on but is not yet available AFAIK. But I’ll check.
LikeLike
That was me above 😅
LikeLike