How can I prevent Harvester workloads from being accidentally exposed to the public internet?

Explanation

Harvester runs workloads on top of Kubernetes. By default, a Service can be exposed as NodePort or LoadBalancer, and an Ingress controller may be reachable from outside the cluster. If any of these objects are created without restriction, a VM or container workload could become reachable from the public internet unintentionally.

Confirmed facts

• A Service with type ClusterIP is only reachable inside the cluster.
• Kubernetes NetworkPolicies allow a default‑deny posture that limits pod‑to‑pod traffic to explicitly allowed rules.
• Harvester provides an isolated network option for VMs that keeps VM NICs on a bridge/VLAN not attached to the external physical network.
• Cloud provider load balancers can be created as internal‑only (e.g., AWS internal ELB, GCP internal load balancer) to restrict exposure to a private subnet.

Steps to enforce internal‑only exposure

1. Audit existing Services

   kubectl get services -A -o wide

   Verify that the TYPE column shows only ClusterIP (or an approved internal load balancer). Change any NodePort or LoadBalancer Service to ClusterIP unless an external consumer is confirmed.
2. Restrict Service creation via admission control Deploy a validating admission webhook (e.g., OPA/Gatekeeper) that rejects any Service with type NodePort, LoadBalancer, or ExternalName unless it carries a specific label such as allow-external=true. Example ConstraintTemplate (simplified):

   apiVersion: templates.gatekeeper.sh/v1
   kind: ConstraintTemplate
   metadata:
     name: k8sservicetype
   spec:
     crd:
       spec:
         names:
           kind: K8sServiceType
     targets:
       - target: admission.k8s.gatekeeper.sh
         rego: |
           package k8sservicetype
           violation[{"msg": msg}] {
             s := input.review.object
             s.kind == "Service"
             not s.metadata.labels.allow-external
             s.spec.type != "ClusterIP"
             msg := sprintf("Service %v/%v must be ClusterIP or have allow-external label", [s.metadata.namespace, s.metadata.name])
           }
   

   Then create a Constraint that applies the template to all namespaces.
3. Apply default‑deny NetworkPolicies For each namespace (or use a namespace‑selector to apply cluster‑wide):

   apiVersion: networking.k8s.io/v1
   kind: NetworkPolicy
   metadata:
     name: deny-all
     namespace: 
   spec:
     podSelector: {}
     policyTypes:
       - Ingress
       - Egress
   

   Then add specific allow rules for required intra‑service traffic (e.g., monitoring, storage).
4. Disable or re‑configure Harvester’s external ingress The Harvester‑provided ingress service is often named harvester-nginx-ingress. Ensure it is set to type ClusterIP or delete it if not needed:

   kubectl patch svc harvester-nginx-ingress -n harvester-system -p '{"spec":{"type":"ClusterIP"}}'
      # or
      kubectl delete svc harvester-nginx-ingress -n harvester-system
   

   If external access to the Harvester UI is required, expose it through an internal‑only load balancer or a VPN.
5. Secure worker nodes Confirm that worker nodes do not have public IP addresses, or that their security groups/firewall rules block inbound traffic from 0.0.0.0/0 on all ports except those needed for cluster management (e.g., SSH, kubelet).
6. Use Harvester isolated VM network (optional) When creating a VM, select the isolated network type so the VM’s NIC is attached to a bridge that is not connected to the physical uplink.

Continuous validation

• Periodic Service check – run a cron job that executes kubectl get services -A -o jsonpath='{.items[*].spec.type}' and alerts if any value differs from ClusterIP (or the approved internal load balancer type).
• NetworkPolicy verification – use kubectl get networkpolicy -A to ensure a default‑deny policy exists in each namespace; optionally run kubectl exec pods to test that blocked traffic is dropped.
• Admission controller audit** – enable audit logs for the validating webhook and set up an alert on any denied Service creation attempts.
• Ingress exposure test** – from a host outside the cluster, attempt to reach the cluster’s external IP on common ports (80, 443, NodePort ranges). Connections should be refused or timeout.

Missing diagnostic detail

To finalize the node‑security step, please confirm whether your Harvester worker nodes currently have public IP addresses assigned or are reachable directly from the internet. If they do, the firewall/security‑group rule adjustment is required; if they are already behind a private subnet, this step can be skipped.