# FIPS VPN Discussion ## Option 1: Make OpenVPN FIPS compliant It is a little unknown what would be required for this to happen. There is an upstream ticket tracking this https://community.openvpn.net/openvpn/ticket/725 However, the ticket is quite old and doesn't seem to be go anywhere fast. There is a patch attached that SUSE allegedly uses in their OpenVPN package to make it FIPS compliant. I think it has been confirmed that we do not have OpenVPN in RHEL content in any form, FIPS or otherwise. Thus we would likely need to get OpenVPN packaged in RHEL with the FIPS patch and certify it before we could more forward. This put the RHEL org in a blocking position for FIPS support in Hypershift. ## Option 2: Use another VPN technology ### Konnectivity Konnectivity is the kube-native way for kube-apiservers to talk to off-network nodes. The setup is composed of a konnectivity server that runs in the same network as the KAS (can be a sidecar), a konnectivity agent that runs on each node, and an `EgressSelectorConfiguration` resource that tells the kube-apiserver to use kconnectivity. https://kubernetes.io/docs/tasks/extend-kubernetes/setup-konnectivity/ #### Cons The application needs to be kconnectivty aware as it is a application level (ISO Level 7) proxy. We have components on the management cluster, in addition to the KAS, that need to access the guest cluster network but are not kconnectivty aware. - openshift-apiserver - call webhooks for resoruces it manages - OLM - resolve service names and access services in the guest cluster We might be able to work around this with a proxy side car. ### ipsec ? ### Wiregaurd (and all VPN solutions that don't use OpenSSL) Wiregaurd is a new VPN technology that has a very simple configuration and function. https://www.wireguard.com/ #### Cons FIPS crypto certification is really rooted in OpenSSL. If a solution rolls their own crypto because OpenSSL is overkill or is slow, it is at a disadantage from a FIPS perspective.