# Ensure cluster network type is configured as private to prevent public exposure. - Source: https://support.icompaas.com/support/solutions/articles/a_1786022989080285-ensure-cluster-network-type-is-configured-as-private-to-prevent-public-exposure - Section: [Solutions](https://support.icompaas.com/support/solutions) › [Utho Cloud](https://support.icompaas.com/support/solutions/c_1786022244474917) › [Utho Checks](https://support.icompaas.com/support/solutions/folders/utho-checks) - Last updated: 2026-08-06 - Publisher: iCompaas, Inc. (https://www.icompaas.com) ## Description This control checks that Utho Kubernetes clusters run on a private network - inside a VPC with a private subnet, with no public IPs on worker nodes and management traffic restricted by firewall - rather than being reachable directly from the public internet. The Utho create-cluster flow lets you choose the network type (public or private) and attach a VPC and subnet, and a firewall can be applied to the cluster's nodes. Because a public endpoint is a selectable option, the control verifies that the cluster was actually placed in a VPC/private subnet and that no 0.0.0.0/0 inbound rule exposes the API server or node ports. It passes when the cluster is private (VPC + private subnet, firewalled, no public node IPs) and administrative access is via VPN/bastion; it fails when the API server or nodes are directly reachable from the internet. - Clusters created with public network type or worker nodes holding public IPs. - Firewall rules allowing 0.0.0.0/0 inbound to the API server or node ports. - Administrative access paths that reach the cluster over the public internet. ## Rationale A cluster with a public network endpoint exposes the Kubernetes API server and worker nodes directly to the internet, inviting brute-force and credential-stuffing against the control plane and direct exploitation of any exposed node port. A single unpatched API-server CVE then becomes remotely reachable by anyone. Placing the cluster in a VPC with a private subnet, denying inbound from the internet at the firewall, and requiring a VPN or bastion for administration removes that direct exposure. The attack surface shrinks to the private network, so an attacker must first breach the perimeter before the control plane is even reachable. - Removes direct internet reachability of the API server and node ports. - Blocks brute-force/credential-stuffing against the control plane from the open internet. - Forces administration through a controlled VPN/bastion path that can be logged and MFA-gated. ## Impact Pros: - The control plane and nodes are not exposed to internet-wide scanning and attack. - An API-server CVE is not remotely reachable without first breaching the VPC. - Management access is funneled through an auditable VPN/bastion chokepoint. Cons: - Administrators need a VPN or bastion into the VPC to reach the cluster. - CI/CD and external tooling must be given a private path (VPN, bastion, or in-VPC runner). - Slightly more networking to set up and maintain (VPC, subnet, firewall, bastion). ## Default Value The Utho create-cluster flow lets you pick the network type (public or private) and attach a VPC/subnet and firewall; a public endpoint is selectable, so a cluster is only private if you explicitly chose a VPC/private subnet - verify this in your account. ## Pre-Requisite - A VPC and a private subnet created in the target Utho datacenter (or permission to create them). - An Utho Firewall you can attach to the cluster nodes. - A VPN or bastion host inside the VPC for administrative access, plus the source CIDRs allowed to manage the cluster. - Utho console access and an API token for scripted checks/changes. ## Remediation ### Test Plan Using the Utho Console: 1. In the Utho console open Kubernetes and select the cluster; on the manage page confirm it is attached to a VPC and a private subnet and that the network type is private. 2. Check the worker nodes have no public IP assigned. 3. Open the Firewall attached to the cluster and confirm there is no 0.0.0.0/0 inbound rule to the API server or node ports - management ports are allowed only from your VPN/bastion/office CIDR. 4. From an external network, attempt to reach the API server / node ports and confirm the connection fails; confirm access succeeds only through the private path. 5. Pass: cluster is in a VPC/private subnet, nodes have no public IP, the firewall denies 0.0.0.0/0 inbound to management ports, and the external connectivity test fails. 6. Fail: the cluster is public, nodes have public IPs, or the firewall allows internet inbound to the API server/node ports. Using the Utho API: Read the cluster's network configuration from the Utho API to confirm the VPC/subnet and network type. curl -s -H 'Authorization: Bearer $UTHO\_API\_TOKEN' https://api.utho.com/v2/kubernetes/ Pass if the cluster reports a private network type attached to a VPC/subnet with no public node IPs; Fail if it reports a public network type or public IPs on nodes. Firewall inbound rules should additionally be confirmed to have no 0.0.0.0/0 to management ports. ### Implementation Steps Using the Utho Console: 1. Create a VPC and a private subnet in the target datacenter (Networking > VPC, then create a subnet) if you do not already have them. 2. Create the cluster in the console create-cluster flow, selecting that VPC and private subnet and setting the network type to private (existing public clusters must be rebuilt private via a blue-green migration - network type cannot be flipped in place). 3. Attach an Utho Firewall to the cluster nodes that denies inbound 0.0.0.0/0 and permits management traffic (API/SSH ports) only from your VPN, bastion, or office CIDR. 4. Do not assign public IPs to worker nodes; keep node-to-node and control-plane traffic on the private subnet. 5. Reach the cluster administratively through a bastion host or VPN into the VPC, and verify from an external network that the API server and node ports are unreachable. Using the Utho API: New clusters can be deployed private via the deploy API by passing the VPC, subnet, and private network type; an existing public cluster cannot be converted in place and must be rebuilt. curl -s -X POST -H 'Authorization: Bearer $UTHO\_API\_TOKEN' -H 'Content-Type: application/json' https://api.utho.com/v2/kubernetes/deploy -d '{"dcslug":"","cluster\_label":"prod-private","cluster\_version":"","nodepools":\[{"label":"pool-1","size":"","count":"2"}\],"vpc":"","subnetRequired":true,"network\_type":"private","firewall":""}' ### Backout Plan: 1. Because network type is fixed at creation, keep the previous cluster running until the new private cluster is validated, then cut traffic over (blue-green). 2. If the private path blocks required access, temporarily widen the firewall to a specific admin CIDR (never 0.0.0.0/0) rather than reverting to a public cluster. 3. If the migration must be abandoned, shift workloads back to the retained cluster and delete the new one once traffic has drained. ## References: 1. [Utho Docs: Deploy a VPC](https://utho.com/docs/products/networking/vpc/vpcs/how-tos/deploy-vpc/) 2. [Utho Docs: Create a subnet](https://utho.com/docs/products/networking/vpc/subnets/how-tos/create-subnet/) 3. [Utho Docs: Create a Kubernetes cluster](https://utho.com/docs/products/compute/kubernetes/how-tos/create-cluster/) ## Related compliance guidance - [SOC 2 compliance: a practical implementation guide for cloud-native SaaS teams](https://support.icompaas.com/compliance/soc-2-trust-services-criteria): Configuration checks like this one are the technical half of a SOC 2 / ISO 27001 programme — the guide shows where they fit, what else an auditor expects, and how to evidence them. - [ISO/IEC 27001:2022 compliance: a practical implementation guide](https://support.icompaas.com/compliance/iso-27001-2022): ISO 27001 Annex A.8 (technological controls) is where cloud hardening evidence lands; the guide shows how to run the ISMS around it.