--sinkMeta <stringSlice>--tlsCertFile <string>--sinkMeta <stringSlice>--tlsCertFile <string>--sinkMeta <stringSlice>--tlsCertFile <string>-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.
-istioctl authn tls-check [<service>] [flags]
+istioctl authn tls-check <pod-name[.namespace]> [<service>] [flags]
@@ -262,11 +262,12 @@ service registry, and check if TLS settings are compatible between them.
Examples
-# Check settings for all known services in the service registry:
-istioctl authn tls-check
+# Check settings for pod "foo-656bd7df7c-5zp4s" 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 "foo-656bd7df7c-5zp4s" in namespace default, filtered on destintation
+service "bar" :
+istioctl authn tls-check 656bd7df7c-5zp4s.default bar
istioctl deregister
diff --git a/content/docs/reference/config/istio.authentication.v1alpha1/index.html b/content/docs/reference/config/istio.authentication.v1alpha1/index.html
index 12aa2f3395..33e58067d7 100644
--- a/content/docs/reference/config/istio.authentication.v1alpha1/index.html
+++ b/content/docs/reference/config/istio.authentication.v1alpha1/index.html
@@ -11,7 +11,7 @@ number_of_entries: 11
Jwt
JSON Web Token (JWT) token format for authentication as defined by
-https://tools.ietf.org/html/rfc7519. See OAuth
+RFC 7519. See OAuth
2.0 and OIDC
1.0 for how this is used in the whole
authentication flow.
diff --git a/content/docs/reference/config/istio.mesh.v1alpha1/index.html b/content/docs/reference/config/istio.mesh.v1alpha1/index.html
index 37d2a280d3..8ed809453a 100644
--- a/content/docs/reference/config/istio.mesh.v1alpha1/index.html
+++ b/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/archoverview/loadbalancing/locality_weight
+Locality Weight
The following example shows how to setup locality weights mesh-wide.
Given a mesh with workloads and their service deployed to “us-west/zone1/”
@@ -475,7 +475,7 @@ can be configured for a single control plane.
string
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 SPIFEE-ID
Fallback to old identity format(without trust domain) if not set.
diff --git a/content/docs/reference/config/istio.networking.v1alpha3/index.html b/content/docs/reference/config/istio.networking.v1alpha3/index.html
index b63dad1da5..c198714f36 100644
--- a/content/docs/reference/config/istio.networking.v1alpha3/index.html
+++ b/content/docs/reference/config/istio.networking.v1alpha3/index.html
@@ -669,6 +669,16 @@ sizes, outlier detection).
One or more named sets that represent individual versions of a
service. Traffic policies can be overridden at subset level.
+
+ exportTostring[]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.
+CorsPolicyCross-Origin Resource Sharing policy (CORS). Refer to -https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS +CORS for further details about cross origin resource sharing.
The following example demonstrates the use of a dedicated egress gateway
through which all external service traffic is forwarded.
-The ‘export_to’ field allows for control over the visibility of a service
+The ‘exportTo’ 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 “.”, so that it cannot be used by other
@@ -3244,8 +3254,8 @@ metadata:
spec:
hosts:
- httpbin.com
- export_to:
- - .
+ exportTo:
+ - "."
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:
One or more endpoints associated with the service.
+exportTostring[]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.
+ +If no namespaces are specified then the service is exported to all +namespaces by default.
+ +The value “.” is reserved and defines an export to the same namespace that +the service is declared in, similarly the value “*” is reserved and +defines an export to all namespaces.
+ +For a Kubernetes Service the equivalent effect can be achieved by setting +the annotation “networking.istio.io/exportTo” to a comma-separated list +of namespace names.
+The example below delcares a Sidecar resource in the prod-us1 namespace +
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.
@@ -3746,7 +3779,7 @@ spec: - "istio-system/*" -The example below delcares a Sidecar resource in the prod-us1 namespace +
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.
be applied to any port that is not a HTTP or TLS port. The first rule matching an incoming request is used. + +exportTostring[]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.
+ +If no namespaces are specified then the virtual service is exported to all +namespaces by default.
+ +The value “.” is reserved and defines an export to the same namespace that +the virtual service is declared in, similarly the value “*” is reserved and +defines an export to all namespaces.
+serverNamestringIndicates the name of adapter backend server which is useful for routing with +proxy-fronted backend.
+Customized header key to hold access token, e.g. x-api-key. Token will be passed as what it is.
+ + +serverNamestringIndicates the name of adapter backend which is useful for routing with +proxy-fronted backend.
+