We're setting up an on-premises Kubernetes environment on a powerful internal server and are trying to make some architectural decisions. First, is it a good idea to expose a database's web-based administration interface through an Ingress controller or reverse proxy such as NGINX or Traefik, even if it is only reachable from the company's internal network? What additional security controls would still be necessary? Second, should infrastructure components such as monitoring, databases, and deployment tools run in the same cluster as our applications, or should we separate them into different clusters? Finally, what storage approach is generally recommended on-premises: the default StorageClass, hostPath, Longhorn, or another solution?
4 Answers
For a database administration GUI, I would avoid exposing the database service itself through Ingress. Keep the database private and provide access to a separate admin interface through a VPN, port-forwarding, or an authenticated internal gateway. An Ingress or reverse proxy is not automatically secure just because it is internal; any reachable service still needs strong authentication, authorization, TLS, network restrictions, patching, and ideally SSO or another centralized access control layer.
Many organizations use a management or monitoring cluster alongside one or more workload clusters. For a small team, though, two clusters may add considerable operational overhead. A practical progression is to start with one well-managed production cluster, use namespaces, quotas, network policies, taints, and careful access controls, then add a separate development or testing cluster if people need a place where they can experiment without affecting production.
A single cluster with separate namespaces per application and environment is a reasonable starting point for a small on-premises setup. Split into multiple clusters when you need stronger isolation, separate upgrade schedules, compliance boundaries, dedicated production protection, or a smaller failure domain. Running infrastructure and applications together is simpler, but a cluster failure can take down everything scheduled there, so critical services should also have backups and a recovery plan.
Our main concern is exactly that failure scenario. If the only cluster goes down, the applications and the monitoring, deployment tools, and databases hosted there would all be unavailable until the cluster is recovered.
For on-premises persistent volumes, hostPath is usually unsuitable for important data because it ties the volume to one node and does not provide useful failover. A distributed system such as Longhorn can provide replicated volumes and a relatively approachable operational model, while a cloud or vendor CSI driver is usually preferable when one is available. Whichever solution you choose, test backups and restores; replication alone is not a complete disaster-recovery strategy. Sending backups or snapshots to S3-compatible storage is a useful addition.
Longhorn can be a good fit for a small team because it offers replication without requiring a very complex storage platform, but it still needs monitoring, capacity planning, and regular recovery tests.
That makes sense. So even with Traefik or NGINX in front, we would still need authentication and network controls rather than treating the proxy as the security boundary.