update dependencies

Signed-off-by: hongming <talonwan@yunify.com>
2020-12-22 16:48:26 +08:00
parent 4a11a50544
commit fe6c5de00f
2857 changed files with 252134 additions and 115656 deletions
--- a/vendor/istio.io/api/networking/v1alpha3/service_entry.pb.html
+++ b/vendor/istio.io/api/networking/v1alpha3/service_entry.pb.html
@@ -4,21 +4,33 @@ description: Configuration affecting service registry.
 location: https://istio.io/docs/reference/config/networking/service-entry.html
 layout: protoc-gen-docs
 generator: protoc-gen-docs
-aliases: [/docs/reference/config/networking/v1alpha3/service-entry.html]
-number_of_entries: 4
+schema: istio.networking.v1alpha3.ServiceEntry
+aliases: [/docs/reference/config/networking/v1alpha3/service-entry]
+number_of_entries: 3
 ---
-<p><code>ServiceEntry</code> enables adding additional entries into Istio&rsquo;s internal
-service registry, so that auto-discovered services in the mesh can
-access/route to these manually specified services. A service entry
-describes the properties of a service (DNS name, VIPs, ports, protocols,
-endpoints). These services could be external to the mesh (e.g., web
-APIs) or mesh-internal services that are not part of the platform&rsquo;s
-service registry (e.g., a set of VMs talking to services in Kubernetes).</p>
+<p><code>ServiceEntry</code> enables adding additional entries into Istio&rsquo;s
+internal service registry, so that auto-discovered services in the
+mesh can access/route to these manually specified services. A
+service entry describes the properties of a service (DNS name,
+VIPs, ports, protocols, endpoints). These services could be
+external to the mesh (e.g., web APIs) or mesh-internal services
+that are not part of the platform&rsquo;s service registry (e.g., a set
+of VMs talking to services in Kubernetes). In addition, the
+endpoints of a service entry can also be dynamically selected by
+using the <code>workloadSelector</code> field. These endpoints can be VM
+workloads declared using the <code>WorkloadEntry</code> object or Kubernetes
+pods. The ability to select both pods and VMs under a single
+service allows for migration of services from VMs to Kubernetes
+without having to change the existing DNS names associated with the
+services.</p>

 <p>The following example declares a few external APIs accessed by internal
 applications over HTTPS. The sidecar inspects the SNI value in the
 ClientHello message to route to the appropriate external service.</p>

+<p>{{<tabset category-name="example">}}
+{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
+
 <pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
 kind: ServiceEntry
 metadata:
@@ -36,11 +48,38 @@ spec:
  resolution: DNS
 </code></pre>

+<p>{{</tab>}}</p>
+
+<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
+
+<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
+kind: ServiceEntry
+metadata:
+  name: external-svc-https
+spec:
+  hosts:
+  - api.dropboxapi.com
+  - www.googleapis.com
+  - api.facebook.com
+  location: MESH_EXTERNAL
+  ports:
+  - number: 443
+    name: https
+    protocol: TLS
+  resolution: DNS
+</code></pre>
+
+<p>{{</tab>}}
+{{</tabset>}}</p>
+
 <p>The following configuration adds a set of MongoDB instances running on
 unmanaged VMs to Istio&rsquo;s registry, so that these services can be treated
 as any other service in the mesh. The associated DestinationRule is used
 to initiate mTLS connections to the database instances.</p>

+<p>{{<tabset category-name="example">}}
+{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
+
 <pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
 kind: ServiceEntry
 metadata:
@@ -61,8 +100,38 @@ spec:
  - address: 3.3.3.3
 </code></pre>

+<p>{{</tab>}}</p>
+
+<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
+
+<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
+kind: ServiceEntry
+metadata:
+  name: external-svc-mongocluster
+spec:
+  hosts:
+  - mymongodb.somedomain # not used
+  addresses:
+  - 192.192.192.192/24 # VIPs
+  ports:
+  - number: 27018
+    name: mongodb
+    protocol: MONGO
+  location: MESH_INTERNAL
+  resolution: STATIC
+  endpoints:
+  - address: 2.2.2.2
+  - address: 3.3.3.3
+</code></pre>
+
+<p>{{</tab>}}
+{{</tabset>}}</p>
+
 <p>and the associated DestinationRule</p>

+<p>{{<tabset category-name="example">}}
+{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
+
 <pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
 kind: DestinationRule
 metadata:
@@ -77,10 +146,34 @@ spec:
      caCertificates: /etc/certs/rootcacerts.pem
 </code></pre>

+<p>{{</tab>}}</p>
+
+<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
+
+<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
+kind: DestinationRule
+metadata:
+  name: mtls-mongocluster
+spec:
+  host: mymongodb.somedomain
+  trafficPolicy:
+    tls:
+      mode: MUTUAL
+      clientCertificate: /etc/certs/myclientcert.pem
+      privateKey: /etc/certs/client_private_key.pem
+      caCertificates: /etc/certs/rootcacerts.pem
+</code></pre>
+
+<p>{{</tab>}}
+{{</tabset>}}</p>
+
 <p>The following example uses a combination of service entry and TLS
 routing in a virtual service to steer traffic based on the SNI value to
 an internal egress firewall.</p>

+<p>{{<tabset category-name="example">}}
+{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
+
 <pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
 kind: ServiceEntry
 metadata:
@@ -97,8 +190,34 @@ spec:
  resolution: NONE
 </code></pre>

+<p>{{</tab>}}</p>
+
+<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
+
+<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
+kind: ServiceEntry
+metadata:
+  name: external-svc-redirect
+spec:
+  hosts:
+  - wikipedia.org
+  - &quot;*.wikipedia.org&quot;
+  location: MESH_EXTERNAL
+  ports:
+  - number: 443
+    name: https
+    protocol: TLS
+  resolution: NONE
+</code></pre>
+
+<p>{{</tab>}}
+{{</tabset>}}</p>
+
 <p>And the associated VirtualService to route based on the SNI value.</p>

+<p>{{<tabset category-name="example">}}
+{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
+
 <pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
 kind: VirtualService
 metadata:
@@ -117,6 +236,31 @@ spec:
        host: internal-egress-firewall.ns1.svc.cluster.local
 </code></pre>

+<p>{{</tab>}}</p>
+
+<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
+
+<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
+kind: VirtualService
+metadata:
+  name: tls-routing
+spec:
+  hosts:
+  - wikipedia.org
+  - &quot;*.wikipedia.org&quot;
+  tls:
+  - match:
+    - sniHosts:
+      - wikipedia.org
+      - &quot;*.wikipedia.org&quot;
+    route:
+    - destination:
+        host: internal-egress-firewall.ns1.svc.cluster.local
+</code></pre>
+
+<p>{{</tab>}}
+{{</tabset>}}</p>
+
 <p>The virtual service with TLS match serves to override the default SNI
 match. In the absence of a virtual service, traffic will be forwarded to
 the wikipedia domains.</p>
@@ -129,6 +273,9 @@ to all namespaces. The following example restricts the visibility to the
 current namespace, represented by &ldquo;.&rdquo;, so that it cannot be used by other
 namespaces.</p>

+<p>{{<tabset category-name="example">}}
+{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
+
 <pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
 kind: ServiceEntry
 metadata:
@@ -147,8 +294,36 @@ spec:
  resolution: DNS
 </code></pre>

+<p>{{</tab>}}</p>
+
+<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
+
+<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
+kind: ServiceEntry
+metadata:
+  name: external-svc-httpbin
+  namespace : egress
+spec:
+  hosts:
+  - httpbin.com
+  exportTo:
+  - &quot;.&quot;
+  location: MESH_EXTERNAL
+  ports:
+  - number: 80
+    name: http
+    protocol: HTTP
+  resolution: DNS
+</code></pre>
+
+<p>{{</tab>}}
+{{</tabset>}}</p>
+
 <p>Define a gateway to handle all egress traffic.</p>

+<p>{{<tabset category-name="example">}}
+{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
+
 <pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
 kind: Gateway
 metadata:
@@ -166,6 +341,30 @@ spec:
   - &quot;*&quot;
 </code></pre>

+<p>{{</tab>}}</p>
+
+<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
+
+<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
+kind: Gateway
+metadata:
+ name: istio-egressgateway
+ namespace: istio-system
+spec:
+ selector:
+   istio: egressgateway
+ servers:
+ - port:
+     number: 80
+     name: http
+     protocol: HTTP
+   hosts:
+   - &quot;*&quot;
+</code></pre>
+
+<p>{{</tab>}}
+{{</tabset>}}</p>
+
 <p>And the associated <code>VirtualService</code> to route from the sidecar to the
 gateway service (<code>istio-egressgateway.istio-system.svc.cluster.local</code>), as
 well as route from the gateway to the external service. Note that the
@@ -173,6 +372,9 @@ virtual service is exported to all namespaces enabling them to route traffic
 through the gateway to the external service. Forcing traffic to go through
 a managed middle proxy like this is a common practice.</p>

+<p>{{<tabset category-name="example">}}
+{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
+
 <pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
 kind: VirtualService
 metadata:
@@ -203,11 +405,51 @@ spec:
        host: httpbin.com
 </code></pre>

+<p>{{</tab>}}</p>
+
+<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
+
+<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
+kind: VirtualService
+metadata:
+  name: gateway-routing
+  namespace: egress
+spec:
+  hosts:
+  - httpbin.com
+  exportTo:
+  - &quot;*&quot;
+  gateways:
+  - mesh
+  - istio-egressgateway
+  http:
+  - match:
+    - port: 80
+      gateways:
+      - mesh
+    route:
+    - destination:
+        host: istio-egressgateway.istio-system.svc.cluster.local
+  - match:
+    - port: 80
+      gateways:
+      - istio-egressgateway
+    route:
+    - destination:
+        host: httpbin.com
+</code></pre>
+
+<p>{{</tab>}}
+{{</tabset>}}</p>
+
 <p>The following example demonstrates the use of wildcards in the hosts for
 external services. If the connection has to be routed to the IP address
 requested by the application (i.e. application resolves DNS and attempts
 to connect to a specific IP), the discovery mode must be set to <code>NONE</code>.</p>

+<p>{{<tabset category-name="example">}}
+{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
+
 <pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
 kind: ServiceEntry
 metadata:
@@ -223,10 +465,35 @@ spec:
  resolution: NONE
 </code></pre>

+<p>{{</tab>}}</p>
+
+<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
+
+<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
+kind: ServiceEntry
+metadata:
+  name: external-svc-wildcard-example
+spec:
+  hosts:
+  - &quot;*.bar.com&quot;
+  location: MESH_EXTERNAL
+  ports:
+  - number: 80
+    name: http
+    protocol: HTTP
+  resolution: NONE
+</code></pre>
+
+<p>{{</tab>}}
+{{</tabset>}}</p>
+
 <p>The following example demonstrates a service that is available via a
 Unix Domain Socket on the host of the client. The resolution must be
 set to STATIC to use Unix address endpoints.</p>

+<p>{{<tabset category-name="example">}}
+{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
+
 <pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
 kind: ServiceEntry
 metadata:
@@ -244,6 +511,30 @@ spec:
  - address: unix:///var/run/example/socket
 </code></pre>

+<p>{{</tab>}}</p>
+
+<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
+
+<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
+kind: ServiceEntry
+metadata:
+  name: unix-domain-socket-example
+spec:
+  hosts:
+  - &quot;example.unix.local&quot;
+  location: MESH_EXTERNAL
+  ports:
+  - number: 80
+    name: http
+    protocol: HTTP
+  resolution: STATIC
+  endpoints:
+  - address: unix:///var/run/example/socket
+</code></pre>
+
+<p>{{</tab>}}
+{{</tabset>}}</p>
+
 <p>For HTTP-based services, it is possible to create a <code>VirtualService</code>
 backed by multiple DNS addressable endpoints. In such a scenario, the
 application can use the <code>HTTP_PROXY</code> environment variable to transparently
@@ -252,8 +543,40 @@ example, the following configuration creates a non-existent external
 service called foo.bar.com backed by three domains: us.foo.bar.com:8080,
 uk.foo.bar.com:9080, and in.foo.bar.com:7080</p>

+<p>{{<tabset category-name="example">}}
+{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
+
 <pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
 kind: ServiceEntry
+metadata:
+  name: external-svc-dns
+spec:
+  hosts:
+  - foo.bar.com
+  location: MESH_EXTERNAL
+  ports:
+  - number: 80
+    name: http
+    protocol: HTTP
+  resolution: DNS
+  endpoints:
+  - address: us.foo.bar.com
+    ports:
+      http: 8080
+  - address: uk.foo.bar.com
+    ports:
+      http: 9080
+  - address: in.foo.bar.com
+    ports:
+      http: 7080
+</code></pre>
+
+<p>{{</tab>}}</p>
+
+<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
+
+<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
+kind: ServiceEntry
 metadata:
  name: external-svc-dns
 spec:
@@ -277,6 +600,9 @@ spec:
      https: 7080
 </code></pre>

+<p>{{</tab>}}
+{{</tabset>}}</p>
+
 <p>With <code>HTTP_PROXY=http://localhost/</code>, calls from the application to
 <code>http://foo.bar.com</code> will be load balanced across the three domains
 specified above. In other words, a call to <code>http://foo.bar.com/baz</code> would
@@ -286,6 +612,9 @@ be translated to <code>http://uk.foo.bar.com/baz</code>.</p>
 containing a subject alternate name
 whose format conforms to the <a href="https://github.com/spiffe/spiffe/blob/master/standards/SPIFFE-ID.md">SPIFFE standard</a>:</p>

+<p>{{<tabset category-name="example">}}
+{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
+
 <pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
 kind: ServiceEntry
 metadata:
@@ -307,6 +636,153 @@ spec:
  - &quot;spiffe://cluster.local/ns/httpbin-ns/sa/httpbin-service-account&quot;
 </code></pre>

+<p>{{</tab>}}</p>
+
+<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
+
+<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
+kind: ServiceEntry
+metadata:
+  name: httpbin
+  namespace : httpbin-ns
+spec:
+  hosts:
+  - httpbin.com
+  location: MESH_INTERNAL
+  ports:
+  - number: 80
+    name: http
+    protocol: HTTP
+  resolution: STATIC
+  endpoints:
+  - address: 2.2.2.2
+  - address: 3.3.3.3
+  subjectAltNames:
+  - &quot;spiffe://cluster.local/ns/httpbin-ns/sa/httpbin-service-account&quot;
+</code></pre>
+
+<p>{{</tab>}}
+{{</tabset>}}</p>
+
+<p>The following example demonstrates the use of <code>ServiceEntry</code> with a
+<code>workloadSelector</code> to handle the migration of a service
+<code>details.bookinfo.com</code> from VMs to Kubernetes. The service has two
+VM-based instances with sidecars as well as a set of Kubernetes
+pods managed by a standard deployment object. Consumers of this
+service in the mesh will be automatically load balanced across the
+VMs and Kubernetes.  VM for the <code>details.bookinfo.com</code>
+service. This VM has sidecar installed and bootstrapped using the
+<code>details-legacy</code> service account. The sidecar receives HTTP traffic
+on port 80 (wrapped in istio mutual TLS) and forwards it to the
+application on the localhost on the same port.</p>
+
+<p>{{<tabset category-name="example">}}
+{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
+
+<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
+kind: WorkloadEntry
+metadata:
+  name: details-vm-1
+spec:
+  serviceAccount: details
+  address: 2.2.2.2
+  labels:
+    app: details
+    instance-id: vm1
+---
+apiVersion: networking.istio.io/v1alpha3
+kind: WorkloadEntry
+metadata:
+  name: details-vm-2
+spec:
+  serviceAccount: details
+  address: 3.3.3.3
+  labels:
+    app: details
+    instance-id: vm2
+</code></pre>
+
+<p>{{</tab>}}</p>
+
+<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
+
+<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
+kind: WorkloadEntry
+metadata:
+  name: details-vm-1
+spec:
+  serviceAccount: details
+  address: 2.2.2.2
+  labels:
+    app: details
+    instance-id: vm1
+---
+apiVersion: networking.istio.io/v1beta1
+kind: WorkloadEntry
+metadata:
+  name: details-vm-2
+spec:
+  serviceAccount: details
+  address: 3.3.3.3
+  labels:
+    app: details
+    instance-id: vm2
+</code></pre>
+
+<p>{{</tab>}}
+{{</tabset>}}</p>
+
+<p>Assuming there is also a Kubernetes deployment with pod labels
+<code>app: details</code> using the same service account <code>details</code>, the
+following service entry declares a service spanning both VMs and
+Kubernetes:</p>
+
+<p>{{<tabset category-name="example">}}
+{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
+
+<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
+kind: ServiceEntry
+metadata:
+  name: details-svc
+spec:
+  hosts:
+  - details.bookinfo.com
+  location: MESH_INTERNAL
+  ports:
+  - number: 80
+    name: http
+    protocol: HTTP
+  resolution: STATIC
+  workloadSelector:
+    labels:
+      app: details
+</code></pre>
+
+<p>{{</tab>}}</p>
+
+<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
+
+<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
+kind: ServiceEntry
+metadata:
+  name: details-svc
+spec:
+  hosts:
+  - details.bookinfo.com
+  location: MESH_INTERNAL
+  ports:
+  - number: 80
+    name: http
+    protocol: HTTP
+  resolution: STATIC
+  workloadSelector:
+    labels:
+      app: details
+</code></pre>
+
+<p>{{</tab>}}
+{{</tabset>}}</p>
+
 <h2 id="ServiceEntry">ServiceEntry</h2>
 <section>
 <p>ServiceEntry enables adding additional entries into Istio&rsquo;s internal
@@ -336,9 +812,23 @@ name with wildcard prefix.</p>
 will be matched against the hosts field.</li>
 </ol>

-<p>Note that when resolution is set to type DNS
-and no endpoints are specified, the host field will be used as the DNS name
-of the endpoint to route traffic to.</p>
+<p><strong>NOTE 1:</strong> When resolution is set to type DNS and no endpoints
+are specified, the host field will be used as the DNS name of the
+endpoint to route traffic to.</p>
+
+<p><strong>NOTE 2:</strong> If the hostname matches with the name of a service
+from another service registry such as Kubernetes that also
+supplies its own set of endpoints, the ServiceEntry will be
+treated as a decorator of the existing Kubernetes
+service. Properties in the service entry will be added to the
+Kubernetes service if applicable. Currently, the only the
+following additional properties will be considered by <code>istiod</code>:</p>
+
+<ol>
+<li>subjectAltNames: In addition to verifying the SANs of the
+service accounts associated with the pods of the service, the
+SANs specified here will also be verified.</li>
+</ol>

 </td>
 <td>
@@ -401,7 +891,7 @@ No
 <p>Service discovery mode for the hosts. Care must be taken
 when setting the resolution mode to NONE for a TCP port without
 accompanying IP addresses. In such cases, traffic to any IP on
-said port will be allowed (i.e. 0.0.0.0:<port>).</p>
+said port will be allowed (i.e. <code>0.0.0.0:&lt;port&gt;</code>).</p>

 </td>
 <td>
@@ -410,9 +900,26 @@ Yes
 </tr>
 <tr id="ServiceEntry-endpoints">
 <td><code>endpoints</code></td>
-<td><code><a href="#ServiceEntry-Endpoint">Endpoint[]</a></code></td>
+<td><code><a href="https://istio.io/docs/reference/config/networking/workload-entry.html#WorkloadEntry">WorkloadEntry[]</a></code></td>
 <td>
-<p>One or more endpoints associated with the service.</p>
+<p>One or more endpoints associated with the service. Only one of
+<code>endpoints</code> or <code>workloadSelector</code> can be specified.</p>
+
+</td>
+<td>
+No
+</td>
+</tr>
+<tr id="ServiceEntry-workload_selector">
+<td><code>workloadSelector</code></td>
+<td><code><a href="https://istio.io/docs/reference/config/networking/sidecar.html#WorkloadSelector">WorkloadSelector</a></code></td>
+<td>
+<p>Applicable only for MESH_INTERNAL services. Only one of
+<code>endpoints</code> or <code>workloadSelector</code> can be specified. Selects one
+or more Kubernetes pods or VM workloads (specified using
+<code>WorkloadEntry</code>) based on their labels. The <code>WorkloadEntry</code> object
+representing the VMs should be defined in the same namespace as
+the ServiceEntry.</p>

 </td>
 <td>
@@ -452,124 +959,13 @@ No
 <td><code>subjectAltNames</code></td>
 <td><code>string[]</code></td>
 <td>
-<p>The list of subject alternate names allowed for workload instances that
-implement this service. This information is used to enforce
-<a href="https://istio.io/docs/concepts/security/#secure-naming">secure-naming</a>.
-If specified, the proxy will verify that the server
-certificate&rsquo;s subject alternate name matches one of the specified values.</p>
+<p>If specified, the proxy will verify that the server certificate&rsquo;s
+subject alternate name matches one of the specified values.</p>

-</td>
-<td>
-No
-</td>
-</tr>
-</tbody>
-</table>
-</section>
-<h2 id="ServiceEntry-Endpoint">ServiceEntry.Endpoint</h2>
-<section>
-<p>Endpoint defines a network address (IP or hostname) associated with
-the mesh service.</p>
-
-<table class="message-fields">
-<thead>
-<tr>
-<th>Field</th>
-<th>Type</th>
-<th>Description</th>
-<th>Required</th>
-</tr>
-</thead>
-<tbody>
-<tr id="ServiceEntry-Endpoint-address">
-<td><code>address</code></td>
-<td><code>string</code></td>
-<td>
-<p>Address associated with the network endpoint without the
-port.  Domain names can be used if and only if the resolution is set
-to DNS, and must be fully-qualified without wildcards. Use the form
-unix:///absolute/path/to/socket for Unix domain socket endpoints.</p>
-
-</td>
-<td>
-Yes
-</td>
-</tr>
-<tr id="ServiceEntry-Endpoint-ports">
-<td><code>ports</code></td>
-<td><code>map&lt;string,&nbsp;uint32&gt;</code></td>
-<td>
-<p>Set of ports associated with the endpoint. The ports must be
-associated with a port name that was declared as part of the
-service. Do not use for <code>unix://</code> addresses.</p>
-
-</td>
-<td>
-No
-</td>
-</tr>
-<tr id="ServiceEntry-Endpoint-labels">
-<td><code>labels</code></td>
-<td><code>map&lt;string,&nbsp;string&gt;</code></td>
-<td>
-<p>One or more labels associated with the endpoint.</p>
-
-</td>
-<td>
-No
-</td>
-</tr>
-<tr id="ServiceEntry-Endpoint-network">
-<td><code>network</code></td>
-<td><code>string</code></td>
-<td>
-<p>Network enables Istio to group endpoints resident in the same L3
-domain/network. All endpoints in the same network are assumed to be
-directly reachable from one another. When endpoints in different
-networks cannot reach each other directly, an Istio Gateway can be
-used to establish connectivity (usually using the
-AUTO_PASSTHROUGH mode in a Gateway Server). This is
-an advanced configuration used typically for spanning an Istio mesh
-over multiple clusters.</p>
-
-</td>
-<td>
-No
-</td>
-</tr>
-<tr id="ServiceEntry-Endpoint-locality">
-<td><code>locality</code></td>
-<td><code>string</code></td>
-<td>
-<p>The locality associated with the endpoint. A locality corresponds
-to a failure domain (e.g., country/region/zone). Arbitrary failure
-domain hierarchies can be represented by separating each
-encapsulating failure domain by /. For example, the locality of an
-an endpoint in US, in US-East-1 region, within availability zone
-az-1, in data center rack r11 can be represented as
-us/us-east-1/az-1/r11. Istio will configure the sidecar to route to
-endpoints within the same locality as the sidecar. If none of the
-endpoints in the locality are available, endpoints parent locality
-(but within the same network ID) will be chosen. For example, if
-there are two endpoints in same network (networkID &ldquo;n1&rdquo;), say e1
-with locality us/us-east-1/az-1/r11 and e2 with locality
-us/us-east-1/az-2/r12, a sidecar from us/us-east-1/az-1/r11 locality
-will prefer e1 from the same locality over e2 from a different
-locality. Endpoint e2 could be the IP associated with a gateway
-(that bridges networks n1 and n2), or the IP associated with a
-standard service endpoint.</p>
-
-</td>
-<td>
-No
-</td>
-</tr>
-<tr id="ServiceEntry-Endpoint-weight">
-<td><code>weight</code></td>
-<td><code>uint32</code></td>
-<td>
-<p>The load balancing weight associated with the endpoint. Endpoints
-with higher weights will receive proportionally higher traffic.</p>
+<p>NOTE: When using the workloadEntry with workloadSelectors, the
+service account specified in the workloadEntry will also be used
+to derive the additional subject alternate names that should be
+verified.</p>

 </td>
 <td>