Add new pod to the rd-db-egress allow

We have a networkpolicy that we deploy to all namespaces called deny-access-to-rd-db-range. This egress NetworkPolicy allows all egress traffic except for the given IP ranges for all pods without the egress-to-rd-db-range: allowed label. Another NetworkPolicy is currently only deployed for the relational-data namespace only applies for pods with the egress-to-rd-db-range: allowed, this allows all egress traffic without blocking any IP ranges.

It is important note here that if an egress NetworkPolicy allows an IP range traffic will be allowed there, even if those IP ranges would be denied in another egress NetworkPolicy. We can think of deny-access-to-rd-db-range NetworkPolicy as it isn’t denying those IP ranges, but allows all of the IP ranges not in those (currently) 3 IP-blocks

As these label protections wouldn’t make it too difficult to reach these rd-db-ranges we have some Kyverno policies. Currently we restrict the podnames and the namespace where egress-to-rd-db-range: allowedlabel can be used to those that actually need it.

If the need arises to allow another pod to reach the rd-db-egress IP ranges we need there are 2 possibilities:

• If the new pod is also in the relational-data namespace it is enough to extend the names section in the Kyverno Policy to allow the new name also, don’t forget to use wildcards like for the other names.
• Otherwise if another namespace needs to reach those IP ranges the namespaces section also needs to be extended and we need another NetworkPolicy like the allow-access-to-rd-db-range in the gap-charts repo. At some point it could makes sense to deploying these to all namespaces with the loop that deploys the deny-access-to-rd-db-range and restrict-redis-to-own-namespace Network Policies.

Currently due to the lack of flexibility with the Network Policy API, it would not be easy to add the external-content-web service in the relational-data namespace due to it being included in a different network policy that disallows it to communicate with the pod IP ranges. We would need to rework the network policy setup we have now in order to accomodate it in the rd-db-egress network policy.

For more protection we might restrict creating network policies. Currently someone could deploy an allow all egress NetworkPolicy that would essentially override the restriction we have on all namespaces.