Introduction

Un-exposing a service means removing public reachability while preserving whatever internal access the application still needs. The common mistake is changing only one layer, such as a Kubernetes Service type or a firewall rule, and assuming the service is now private even though other entry points still exist.

Inventory Every Exposure Path First

Before changing anything, list how traffic currently reaches the service. A service can be public through more than one mechanism at the same time.

Common exposure paths include:

• a Kubernetes LoadBalancer service
• a NodePort service
• an Ingress or API gateway route
• cloud load balancer target groups
• public DNS entries
• firewall or security-group rules

If you remove only one of those layers, the service may still be reachable from outside.

Make the Kubernetes Service Internal Again

If the service was exposed by its Kubernetes Service type, switch it back to ClusterIP:

kubectl -n app patch service my-api -p '{"spec":{"type":"ClusterIP"}}'
kubectl -n app get svc my-api -o wide

If public access comes through an Ingress, remove or patch that route:

kubectl -n app delete ingress my-api-ingress

If the Ingress object is shared, patch only the route you want to remove instead of deleting the whole resource.

Clean Up Cloud and DNS Layers Too

Kubernetes changes may not be enough if external resources were provisioned outside the cluster manifests. Check:

• load balancers
• firewall rules
• API gateways
• public DNS records

Typical follow-up work includes:

• removing the backend from the public load balancer
• closing the inbound firewall port
• deleting or changing the public DNS record
• updating infrastructure-as-code so the public path is not recreated later

If Terraform or another IaC tool owns the resource, make the change there as well or the next apply may expose the service again.

Verify External Failure and Internal Success

After the change, test from outside and from the internal path that should still work.

External check:

curl -I https://public.example.com/api

Internal cluster check:

kubectl -n app run tmp-curl --rm -it --image=curlimages/curl -- \
  curl -sS http://my-api.app.svc.cluster.local/health

Both tests matter. It is easy to remove the public route and accidentally break internal traffic at the same time.

Plan the Rollback Before the Change

Because un-exposing a service may affect unknown consumers, keep rollback steps ready:

• restore the previous Service type
• reapply the old Ingress route
• reopen the firewall rule
• restore the DNS record

A rollback plan is not only a list of commands. It also means knowing what signal tells you the un-exposure failed and needs to be reversed quickly.

Internal-Only Is Not a Full Security Model

Making a service internal reduces attack surface, but it is not the same as securing the service. Internal services still need authentication, authorization, and network policy. A compromised workload or misconfigured route can still abuse an internal-only service if that service trusts location more than identity.

Treat “not public” as one layer of defense, not the only one.

Common Pitfalls

The biggest mistake is changing the Kubernetes Service type while leaving an Ingress or gateway route active.

Another issue is making live cloud changes without updating infrastructure-as-code, which invites accidental re-exposure later.

People also sometimes test only the public path and forget to verify that legitimate internal traffic still works.

Summary

• Un-exposing a service means removing every external access path, not just one object.
• In Kubernetes, review Service type, Ingress, and edge-routing configuration together.
• Clean up cloud load balancers, firewall rules, and DNS as part of the same change.
• Verify both expected external failure and expected internal success.
• Remember that internal-only access does not replace authentication or policy.