I have not found a way to restrict egress traffic in this doc yet. Just register AKSLockingDownEgressPreview feature and create a cluster? Or need additional operation such as UDR to define a route to Firewall? Need some parameter when I create a cluster?
⚠Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.
@ToruMakabe Thanks for the question! We will check on this issue and get back to you soon.
@ToruMakabe This document has the set of required and recommended rules to be opened which is needed for the AKS nodes.
We can have Azure Firewall on the VNET and add the above rules to the firewall so that the AKS nodes will have limited egress.
For creating a cluster, i think you dont need to give additional arguments apart from registering tot het preview. @iainfoulds Correct me if i am wrong.
You need to deploy the Cluster on a VNET(already existing) when you can enable the Azure firewall or any other third party firewall service.
@ToruMakabe Also let me know if you are looking for something else
@jakaruna-MSFT Thanks. I'm catching on. Let me know two important things.
What kind of effects does the "AKSLockingDownEgressPreview" feature register command?
If I do not have to give additional arguments about this feature when I create a cluster, how can I specify on/off of this feature to cluster?
I still do not get the purpose of this document. We can deploy AKS in a VNET and enable Azure Firewall just fine without the registered feature. It's great that there is a list of ports and URLs to allow because that was missing in the past.
But the question remains: what does the registered feature do exactly?
@ToruMakabe @gbaeke I think using that registration Azure team can keep track of the customers who are using this preview feature.
@iainfoulds Please provide your comments
The feature registration tells the cluster to only pull core system images from container image repositories housed in the Microsoft Container Registry (MCR). Otherwise, clusters could try to pull container images for the core components from external repositories. There is some additional routing that also occurs for the cluster to do this. The list of ports and addresses are then what's required for you to permit when the egress traffic is restricted. You can't simply limit the egress traffic to only those address without the feature being enabled for the cluster.
@iainfoulds Thanks. Let me clarify my understanding. After the feature registration, will "all" cluster in the feature registered subscription pull core system images from MCR only? If so, the registration have a high impact on customer. Could you add a note of caution?
@ToruMakabe Yes, the doc was already updated to note that. Any clusters created after registering the feature will have the ability, but this is only for the base system images. Customers can still pull from any additional registry they like for their own deployments. The MCR/ACR limitation is in terms of things like core-dns and the other required Kubernetes cluster components. There shouldn't be anything breaking on the customer workflow here.
As doc updates are already in place, #please-close
@iainfoulds Thanks!
I agree with @gbaeke that the purpose of this document is extremely unclear. The title implies that the doc explains how to do something, but it doesn't.
If this document is explaining how to "[configure] the cluster to only pull core system images from container image repositories housed in the Microsoft Container Registry (MCR)" then perhaps the title should be amended.
The title implies that it's about how to configure Egress in network policy but that's not what it's about (I can't find a doc that explains how to do that, and that is what I was looking for).
6 months later, the doc is still not clear. it just say, you'll need CLI and Firewall...and that's all.