Openshift Service Mesh 2.0 provides an easy way to connect microservices in a secure and consistent manner, and to build distributed, modulable and scalable applications on top of it.
Connecting microservices and securing these connections is rather simple thanks to custom ressources such as VirtualService and DestinationRule. But what about securing the access to the resulting applications? In an enterprise context, it might be desirable to have some high-level filtering - complementary to network-based filtering - regarding which users or teams can access which applications.
Istio - the control plane of Openshift Service Mesh 2.0 - provides natively some mechanisms for such filtering, based on a JSON Web Token (JWT) that a user would embed in a cookie when requesting an application. However, the retrieval and the embedding of the JWT is left to the user, and no native mechanism exists yet to provide a full automated workflow.
In this blog post, we go through these native authentication/authorization mechanisms, and explore a way to implement a full automated workflow based on OIDC. Red Hat Single Sign-On (RHSSO) is used as the authentication/authorization entity. All the code and more detailed READMEs for each approach are available in this repository.
This tutorial assumes that a running OCP 4.6 cluster and cluster-admin user are available.
Requirements
- have an OCP 4.6 running cluster
- have a user with cluster-admin role
- have Service Mesh 2.0 installed
- have a RHSSO platform inside the cluster deployed using the RHSSO operator
- have bookinfo service mesh application example deployed
Approach 1: Using Istio native mechanisms for JWT-based authorization
In this approach, access to the bookinfo
application is restricted using Istio-related CRD RequestAuthentication and AuthorizationPolicy deployed in the cluster. A user can access the application by providing a JWT token in its HTTP request (through the HTTP Header Authorization
).
The workflow is as follows:
- the user authenticates to RHSSO and get a JWT token (not shown in the above picture);
- the user performs an HTTP request to
https://<route>/productpage
and passes along this request the JWT token; - the Istio ingress gateway (default one) forwards the request and the JWT token to the istio-proxy container of the productpage pod;
- the istio-proxy container of the productpage pod checks the validity of the JWT token depending on the
RequestAuthentication
andAuthorizationPolicy
objects deployed beforehand; - if the JWT token is valid, user accesses
/productpage
- otherwise, an error message is returned to the user (code 404, message "RBAC denied" or others).
Pros:
- the simplest approach (only 2 CR to be deployed)
- fine-grained authorization based on JWT token fields
Cons:
- no OIDC workflow: the user must get a JWT token on its own, and pass it with the HTTP request on its own
- need to define
RequestAuthentication
andAuthorizationPolicy
objects for each application to protect inside the service mesh
Approach 2: Injecting oauth2-proxy container inside the Istio ingress gateway to implement an OIDC workflow
In this approach, access to the bookinfo
application is restricted by injecting an oauth2-proxy sidecar container to the Istio ingress gateway. The oauth2-proxy will enforce user authentication with RHSSO before forwarding any request to the istio-proxy (the default container of the Istio ingress gateway). In this approach, the OIDC workflow between the user, oauth2-proxy and RHSSO is perfomed automatically.
The workflow is as follows:
- the user performs an unauthenticated HTTP request to
https://<route>/productpage
; - the oauth2-proxy inside the Istio ingress gateway pod initiates the OIDC workflow to authenticate the user; user authenticates to RHSSO (not shown on the picture);
- the user performs an authenticated HTTP request to
https://<route>/productpage
; the authentication is checked by the oauth2-proxy using HTTP cookies; - the oauth2-proxy forwards locally (same pod) the request to the istio-proxy container of the Istio ingress gateway, which in turn forwards the request to the istio-proxy container of the productpage pod;
- user accesses
/productpage
.
Pros:
- authentication enforced at the ingress gateway level (no need to define
RequestAuthentication
andAuthorizationPolicy
objects for each application) - automated OIDC workflow to authenticate the user
Cons:
- coarse-grained authorization (authenticated == authorized)
- complex setup (involve patches)
Approach 3: Combining JWT-based authorization and OIDC workflow
This approach combines the use of RequestAuthentication
and AuthorizationPolicy
objects as done for approach 1, and the injection of the oauth2-proxy container as done in the approach 2. In this approach, the oauth2-proxy container extracts the JWT token from the authentication cookie, and forwards it to the istio-proxy container alongside the HTTP request (using the X-Forwarded-Access-Token
HTTP header). As a result, an automated OIDC workflow to authenticate the user is performed, and can be, if needed, combined to a fine-grained authorization based on JWT token fields (e.g. simple auth for 'non-secure' apps, auth + JWT field for more secure apps).
The workflow is as follows:
- the user performs an unauthenticated HTTP request to
https://<route>/productpage
; - the oauth2-proxy inside the Istio ingress gateway pod initiates the OIDC workflow to authenticate the user; user authenticates to RHSSO (not shown on the picture);
- the user performs an authenticated HTTP request to
https://<route>/productpage
; the authentication is checked by the oauth2-proxy using HTTP cookies; - the oauth2-proxy extracts the JWT token from the authentication cookie and forwards it locally (same pod) alongside the HTTP request to the istio-proxy container of the Istio ingress gateway;
- the istio-proxy container of the Istio ingress gateway forwards the request and the JWT token to the istio-proxy container of the productpage pod;
- the istio-proxy container of the productpage pod checks the validity of the JWT token depending on the
RequestAuthentication
andAuthorizationPolicy
objects deployed beforehand; - if the JWT token is valid, user accesses
/productpage
- otherwise, an error message is returned to the user (code 404, message "RBAC denied" or others).
Pros:
- authentication enforced at the ingress gateway level
- automated OIDC workflow to authenticate the user
- if needed, fine-grained authorization based on JWT token fields
Cons:
- complex setup (currently involves deployment / service / route patches)
References
À propos de l'auteur
Contenu similaire
Parcourir par canal
Automatisation
Les dernières nouveautés en matière d'automatisation informatique pour les technologies, les équipes et les environnements
Intelligence artificielle
Actualité sur les plateformes qui permettent aux clients d'exécuter des charges de travail d'IA sur tout type d'environnement
Cloud hybride ouvert
Découvrez comment créer un avenir flexible grâce au cloud hybride
Sécurité
Les dernières actualités sur la façon dont nous réduisons les risques dans tous les environnements et technologies
Edge computing
Actualité sur les plateformes qui simplifient les opérations en périphérie
Infrastructure
Les dernières nouveautés sur la plateforme Linux d'entreprise leader au monde
Applications
À l’intérieur de nos solutions aux défis d’application les plus difficiles
Programmes originaux
Histoires passionnantes de créateurs et de leaders de technologies d'entreprise
Produits
- Red Hat Enterprise Linux
- Red Hat OpenShift
- Red Hat Ansible Automation Platform
- Services cloud
- Voir tous les produits
Outils
- Formation et certification
- Mon compte
- Assistance client
- Ressources développeurs
- Rechercher un partenaire
- Red Hat Ecosystem Catalog
- Calculateur de valeur Red Hat
- Documentation
Essayer, acheter et vendre
Communication
- Contacter le service commercial
- Contactez notre service clientèle
- Contacter le service de formation
- Réseaux sociaux
À propos de Red Hat
Premier éditeur mondial de solutions Open Source pour les entreprises, nous fournissons des technologies Linux, cloud, de conteneurs et Kubernetes. Nous proposons des solutions stables qui aident les entreprises à jongler avec les divers environnements et plateformes, du cœur du datacenter à la périphérie du réseau.
Sélectionner une langue
Red Hat legal and privacy links
- À propos de Red Hat
- Carrières
- Événements
- Bureaux
- Contacter Red Hat
- Lire le blog Red Hat
- Diversité, équité et inclusion
- Cool Stuff Store
- Red Hat Summit