Define how traffic is routed to a Kubernetes Deployed GitLab.com
Currently, we utilize haproxy as our gateway into the GitLab.com product. Here we define multiple ACL's 1 2 that handle a lot of control. Whether it be blocking abusers, slowing down potential DDoS, or adjusting how traffic is flowing through haproxy, it's responsible for quite a bit 3 4. We need to determine how to port over this into a kubernetes environment. When building the PoC of using the container registry for the pre environment, this situation was not taken into consideration at all. It was deployed behind the provided nginx ingress with none of these security controls. This will not work for GitLab.com. There are too many dependencies with how we route traffic to specific endpoints, the division of fleets to handle specific types of requests, and automation we have to assist us with security related concerns.
We should consider the following when thinking about this:
- Are there any features we can tie into the existing Cloud Native GitLab helm charts, which utilize the nginx ingress that can help us achieve the above?
- Do we push haproxy into Kuberentes with some way of handling these large sets of ACL's or do we maintain our existing haproxy infrastructure and change the endpoint for which haproxy uses as it's backend?
- Invest time into a different solution?
- ...