Please note: A common misconception is that using a {name}.pathfinder.bcgov name will secure your application for 'internal to BCGov' traffic. This is NOT the case. Both of the external VIPs are directing traffic to the SAME cluster ingress. To secure named routes you must add route whitelists.
OCP3 was behind the DMZ firewall and so you could connect to either the outside VIP or the inside VIP. OCP4 only has the outside VIP. And only has the one subnet in the SDN Zone that is not behind any firewalls.
Security should be achieved via ACLshaproxy.router.openshift.io/ip_whitelist in routes, and Aporeto policy.
Additionally, OCP4 won't have a built in wildcard set up for *.apps.silver.devops.bcgov as we are trying to get people to move to vanity URLs. No wildcard TLS cert will be added for bcgov.
With the move to an enterprise service, the platform wildcard has been deemed unsuitable for production application deployments. This means if you don't have a vanity URL for your application yet, you will want to get started on provisioning one.
Users are welcome to create a CNAME from a bcgov subdomain of their choosing to the ingress route, but it is just security through obscurity.
Per https://pathfinder-faq-ocio-pathfinder-prod.pathfinder.gov.bc.ca/OCP/Networking.html
OCP3 was behind the DMZ firewall and so you could connect to either the outside VIP or the inside VIP. OCP4 only has the outside VIP. And only has the one subnet in the SDN Zone that is not behind any firewalls.
Security should be achieved via ACLs
haproxy.router.openshift.io/ip_whitelist
in routes, and Aporeto policy.Additionally, OCP4 won't have a built in wildcard set up for
*.apps.silver.devops.bcgov
as we are trying to get people to move to vanity URLs. No wildcard TLS cert will be added forbcgov
.Users are welcome to create a CNAME from a
bcgov
subdomain of their choosing to the ingress route, but it is just security through obscurity.Ref: https://github.com/BCDevOps/OpenShift4-RollOut/issues/460