We are currently preparing a migration of our Kubernetes environment from RKE to RKE2 and are switching from Canal to Cilium as the CNI. In this process, we are evaluating whether to enable Cilium’s kube-proxy replacement mode (eBPF-based service handling).
We’ve read in your documentation that this mode is currently not supported due to the Microgateway’s reliance on iptables. Since we are using Airlock Microgateway in sidecar mode to protect our applications, we would like to ask:
Are there plans to support Cilium’s kube-proxy replacement mode in a future version of Airlock Microgateway?
If so, could you share an approximate timeline or version target?
Are there any known workarounds or experimental setups that could be considered in the meantime?
It is correct, that Microgateway in data plane mode “sidecar” currently does not support Cilium with kube-proxy replacement (see Microgateway documentation - Cilium Service Mesh).
Besides many features, Cilium is a sidecar less service mesh, which many customers love. Our existing customer base and prospects who are using Cilium generally want to get rid of sidecars - for various reasons.
Because supporting Microgateway in data plane mode sidecar would be an expensive feature, the trend is away from sidecars and no customer ever asked for it (maybe except you ;-)), it is currently not planned to support Cilium’s kube-proxy replacement.
We suggest you to use Airlock Microgateway in data plane mode “sidecarless” (Gateway API) with Cilium. This way you can run Cilium with kube-proxy replacement and can run Microgateway as Ingress.
In case you are unaware of it. Kubernetes Ingress is frozen (see link). In other words, migrating away from Ingress to Gateway API is something you should do anyway. Since you are using Microgateway, you can migrate to Gateway API (sidecarless data plane mode) und re-use 99% of your CRs (ContentSecurityPolicy instead of ContentSecurity and AccessControlPolicy instead of AccessControl).
Did you already consider to migrate to Gateway API? Are there any reasons why you don’t want to migrate (except the effort). Do you need assistance for this project?
Hi Stefan and thanks.
It’s the effort that keeps us from changeing for the moment. Currently we use three different Ingress controllers, have nginx settings on them etc. We will have to change quite a lot of stuff before we even get to the Airlock microgateway changes. I think this will we something we start working on end of 2025 or beginning 2026…
Thank you for getting back to me.
I assume the architecture you aim for will only have one Ingress controller, right? Do you see right now any features in the other Ingress controllers which might be missing in Airlock Microgateway?
We have three ingress controllers for a reason. One for internal applications, one for regular public applications and one for public applications that might get blocked like phishing pages for our simulations.
I’m not sure how we would handle this with Gateway API…
In nginx-ingress we use things like:
Set additional headers (for bots, etc)
We limit allowed http methods
In some cases we allow only certain url patterns (regex)
Deploying more than one Ingress, for internal applications, regular and public applications would be possible with Airlock Microgateway. Gateway API is very flexible in this area which means that you can expose a certain application on more than one Ingress without duplicating the configuration files.
The Guides from Gateway API gives some insights how it can be used => Getting started - Kubernetes Gateway API
I hope this also helps to get a better picture of how it works and what is possible.
I’m not sure how we would handle this with Gateway API…
We can have a brief call to discuss this.
Set additional headers (for bots, etc)
You can do that with “Gateway API” functionality or with our CRD HeaderRewrites.
We limit allowed http methods
Should be possible with Airlock Microgateway
In some cases we allow only certain url patterns (regex)
Should be possible with Airlock Microgateway
We inject a .well-known/security.txt file
Airlock Microgateway 4.7 will provide the possibility to configure Envoy native filters. I assume, that this way it’s possible to publish a security.txt file. I can also think of other possible solutions.
We drop duplicate headers
This must be analyzed in more details whether Airlock Microgateway is not already doing this.
This should be also possible with Airlock Microgateway 4.7 by configuring Envoy native filters.
Nevertheless, rate limiting is something we have on our roadmap too.