istio | Connect , secure , control , and observe services | Microservice library

This seems to be a bug introduced with 1.25.0 version of minikube: https://github.com/kubernetes/minikube/issues/13503 . A PR to revert the changes introducing the bug is already open: https://github.com/kubernetes/minikube/pull/13506

The fix is scheduled for minikube v1.26.

As you noticed, knative uses istio as a service mesh.

In the Istio context mesh is not an object (or resource) like, for example, a Service. Istio About page explain what Service Mesh is:

A service mesh is a dedicated infrastructure layer that you can add to your applications. It allows you to transparently add capabilities like observability, traffic management, and security, without adding them to your own code. The term “service mesh” describes both the type of software you use to implement this pattern, and the security or network domain that is created when you use that software.

So mesh is a term that encapsulate all Istio objects (istio-proxy containers, Virtual Services, Ingress Gateways etc.), that work together to allow for traffic management inside cluster.

A Gateway is a load balancer operating at the edge of the mesh receiving incoming or outgoing HTTP/TCP connections.

What about something like this?

I consider if there is a way to use Istio to translate opaque token to JWT.

Unfortunately, Istio won't be able to translate the tokens. In your case, it seems to me that the easiest way is to get services in such a way that they work on one type of token.

Translation is possible, but not by Istio. Look at this question. You can also read more about Istio Authentication:

Istio provides two types of authentication:

• Peer authentication: used for service-to-service authentication to verify the client making the connection. Istio offers mutual TLS as a full stack solution for transport authentication, which can be enabled without requiring service code changes. This solution:

• Provides each service with a strong identity representing its role to enable interoperability across clusters and clouds. - Secures service-to-service communication. - Provides a key management system to automate key and certificate generation, distribution, and rotation.

• Request authentication: Used for end-user authentication to verify the credential attached to the request. Istio enables request-level authentication with JSON Web Token (JWT) validation and a streamlined developer experience using a custom authentication provider or any OpenID Connect providers, for example:

• ORY Hydra

• Keycloak

• Auth0

• Firebase Auth

• Google Auth

In all cases, Istio stores the authentication policies in the Istio config store via a custom Kubernetes API. Istiod keeps them up-to-date for each proxy, along with the keys where appropriate. Additionally, Istio supports authentication in permissive mode to help you understand how a policy change can affect your security posture before it is enforced.

AFAIK istio collects only ingress HTTP logs by default.

In the istio documentation there is an old article (from 2018) describing how to enable egress traffic HTTP logs.

Please keep in mind that some of the information may be outdated, however I believe this is the part that you are missing.

You are correct - x is shorthand for experimental.

You can see more information if you issue istioctl x without any additional commands:

Envoy does not support custom HTTP methods. Envoy implements the H/1 codec, which has a hardcoded list of HTTP methods it accepts (see RFC)

There is an open issue on the Envoy Github: https://github.com/envoyproxy/envoy/issues/18819

So you can't achieve what you want with an HTTP route. But you can make it work with a TCP/TLS route.

For this do the following:

1. Set the correct protocol on the service istio-ingressgateway:

I have reproduced your problem and the solution is as follows. First, pay attention to your yaml file:

I was able to figure it out.