1931 gitlab runner not passing control plane cidr
General MR
Summary
The BB level value of networkPolicies.controlPlaneCidr passes down to app netpols via default values per app in their respective BB template subdirectories, but gitlab-runner is missing this default value
Also, the associated network policy includes a rule to allow all traffic to the gitlab namespace, but all other applications have a dedicated kube-api egress and this one should as well, as the current multi-element rule allows all traffic to the gitlab namespace or the default cidr (0.0.0.0/0 if not configured directly in the gitlab runner values).
Suggested action is to fix the gitlab runner BB level values, break the netpol into its own dedicated kube api netpol and create a new netpol for gitlab-runner > gitlab communication.
Dev Test Screenshots
At a high level this fixes a bug in the Gitlab Runner template to support passing of the CIDR Network value to Gitlab Runner Package Chart that ties in with the network policies. Also the contributor is recommending we make the multi element network policy that includes kube api access and Gitlab access to be split into their own respective network policies.
In addition. I made the kube api network policy even more explicit by specifying the port and not defaulting to 0.0.0.0/0 on all ports.
Linked Issue
Upgrade Notices
A New Top-Level Big Bang Global Value has been added ".Values.networkPolicies.kubeapiPort". This is specific to the network policy for Gitlab Runner to allow explicit Kube API access in conjunction with ".Values.networkPolicies.controlPlaneCidr".
Defaults for values above if not set:
".Values.networkPolicies.controlPlaneCidr" default value is "0.0.0.0/0"
".Values.networkPolicies.kubeapiPort" default value is ("443", "6443")