[EKS] [request]: Allow kube-api access with un-chained (single) Cilium CNI

### Community Note

* Please vote on this issue by adding a 👍 [reaction](https://blog.github.com/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/) to the original issue to help the community and maintainers prioritize this request
* Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
* If you are interested in working on this issue or have submitted a pull request, please leave a comment

**Tell us about your request**
Provide a secure way to access `kube-api` while un-chained (single) Cillium CNI is used.

**Which service(s) is this request for?**
EKS

**Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?**

Quoting [Cilium documentation](https://docs.cilium.io/en/stable/installation/k8s-install-helm/):

```
Cilium can alternatively run in EKS using an overlay mode that gives pods non-VPC-routable IPs. This allows running more pods per Kubernetes worker node than the ENI limit, but means that pod connectivity to resources outside the cluster (e.g., VMs in the VPC or AWS managed services) is masqueraded (i.e., SNAT) by Cilium to use the VPC IP address of the Kubernetes worker node.
```

While running any applications that requires Admission webhooks, `kube-api` is only available on `hostNetwork`, which is a difficult solution to overcome. The details are explained [here](https://github.com/cilium/cilium/issues/21959)

**What outcome are you trying to achieve, ultimately, and why is it hard/impossible to do right now? What is the impact of not having this problem solved?** The more details you can provide, the better we'll be able to understand and solve the problem.

Currently we're facing the issue when `istio-proxy` is not able to connect to `istiod` admission webhook. The situation prevents microservice to start and be functional. The complete steps sequence is attached here for reference. [cilium_eks_istio_sidecar_injection_issue.md](https://github.com/aws/containers-roadmap/files/13551825/cilium_eks_istio_sidecar_injection_issue.md)

**Are you currently working around this issue?**
How are you currently solving this problem?

Per [the issue](https://github.com/cilium/cilium/issues/21959) that is also quoted above. Neither solution (hostNetwork:true, chaining VPC CNI and exposing webhook via LB) are not ideal and require significant product adjustments, security exceptions or sacrifice of custom IPAM functionality.

**Additional context**
GCP and Azure overcome such problem by introducing [Konnectivity](https://kubernetes.io/docs/tasks/extend-kubernetes/setup-konnectivity/). The similar approach from AWS (with or without Konnectivity) would help the community to run Cilium CNI on AWS EKS without any security or technical trade-offs.

we are also reviewing the possibility to extend IP Address range per [this blog](https://aws.amazon.com/blogs/containers/automating-custom-networking-to-solve-ipv4-exhaustion-in-amazon-eks/) suggested by @shapirov103 And also analyzing any other use-cases that are not resolvable today with the CNI-chained approach.

**Attachments**
If you think you might have additional information that you'd like to include via an attachment, please do - we'll take a look. (Remember to remove any personally-identifiable information.)

Start with the linked Cilium installation documentation, Cilium issue #21959, and the attached cilium_eks_istio_sidecar_injection_issue.md to understand the un-chained EKS networking failure. Done means a secure kube-api path works for pods using a single Cilium CNI, including the istio-proxy-to-istiod admission-webhook scenario, without requiring hostNetwork or the cited CNI chaining workaround.

Written by the indexing model from the issue text.