A service mesh is an architectural pattern that provides common network services as a feature of the infrastructure. This typically includes features such as service discovery and policy enforcement to control how services within the mesh can communicate with each other. By Luke Addison.
In addition to the core features, Istio also supports powerful extension points, as well as the ability to apply custom configuration to the Envoy sidecars. Here we will describe how Istio can be configured to manage the OpenID Connect (OIDC) authentication flow for applications running within the mesh to allow both authentication and authorisation decisions to be offloaded to Istio. There are a number of ways to achieve this with Istio however here we look at two solutions and how their integration points have been affected by changes to Istio’s architecture.
The article main parts are:
- OIDC - an identity layer built upon the OAuth 2.0 protocol
- Istio 1.4
- Istio 1.5 and Above
- Authentication
- oauth2-proxy
As we have demonstrated, a really powerful aspect of this is that our backend service can be completely unaware that OIDC is being used and does not need to support it itself. However, if the service has support for parsing the JWT, then it can also be used to authorise granular access to different features of the service.
All the code is explained and you will get plenty of links to further reading. With the provided configuration in place, you will be able to make further authorisation decisions based on the attached JWT and corresponding claims. Nice one!
[Read More]