Update reference docs. (#3334)

content/docs/reference/commands/galley/index.html

@@ -166,6 +166,10 @@ number_of_entries: 4
 <td>Name of authentication plugin to use for connection to sink server.  (default ``)</td>
 </tr>
 <tr>
+<td><code>--sinkMeta &lt;stringSlice&gt;</code></td>
+<td>Comma-separated list of key=values to attach as metadata to outgoing sink connections. Ex: &#39;key=value,key2=value2&#39;  (default `[]`)</td>
+</tr>
+<tr>
 <td><code>--tlsCertFile &lt;string&gt;</code></td>
 <td>File containing the x509 Certificate for HTTPS.  (default `/etc/certs/cert-chain.pem`)</td>
 </tr>
@@ -358,6 +362,10 @@ number_of_entries: 4
 <td>Name of authentication plugin to use for connection to sink server.  (default ``)</td>
 </tr>
 <tr>
+<td><code>--sinkMeta &lt;stringSlice&gt;</code></td>
+<td>Comma-separated list of key=values to attach as metadata to outgoing sink connections. Ex: &#39;key=value,key2=value2&#39;  (default `[]`)</td>
+</tr>
+<tr>
 <td><code>--tlsCertFile &lt;string&gt;</code></td>
 <td>File containing the x509 Certificate for HTTPS.  (default `/etc/certs/cert-chain.pem`)</td>
 </tr>
@@ -591,6 +599,11 @@ number_of_entries: 4
 <td>Name of authentication plugin to use for connection to sink server.  (default ``)</td>
 </tr>
 <tr>
+<td><code>--sinkMeta &lt;stringSlice&gt;</code></td>
+<td></td>
+<td>Comma-separated list of key=values to attach as metadata to outgoing sink connections. Ex: &#39;key=value,key2=value2&#39;  (default `[]`)</td>
+</tr>
+<tr>
 <td><code>--tlsCertFile &lt;string&gt;</code></td>
 <td></td>
 <td>File containing the x509 Certificate for HTTPS.  (default `/etc/certs/cert-chain.pem`)</td>

content/docs/reference/commands/istioctl/index.html

@@ -176,10 +176,10 @@ istioctl authn tls-check
 </code></pre>
 <h2 id="istioctl-authn-tls-check">istioctl authn tls-check</h2>
 <p>
-Requests Pilot to check for what authentication policy and destination rule it uses for each service in
-service registry, and check if TLS settings are compatible between them.
+Check what authentication policies and destination rules pilot uses to config a proxy instance,
+and check if TLS settings are compatible between them.
 </p>
-<pre class="language-bash"><code>istioctl authn tls-check [&lt;service&gt;] [flags]
+<pre class="language-bash"><code>istioctl authn tls-check &lt;pod-name[.namespace]&gt; [&lt;service&gt;] [flags]
 </code></pre>
 <table class="command-flags">
 <thead>
@@ -262,11 +262,12 @@ service registry, and check if TLS settings are compatible between them.
 </table>
 <h3 id="istioctl-authn-tls-check Examples">Examples</h3>
 <pre class="language-bash"><code>
-# Check settings for all known services in the service registry:
-istioctl authn tls-check
+# Check settings for pod &#34;foo-656bd7df7c-5zp4s&#34; in namespace default:
+istioctl authn tls-check 656bd7df7c-5zp4s.default
 
-# Check settings for a specific service
-istioctl authn tls-check foo.bar.svc.cluster.local
+# Check settings for pod &#34;foo-656bd7df7c-5zp4s&#34; in namespace default, filtered on destintation
+service &#34;bar&#34; :
+istioctl authn tls-check 656bd7df7c-5zp4s.default bar
 
 </code></pre>
 <h2 id="istioctl-deregister">istioctl deregister</h2>

content/docs/reference/config/istio.authentication.v1alpha1/index.html

@@ -11,7 +11,7 @@ number_of_entries: 11
 <h2 id="Jwt">Jwt</h2>
 <section>
 <p>JSON Web Token (JWT) token format for authentication as defined by
-https://tools.ietf.org/html/rfc7519. See <a href="https://tools.ietf.org/html/rfc6749">OAuth
+<a href="https://tools.ietf.org/html/rfc7519">RFC 7519</a>. See <a href="https://tools.ietf.org/html/rfc6749">OAuth
 2.0</a> and <a href="http://openid.net/connect">OIDC
 1.0</a> for how this is used in the whole
 authentication flow.</p>

content/docs/reference/config/istio.mesh.v1alpha1/index.html

@@ -93,7 +93,7 @@ distribution of traffic to endpoints based on the localities of where the
 traffic originates and where it will terminate. These localities are
 specified using arbitrary labels that designate a hierarchy of localities in
 {region}/{zone}/{sub-zone} form. For additional detail refer to
-https://www.envoyproxy.io/docs/envoy/latest/intro/arch<em>overview/load</em>balancing/locality_weight
+<a href="https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/load_balancing/locality_weight">Locality Weight</a>
 The following example shows how to setup locality weights mesh-wide.</p>
 
 <p>Given a mesh with workloads and their service deployed to &ldquo;us-west/zone1/<em>&rdquo;
@@ -475,7 +475,7 @@ can be configured for a single control plane.</p>
 <td><code>string</code></td>
 <td>
 <p>The trust domain corresponds to the trust root of a system.
-Refer to https://github.com/spiffe/spiffe/blob/master/standards/SPIFFE-ID.md#21-trust-domain
+Refer to <a href="https://github.com/spiffe/spiffe/blob/master/standards/SPIFFE-ID.md#21-trust-domain">SPIFEE-ID</a>
 Fallback to old identity format(without trust domain) if not set.</p>
 
 </td>

content/docs/reference/config/istio.networking.v1alpha3/index.html

@@ -669,6 +669,16 @@ sizes, outlier detection).</p>
 <p>One or more named sets that represent individual versions of a
 service. Traffic policies can be overridden at subset level.</p>
 
+</td>
+</tr>
+<tr id="DestinationRule-export_to">
+<td><code>exportTo</code></td>
+<td><code>string[]</code></td>
+<td>
+<p>The resolution of a DestinationRule to apply to a service occurs in the
+context of a hierarchy of namespaces. This rule controls whether those
+namespaces are allowed to select this rule.</p>
+
 </td>
 </tr>
 </tbody>
@@ -1855,7 +1865,7 @@ destination.</p>
 <td><code><a href="#CorsPolicy">CorsPolicy</a></code></td>
 <td>
 <p>Cross-Origin Resource Sharing policy (CORS). Refer to
-https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS
+<a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS">CORS</a>
 for further details about cross origin resource sharing.</p>
 
 </td>
@@ -3230,7 +3240,7 @@ spec:
 
 <p>The following example demonstrates the use of a dedicated egress gateway
 through which all external service traffic is forwarded.
-The &lsquo;export_to&rsquo; field allows for control over the visibility of a service
+The &lsquo;exportTo&rsquo; field allows for control over the visibility of a service
 declaration to other namespaces in the mesh. By default a service is exported
 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
@@ -3244,8 +3254,8 @@ metadata:
 spec:
   hosts:
   - httpbin.com
-  export_to:
-  - .
+  exportTo:
+  - &quot;.&quot;
   location: MESH_EXTERNAL
   ports:
   - number: 80
@@ -3288,7 +3298,7 @@ metadata:
 spec:
   hosts:
   - httpbin.com
-  export_to:
+  exportTo:
   - *
   gateways:
   - mesh
@@ -3494,6 +3504,29 @@ said port will be allowed (i.e. 0.0.0.0:<port>).</p>
 <td>
 <p>One or more endpoints associated with the service.</p>
 
+</td>
+</tr>
+<tr id="ServiceEntry-export_to">
+<td><code>exportTo</code></td>
+<td><code>string[]</code></td>
+<td>
+<p>A list of namespaces to which this service is exported. Exporting a service
+allows it to used by sidecars, gateways and virtual services defined in
+other namespaces. This feature provides a mechanism for service owners
+and mesh administrators to control the visibility of services across
+namespace boundaries.</p>
+
+<p>If no namespaces are specified then the service is exported to all
+namespaces by default.</p>
+
+<p>The value &ldquo;.&rdquo; is reserved and defines an export to the same namespace that
+the service is declared in, similarly the value &ldquo;*&rdquo; is reserved and
+defines an export to all namespaces.</p>
+
+<p>For a Kubernetes Service the equivalent effect can be achieved by setting
+the annotation &ldquo;networking.istio.io/exportTo&rdquo; to a comma-separated list
+of namespace names.</p>
+
 </td>
 </tr>
 <tr id="ServiceEntry-subject_alt_names">
@@ -3728,7 +3761,7 @@ than one selector-less Sidecar resources exist in a given namespace. The
 behavior of the system is undefined if two or more Sidecar resources
 with a workload selector select the same workload.</p>
 
-<p>The example below delcares a Sidecar resource in the prod-us1 namespace
+<p>The example below declares a Sidecar resource in the prod-us1 namespace
 that configures the sidecars in the namespace to allow egress traffic to
 public services in the prod-us1, prod-apis, and the istio-system
 namespaces.</p>
@@ -3746,7 +3779,7 @@ spec:
     - &quot;istio-system/*&quot;
 </code></pre>
 
-<p>The example below delcares a Sidecar resource in the prod-us1 namespace
+<p>The example below declares a Sidecar resource in the prod-us1 namespace
 that accepts inbound HTTP traffic on port 9080 and forwards
 it to the attached workload listening on a unix domain socket. In the
 egress direction, in addition to the istio-system namespace, the sidecar
@@ -4573,6 +4606,25 @@ traffic.</p>
 be applied to any port that is not a HTTP or TLS port. The first rule
 matching an incoming request is used.</p>
 
+</td>
+</tr>
+<tr id="VirtualService-export_to">
+<td><code>exportTo</code></td>
+<td><code>string[]</code></td>
+<td>
+<p>A list of namespaces to which this virtual service is exported. Exporting a
+virtual service allows it to used by sidecars and gateways defined in
+other namespaces. This feature provides a mechanism for service owners
+and mesh administrators to control the visibility of virtual services
+across namespace boundaries.</p>
+
+<p>If no namespaces are specified then the virtual service is exported to all
+namespaces by default.</p>
+
+<p>The value &ldquo;.&rdquo; is reserved and defines an export to the same namespace that
+the virtual service is declared in, similarly the value &ldquo;*&rdquo; is reserved and
+defines an export to all namespaces.</p>
+
 </td>
 </tr>
 </tbody>

content/docs/reference/config/policy-and-telemetry/istio.policy.v1beta1/index.html

@@ -1006,6 +1006,15 @@ default mixer certificates will be used.</p>
 verify the presented adapter certificates. By default mixer should already
 include Istio CA certificates and system certificates in cert pool.</p>
 
+</td>
+</tr>
+<tr id="Mutual-server_name">
+<td><code>serverName</code></td>
+<td><code>string</code></td>
+<td>
+<p>Indicates the name of adapter backend server which is useful for routing with
+proxy-fronted backend.</p>
+
 </td>
 </tr>
 </tbody>
@@ -1313,6 +1322,15 @@ key, etc).</p>
 <p>Customized header key to hold access token, e.g. x-api-key. Token will be
 passed as what it is.</p>
 
+</td>
+</tr>
+<tr id="Tls-server_name">
+<td><code>serverName</code></td>
+<td><code>string</code></td>
+<td>
+<p>Indicates the name of adapter backend which is useful for routing with
+proxy-fronted backend.</p>
+
 </td>
 </tr>
 </tbody>