The current network policy for HCP kube-apiserver is too permissive which allows access to the HCP apiserver from any namespace in the cluster:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
 annotations:
   hypershift.openshift.io/cluster: clusters/kramraja-hshift-25288
 name: kas
 namespace: clusters-kramraja-hshift-25288
spec:
 ingress:
 - ports:
   - port: 6443
     protocol: TCP
 podSelector:
   matchLabels:
     app: kube-apiserver
 policyTypes:
 - Ingress

This is a security concern as if an attacker gains access to one of the apiservers, they could be able to access apiserver of other hosted clusters. Instead, this network policy can be modified to something like this:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
 annotations:
   hypershift.openshift.io/cluster: clusters/kramraja-hshift-25288
 name: kas
 namespace: clusters-kramraja-hshift-25288
spec:
  ingress:
  - from:
     - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: openshift-ingress     //Just a random namespace for example
     - ipBlock:
            cidr: 0.0.0.0/0
    ports:
    - port: 6443
      protocol: TCP
  podSelector:
    matchLabels:
      app: kube-apiserver
  policyTypes:
  - Ingress

This ^ will make sure that the apiserver is accessible from outside the cluster for the customers but block access to it from inside the cluster. Opening up access to openshift-ingress above is just an example, that should be replaced by the core components that actually need to communicate with the HCP apiserver (like hypershift operator)

This was initially found in OSD-12581

Acceptance Criteria

• Kas network policy is modified based on recommendations mentioned above to block network access to HCP kube-apiserver from the in-cluster components that do not require it.