Service entry is an Istio primitive that's created through a custom resource definition in Kubernetes. The purpose of a service entry is to add an external service entry to Istio's abstract model, as shown in the architecture diagram, to make it look as if it was a service in your mesh. Once an external service entry has been defined through service entry, it can be subjected to the same policies, such as retry, timeout, and fault injection, since they are applied to internal services.

By adding an external service running in a Virtual Machine (VM), we can expand the mesh beyond the Kubernetes cluster. This also helps to add services from a different cluster to the mesh to configure a multi-cluster Istio mesh on Kubernetes.

Through the use of the Egress gateway and the service entry primitive, we can configure Envoy so that it performs TLS origination to secure the traffic to external endpoints. 

The security posture should always begin with a deny (blacklist) and allow (whitelist) rule, for example, deny access from all and then allow access to those who have a need for it. The whitelist is a list of subjects that have a legitimate need for access, while the blacklist is a deny rule that disallows services to either all or to a list of subjects. 

The following is an example of allowing access to an external endpoint as a whitelisted service for the microservices application:

apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
  name: ibm
spec:
  hosts:
  - www.ibm.com
  ports:
  - number: 443
    name: https
    protocol: HTTPS
  resolution: DNS
  location: MESH_EXTERNAL

Next, we'll discuss the destination rule.