<p>I have a service defined as ClusterIP Service Type but I am surprised to see it has endpoints and so is reachable from outside the cluster.</p>
<p>According to the definition, a clusterIP service type should be only reachable from within the Kubernetes cluster, but having an endpoint makes the service pingeable from anywhere (within a certain VNET) and this is reachable from outside the cluster.</p>
<p>Does anyone know why this would happen?</p>
<pre><code>Name:              active-mq-service
Namespace:         qa-env
Labels:            name=active-mq-service
Annotations:       Selector:  app=active-mq
Type:              ClusterIP
IP:                10.0.140.160
Port:              dashboard  8161/TCP
TargetPort:        8161/TCP
Endpoints:         10.3.1.20:8161
Port:              openwire  61616/TCP
TargetPort:        61616/TCP
Endpoints:         10.3.1.20:61616
Port:              amqp  5672/TCP
TargetPort:        5672/TCP
Endpoints:         10.3.1.20:5672
Port:              stomp  61613/TCP
TargetPort:        61613/TCP
Endpoints:         10.3.1.20:61613
Port:              mqtt  1883/TCP
TargetPort:        1883/TCP
Endpoints:         10.3.1.20:1883
Session Affinity:  None
Events:            &lt;none&gt;
</code></pre>
<p>Thanks</p>

<p>The endpoints that you're seeing are the IP addresses and ports of the Pods behind the Service.</p>
<p>When you create a cluster, you define a Pod IP address range and each Pod gets an IP address from this range when it's created (these are &quot;virtual&quot; IP addresses in the sense that there are no physical network devices with these IP addresses).</p>
<p>Depending on the CNI plugin you're using, this CNI plugin configures routing entries in the gateway on the host network to route messages to these Pods (this happens when you use an <em>unencapsulated</em> CNI plugin, see <a href="https://github.com/weibeld/cni-plugin-comparison#notes-6" rel="nofollow noreferrer"><em>encapsulated vs unencapsulated CNI plugins</em></a>). So, if you have access to this gateway from outside the cluster (e.g. from the same VNET, as you say), then you can reach these Pods from outside the cluster.</p>
<p>However, this is a special case and you would usually restrict and narrow down the network in which you create a Kubernetes cluster so that no unintended sources get access to anything inside the cluster.</p>
