Version 1.15

Versions disponibles

1.20 (la plus récente)
1.19
1.18
1.17
1.16
1.15
1.14
1.13
1.12
1.11
1.10
1.9
1.8
1.7
1.6
1.5
1.4

Cette page a été traduite par l'API Cloud Translation.

Configurer l'authentification des utilisateurs avec Cloud Service Mesh

L'authentification des utilisateurs avec Cloud Service Mesh est une solution intégrée pour l'authentification des utilisateurs finaux via un navigateur et le contrôle des accès à vos charges de travail déployées. Elle permet l'intégration aux fournisseurs d'identité (IDP) existants pour l'authentification des utilisateurs, et utilise les API et règles d'autorisation Istio pour la gestion des accès. Il s'agit d'une alternative plus facile à utiliser que l'authentification par jeton Web JSON (JWT) d'Istio.

Un cas d'utilisation classique est celui d'une entreprise qui utilise Cloud Service Mesh pour héberger une application Web à laquelle son personnel doit accéder via un navigateur Web. De plus, l'organisation doit faire appel à son fournisseur d'identité existant pour gérer les identités des utilisateurs. L'authentification des utilisateurs avec Cloud Service Mesh permet aux utilisateurs de s'authentifier facilement à l'aide d'un flux de connexion et d'autorisation OpenID Connect (OIDC) Web standard. Lorsque l'utilisateur s'authentifie, Cloud Service Mesh applique les règles d'autorisation Istio et, en cas d'autorisation réussie, il transmet l'identité aux charges de travail dans un format d'identifiants sécurisé.

Fonctionnement

L'authentification des utilisateurs avec Cloud Service Mesh introduit un nouveau composant, authservice. Ce composant s'intègre au contrôle d'entrée basé sur Envoy en tant que service d'autorisation externe qui intercepte toutes les requêtes entrantes pour authentification. authservice met en œuvre le côté client du protocole OIDC et permet aux utilisateurs d'accéder aux applications via un navigateur, d'où ils suivent un flux d'authentification et d'autorisation interactif afin d'établir une session de courte durée. authservice met en œuvre des protocoles standards dans l'industrie pour permettre l'intégration à n'importe quel fournisseur d'identité capable d'agir en tant que serveur d'autorisation OIDC. Une fois l'utilisateur authentifié, les informations principales sont encapsulées dans un jeton RCToken au format JWT, qui est signé par authservice, puis transféré vers la couche d'autorisation Istio dans l'entrée. Ce modèle fournit un contrôle d'accès de périmètre pour le trafic entrant dans le maillage. Si l'utilisateur est autorisé à accéder à une ressource, ce jeton RCToken est également transmis aux microservices afin qu'ils obtiennent les informations principales et puissent appliquer un contrôle d'accès précis.

Le schéma suivant illustre l'emplacement de authservice dans le maillage et son lien avec les autres parties du maillage, telles que l'entrée, les charges de travail, le navigateur de l'utilisateur et tout IDP existant.

Authentification de l'utilisateur final

Les administrateurs peuvent installer authservice en tant que module complémentaire sur une installation de Cloud Service Mesh. Une fois installé, authservice lit la configuration du point de terminaison OIDC et les autres paramètres associés définis dans la ressource personnalisée UserAuth. L'administrateur peut utiliser les API ExternalAuthorization de Cloud Service Mesh pour configurer auth_server en tant que filtre sur l'entrée.

Installer le service d'authentification des utilisateurs

Les étapes suivantes expliquent comment configurer le service authservice.

Prérequis

Suivez les étapes de la page Installer les outils dépendants et valider le cluster pour effectuer les opérations suivantes :

Si vous utilisez Cloud Service Mesh géré sur un cluster privé, assurez-vous que le cluster est capable d'envoyer le trafic sortant vers l'IDP.

De plus, assurez-vous de bien satisfaire les prérequis en procédant comme suit :

Personnaliser la superposition d'authentification de l'utilisateur d'installation

Pour installer le service d'authentification des utilisateurs, vous devez personnaliser l'installation de Cloud Service Mesh afin d'ajouter un fournisseur d'autorisation externe au niveau du maillage. Les étapes requises varient selon que vous utilisez Cloud Service Mesh géré ou en cluster.

Géré

Mettez à jour le ConfigMap pour inclure le MeshConfig d'authentification utilisateur. Dans la commande suivante, utilisez le même REVISION_LABEL que celui utilisé lors du provisionnement de Cloud Service Mesh géré (par exemple, asm-managed, asm-managed-rapid ou asm-managed-stable):
```
kubectl edit configmap istio-REVISION_LABEL -n istio-system
```

Ajoutez le texte suivant sous le champ mesh de MeshConfig :

mesh: |-
...
  extensionProviders:
  - name: "asm-userauth-grpc"
    envoyExtAuthzGrpc:
      service: "authservice.asm-user-auth.svc.cluster.local"
      port: "10003"

Créez un espace de noms asm-user-auth et ajoutez-lui un libellé.
```
kubectl create namespace asm-user-auth
kubectl label namespace asm-user-auth istio.io/rev=REVISION --overwrite
```
Pour trouver le libellé REVISION, reportez-vous à la section Libellés d'injection.

Installez la passerelle Istio dans l'espace de noms asm-user-auth.

kubectl apply -n asm-user-auth -f DIR_PATH/samples/gateways/istio-ingressgateway

Dans le cluster

Obtenez l'exemple de superposition d'authentification des utilisateurs et mettez-le à jour si vous avez personnalisé votre maillage. Nous vous recommandons de conserver ce fichier de superposition dans votre système de gestion de code source.
```
curl https://raw.githubusercontent.com/GoogleCloudPlatform/asm-user-auth/v1.2.1/overlay/user-auth-overlay.yaml > user-auth-overlay.yaml
```
Suivez les instructions de la section Installer Cloud Service Mesh avec une superposition pour utiliser un script fourni par Google pour installer Cloud Service Mesh avec la superposition d'authentification de l'utilisateur. Exemple :
```
./asmcli install \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --fleet_id FLEET_PROJECT_ID \
  --output_dir DIR_PATH \
  --enable_all \
  --custom_overlay user-auth-overlay.yaml
```
Important :Si vous personnalisez l'installation avec plusieurs superpositions, assurez-vous que l'option --custom_overlay inclut tous vos fichiers de superposition.

Les packages kpt d'authentification des utilisateurs créent une règle AuthorizationPolicy permettant de référencer le fournisseur d'autorisation externe spécifié par pkg/ext-authz.yaml.
Créez un espace de noms asm-user-auth et ajoutez-lui un libellé.
```
kubectl create namespace asm-user-auth
kubectl label namespace asm-user-auth istio.io/rev=REVISION --overwrite
```
Vous pouvez trouver la valeur du libellé REVISION en vérifiant kubectl get pod -n istio-system -L istio.io/rev

Installez la passerelle Istio dans l'espace de noms asm-user-auth.

kubectl apply -n asm-user-auth -f DIR_PATH/samples/gateways/istio-ingressgateway

Préparer la configuration du client OIDC

Définissez la configuration de votre client OIDC en suivant la procédure ci-dessous. Ce guide utilise Google comme fournisseur d'identité, mais vous pouvez utiliser n'importe quel IdP compatible avec l'authentification OIDC.

Dans la console Google Cloud, accédez à API et services > Identifiants.

Accéder à "Identifiants"
Accédez à Créer des identifiants, puis sélectionnez ID client OAuth. Si nécessaire, définissez les options de l'écran d'autorisation OAuth, puis configurez les options suivantes :
- Définissez le paramètre Type d'application sur Application Web.
- Définissez l'URI de redirection autorisé sur https://REDIRECT_HOST/REDIRECT_PATH. Par exemple, pour localhost, vous pouvez définir https://localhost:8443/_gcp_asm_authenticate.
Ensuite, cliquez sur Enregistrer.

Enregistrez également la configuration de votre client OIDC pour pouvoir l'utiliser ultérieurement.

export OIDC_CLIENT_ID=CLIENT_ID
export OIDC_CLIENT_SECRET=CLIENT_SECRET
export OIDC_ISSUER_URI=ISSUER_URI
export OIDC_REDIRECT_HOST=REDIRECT_HOST
export OIDC_REDIRECT_PATH=REDIRECT_PATH

Obtenir les packages `kpt`

Procédez comme suit pour installer la configuration authservice recommandée à partir du dépôt public. Ces commandes récupèrent le conteneur authservice le plus récent et le lancent en tant que pod dans l'espace de noms asm-user-auth. Elles configurent également l'entrée pour qu'elle intercepte toutes les requêtes.

Obtenez le package kpt :

kpt pkg get https://github.com/GoogleCloudPlatform/asm-user-auth.git/@v1.2.1 .
cd asm-user-auth/

Définir l'URL de redirection et le code secret pour la passerelle d'entrée

OAuth2 nécessite une URL de redirection hébergée sur un point de terminaison protégé par HTTPS. Ces commandes sont fournies à titre d'exemple et simplifient la configuration en générant un certificat autosigné pour la passerelle d'entrée Istio.

Générez un certificat autosigné :

openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem \
 -days 365 -nodes -subj '/CN=localhost'

Créez un code secret permettant à la passerelle d'entrée d'héberger le trafic HTTPS :

kubectl create -n asm-user-auth secret tls userauth-tls-cert --key=key.pem \
--cert=cert.pem

Appliquer les clés de chiffrement et de signature

authservice a besoin de deux ensembles de clés pour fonctionner correctement. Le premier est constitué d'une clé symétrique pour le chiffrement et le déchiffrement. Cette clé permet de chiffrer l'état de la session avant de la définir en tant que cookie.

Le second ensemble de clés est une paire de clés publique/privée. Cette clé est utilisée pour signer les informations des utilisateurs authentifiés au format JWT en tant que jeton RCToken. La clé publique de cette paire de clés est publiée sur un point de terminaison prédéfini, que les side-cars peuvent utiliser pour valider le jeton JWT.

Le package kpt d'authentification des utilisateurs contient deux exemples de clés permettant une configuration rapide. Toutefois, vous pouvez aussi utiliser le système de gestion de clés de votre choix pour générer ces clés.

Préparez la clé de chiffrement de session au format suivant ou utilisez l'exemple du fichier pkg, que vous pouvez afficher avec cat ./samples/cookie_encryption_key.json.

{
  "keys":[
     {
        "kty":"oct",
        "kid":"key-0",
        "K":"YOUR_KEY",
        "useAfter": 1612813735
     }
  ]
}

Vous pouvez générer une clé AES de test à l'aide de la commande suivante :

openssl enc -aes-256-cbc -k mycustomkey -P -md sha1 | grep key

Préparez la clé de signature de jeton RCToken au format suivant ou utilisez l'exemple du fichier pkg, que vous pouvez afficher avec cat ./samples/rctoken_signing_key.json.

{
  "keys":[
     {
        "kty":"RSA",
        "kid":"rsa-signing-key",
        "K":"YOUR_KEY",  # k contains a Base64 encoded PEM format RSA signing key.
        "useAfter": 1612813735  # unix timestamp
     }
  ]
}

Vous pouvez générer une clé privée RSA 256 bits de test à l'aide de la commande suivante :

openssl genpkey -algorithm RSA -out rsa_private.pem -pkeyopt rsa_keygen_bits:256

Créez le secret Kubernetes que authservice va installer dans son propre système de fichiers.

kubectl create secret generic secret-key  \
    --from-file="session_cookie.key"="./samples/cookie_encryption_key.json" \
    --from-file="rctoken.key"="./samples/rctoken_signing_key.json"  \
    --namespace=asm-user-auth

Déployer le service d'authentification des utilisateurs

Les commandes suivantes créent le service d'authentification des utilisateurs et son déploiement dans l'espace de noms asm-user-auth.

Définissez les valeurs nécessaires pour la configuration de l'authentification des utilisateurs. L'ID client et le secret sont stockés en tant que secrets Kubernetes. Nous utilisons donc Base64 pour les encoder. Veuillez consulter le dépôt public pour afficher tous les setters disponibles.

kpt fn eval pkg --image gcr.io/kpt-fn/apply-setters:v0.2 --truncate-output=false -- \
  client-id="$(echo -n ${OIDC_CLIENT_ID} | base64 -w0)" \
  client-secret="$(echo -n ${OIDC_CLIENT_SECRET} | base64 -w0)" \
  issuer-uri="${OIDC_ISSUER_URI}" \
  redirect-host="${OIDC_REDIRECT_HOST}" \
  redirect-path="${OIDC_REDIRECT_PATH}"

Appliquez le package kpt :

# Remove the potential alpha version CRD if exists.
kubectl delete crd userauthconfigs.security.anthos.io
kubectl apply -f ./pkg/asm_user_auth_config_v1beta1.yaml
kubectl apply -f ./pkg

authservice utilise l'objet CRD UserAuthConfig pour fournir l'authentification des utilisateurs finaux. UserAuthConfig est configurable en cours d'exécution. Vous pouvez le mettre à jour pour modifier le comportement de authservice et y configurer des points de terminaison pour tout serveur d'autorisation OIDC.

Vous pouvez afficher le fichier à l'aide de cat pkg/user_auth_config.yaml, qui contient les champs suivants :

apiVersion: security.anthos.io/v1beta1
kind: UserAuthConfig
metadata:
  name: user-auth-config
  namespace: asm-user-auth
spec:
  authentication:
    oidc:
      certificateAuthorityData: ""  # kpt-set: ${ca-cert}
      issuerURI: "<your issuer uri>"  # kpt-set: ${issuer-uri}
      proxy: ""  # kpt-set: ${proxy}
      oauthCredentialsSecret:
        name: "oauth-secret"  # kpt-set: ${secret-name}
        namespace: "asm-user-auth"  # kpt-set: ${secret-namespace}
      redirectURIHost: ""  # kpt-set: ${redirect-host}
      redirectURIPath: "/_gcp_asm_authenticate"  # kpt-set: ${redirect-path}
      scopes: ""  # kpt-set: ${scopes}
      groupsClaim: ""  # kpt-set: ${groups}
  outputJWTAudience: "test_audience"  # kpt-set: ${jwt-audience}

Pour en savoir plus sur les champs user_auth_config.yaml, consultez la section Détails de la configuration de l'authentification utilisateur.

Effectuer les tâches post-installation

Les tâches suivantes sont nécessaires une fois que vous avez terminé les étapes d'installation précédentes.

Activer l'authentification des utilisateurs pour vos applications

Cette section montre comment activer l'authentification des utilisateurs, en utilisant httpbin comme exemple.

L'authentification des utilisateurs avec Cloud Service Mesh utilise une règle d'autorisation de type CUSTOM pour déclencher le flux OIDC.

Après avoir installé la passerelle Istio, configurez-la pour diffuser le trafic HTTPS en utilisant le certificat TLS userauth-tls-cert créé ci-dessus. Vous trouverez ci-dessous la configuration pkg/gateway.yaml que vous venez d'installer.

apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: userauth
  namespace: asm-user-auth
spec:
  selector:
    istio: ingressgateway
  servers:
  - hosts:
    - '*'
    port:
      name: https
      number: 443
      protocol: HTTPS
    tls:
      mode: SIMPLE
      credentialName: userauth-tls-cert
---
# This ensures the OIDC endpoint has at least some route defined.
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: userauth-oidc
  namespace: asm-user-auth
spec:
  gateways:
  - userauth
  hosts:
  - '*'
  http:
  - match:
    - uri:
        prefix: /status
    - uri:
        prefix: "your-oidc-redirect-path"
    name: user-auth-route
    route:
    - destination:
        host: authservice
        port:
          number: 10004

Ajoutez un libellé à l'espace de noms default pour activer l'injection automatique de istio-proxy pour les déploiements.
```
kubectl label namespace default istio.io/rev=REVISION --overwrite
```

Déployez httpbin sur l'espace de noms default.

kubectl apply -f https://raw.githubusercontent.com/istio/istio/master/samples/httpbin/httpbin.yaml -n default

Mettez à jour httpbin afin d'utiliser cette passerelle pour diffuser le trafic HTTPS, et utilisez le transfert de port pour accéder à l'application localement :
```
kubectl apply -f./samples/httpbin-route.yaml -n default
kubectl port-forward service/istio-ingressgateway 8443:443 -n asm-user-auth
```
La passerelle d'entrée sur le port 8443 sera transférée vers localhost afin de rendre l'application accessible localement.

Déployez samples/rctoken-authz.yaml pour activer RequestAuthentication et AuthorizationPolicy afin de vérifier le jeton RCToken pour les requêtes.

kubectl apply -f ./samples/rctoken-authz.yaml -n asm-user-auth

Exemple samples/rctoken-authz.yaml :

apiVersion: security.istio.io/v1beta1
kind: RequestAuthentication
metadata:
  name: require-rc-token
spec:
  selector:
    matchLabels:
      istio: ingressgateway
  jwtRules:
  - issuer: "authservice.asm-user-auth.svc.cluster.local"
    audiences:
    - "test_audience"
    jwksUri: "http://authservice.asm-user-auth.svc.cluster.local:10004/_gcp_user_auth/jwks"
    fromHeaders:
    - name: X-ASM-RCTOKEN
    forwardOriginalToken: true
---
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: require-rc-token
spec:
  selector:
    matchLabels:
      istio: ingressgateway
  action: ALLOW
  rules:
  - when:
    - key: request.auth.claims[iss]
      values:
      - authservice.asm-user-auth.svc.cluster.local
    - key: request.auth.claims[aud]
      values:
      - test_audience

Valider l'authentification des utilisateurs

Le port httpbin diffuse deux chemins. /ip est accessible au public et /headers nécessite que l'utilisateur final se connecte via son fournisseur d'identité configuré.

Vérifiez que vous pouvez accéder directement à /ip en vous rendant à l'adresse https://localhost:8443/ip.
Vérifiez que la page de connexion OIDC s'affiche en accédant à l'adresse https://localhost:8443/headers.
Une fois connecté, cliquez sur Suivant et vérifiez que vous êtes redirigé vers la page /headers.

Configurer les règles d'autorisation

Une fois la configuration décrite dans les étapes précédentes terminée, chaque utilisateur sera redirigé via un flux d'authentification Web. À la fin de ce flux, authservice génère un jeton RCToken au format JWT qui permet de transmettre les informations sur l'utilisateur authentifié.

Ajoutez à l'entrée des règles d'autorisation Istio pour vous assurer qu'une vérification d'autorisation est effectuée pour chaque utilisateur authentifié :
```
kubectl apply -f ./samples/httpbin-authz.yaml -n asm-user-auth
```

Le fichier httpbin-authz.yaml configure la passerelle d'entrée pour valider le jeton RC émis par authservice et n'accorder l'autorisation que lorsque le jeton JWT contient les champs souhaités, tels que des audiences et des émetteurs.

Examinez l'exemple de règle d'autorisation suivant :

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: require-rc-token
spec:
  selector:
    matchLabels:
      istio: ingressgateway
  action: ALLOW
  rules:
  - to:
    - operation:
        paths: ["/ip"]
  - to:
    when:
    - key: request.auth.claims[iss]
      values:
      - authservice.asm-user-auth.svc.cluster.local
    - key: request.auth.claims[aud]
      values:
      - test_audience
    - key: request.auth.claims[sub]
      values:
      - allowed_user_sub_1  # Change this with the "sub" claim in the RC token. Wildcard '*' will match everything.

Configurer les paramètres spécifiques à l'environnement

Les étapes précédentes utilisent localhost et un certificat HTTPS autosigné pour une configuration rapide. Pour une utilisation réelle en production, utilisez votre propre domaine, par exemple example.com.

De plus, assurez-vous que certificateAuthorityData contient le contenu du certificat racine prévu. Par exemple, si le fournisseur d'identité (IdP) est approuvé avec les certificats racine du système, vous pouvez le laisser vide. Si un proxy HTTPS met fin à la connexion HTTPS, il doit être défini sur le certificat racine du proxy.

Gérer et alterner les clés

authservice utilise deux ensembles de clés. Vous pouvez alterner chaque clé de manière indépendante. Cependant, avant d'alterner les clés, il est important de comprendre comment fonctionne la rotation.

Les deux clés sont au format JSON. Le champ useAfter spécifie l'horodatage définissant le moment à partir duquel la clé doit être utilisée. Lors d'une rotation de clé, vous devez inclure dans le JSON à la fois l'ancienne et la nouvelle clé. Par exemple, dans l'exemple suivant, new-key ne sera utilisé qu'après l'horodatage 1712813735.

{
   "keys":[
      {
         "kty":"RSA",
         "kid":"old-key",
         "K":"...", # k contains a Base64 encoded PEM format RSA signing key.
         "useAfter": 1612813735, # unix timestamp
      }
      {
      "kty":"RSA",
         "kid":"new-key",
         "K":"...", # k contains a Base64 encoded PEM format RSA signing key.
         "useAfter": 1712813735, # unix timestamp
      }
   ]
}

Cloud Service Mesh utilise la clé symétrique pour chiffrer les données de session stockées dans les cookies du navigateur. Pour garantir la validité des sessions existantes, authservice tente le déchiffrement avec toutes les clés de l'ensemble de clés. Lors d'une rotation, authservice utilise la nouvelle clé pour chiffrer les nouvelles sessions et continue à tenter le déchiffrement avec les anciennes clés.

La paire de clés publique/privée est utilisée pour signer RCToken. La clé publique est transmise aux side-cars par istiod pour la validation JWT. Les side-cars doivent impérativement recevoir la nouvelle clé publique avant que authservice ne commence à utiliser la nouvelle clé privée pour signer les jetons RCToken. Pour cela, authservice commence à publier la clé publique immédiatement après son ajout, mais attend un certain temps avant de l'utiliser pour signer des jetons RCToken.

En résumé, lorsque vous effectuez des rotations de clés, nous vous recommandons de procéder comme suit :

Effectuez des rotations de clés régulières ou à la demande selon vos besoins.
Au format JSON, incluez à la fois la clé actuelle et la nouvelle clé. Les nouvelles clés doivent être associées à un horodatage futur. Nous vous recommandons de spécifier un horodatage avec au moins quelques heures d'avance sur l'heure actuelle.
Surveillez et confirmez que les services sont toujours opérationnels après l'utilisation de la nouvelle clé. Attendez au moins un jour après l'utilisation de la nouvelle clé avant de passer à l'étape suivante.
Supprimez les anciennes clés des entrées JSON. Elles ne sont plus nécessaires.

Déploiement multicluster

L'authentification utilisateur de Cloud Service Mesh est compatible avec le déploiement multicluster. Vous devez déployer l'authentification utilisateur dans chaque cluster comme décrit ci-dessus. Les éléments de la configuration de l'authentification utilisateur, tels que la ressource personnalisée UserAuth, le code secret du client OIDC et les clés de chiffrement, doivent tous être répliqués dans chaque cluster.

Par défaut, la passerelle d'entrée équilibre la charge des requêtes d'authentification sur l'une des instances authservice. Vous pouvez utiliser la règle de destination pour configurer la passerelle d'entrée de manière à ce qu'elle envoie des requêtes au authservice du même cluster et qu'elle ne bascule que vers les authservice des autres clusters.

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: authservice-fail-over
  namespace: asm-user-auth
spec:
  host: authservice.asm-user-auth.svc.cluster.local
  trafficPolicy:
    loadBalancer:
      localityLbSetting:
        enabled: true
        failover:
        - from:  us-east
          to: us-west
        - from: us-west
          to: us-east

Comme d'autres configurations, cela doit être configuré dans chaque cluster.

Mappage des revendications personnalisé

Pour configurer un mappage de revendications personnalisé, configurez spec.authentication.oidc.attributeMapping pour définir les mappages à partir du jeton d'ID du fournisseur d'identité d'origine. La clé sera le nom de revendication dans le jeton RCToken et la valeur est une expression CEL sur la façon d'analyser la revendication à partir d'IDToken, en utilisant assertion pour référencer l'IDToken.

Exemple :

spec:
  authentication:
    oidc:
      attributeMapping:
        aud_copy: assertion.aud
        decision: 'assertion.sub.startsWith("123") ? "success" : "fail"'

Dans le jeton RCToken, une revendication imbriquée attributes contient les revendications configurées:

"attributes": {
    "aud_copy": "foo.googleusercontent.com",
    "decision": "success"
}

Si l'expression CEL ne parvient pas à analyser la valeur d'IDToken, elle ignorera la revendication sans faire échouer le flux d'authentification.

Mises à niveau de l'authentification utilisateur

Installez à nouveau les packages user-auth, car ils contiennent le binaire mis à jour pour la nouvelle version de user-auth :
```
kpt pkg get https://github.com/GoogleCloudPlatform/asm-user-auth.git/@v1.2.1 .
cd asm-user-auth/
```

Enregistrez la configuration de votre client OIDC :

export OIDC_CLIENT_ID=CLIENT_ID
export OIDC_CLIENT_SECRET=CLIENT_SECRET
export OIDC_ISSUER_URI=ISSUER_URI
export OIDC_REDIRECT_HOST=REDIRECT_HOST
export OIDC_REDIRECT_PATH=REDIRECT_PATH

Déployez le service d'authentification utilisateur pour effectuer une mise à niveau vers une version plus récente.

Détails de la configuration de l'authentification utilisateur

Le tableau suivant décrit chaque champ de l'objet CRD :

Nom du champ	Description
`authentication.oidc`	Cette section contient la configuration du point de terminaison OIDC et les paramètres utilisés dans le flux OIDC.
`authentication.oidc.certificateAuthorityData`	Il s'agit du certificat racine SSL du domaine du serveur d'autorisation OIDC ou du proxy HTTPS, le cas échéant.
`authentication.oidc.oauthCredentialsSecret`	Références secrètes au secret de type Opaque Kubernetes qui contient les paramètres client OIDC OAuth2 et client_secret dans la charge utile JSON.
`authentication.oidc.issuerURI`	URI à utiliser comme émetteur dans le jeton RCToken de sortie.
`authentication.oidc.proxy`	Serveur proxy vers le fournisseur d'identité OIDC, le cas échéant. Au format http://user:password@10.10.10.10:8888.
`authentication.oidc.redirectURIHost`	Hôte à utiliser pour l'URI de terminaison OAuth. Si vous laissez ce champ vide, l'hôte de l'URL cible sera utilisé et l'URI de redirection sera assemblé de manière dynamique. Cette valeur peut être utilisée lorsqu'une session SSO d'authentification utilisateur est souhaitée pour un domaine de niveau supérieur. Par exemple, pour activer l'authentification unique (SSO) entre profile.example.com/ et admin.example.com/, cette valeur peut être définie sur example.com. Cela permettra d'établir une session d'authentification utilisateur sur example.com qui sera partagée entre tous les sous-domaines. Remarque : Si plusieurs domaines sont diffusés à partir du même maillage, example1.com et example2.com, la fonctionnalité ne peut pas être utilisée. Il est recommandé de laisser ce champ vide.
`authentication.oidc.redirectURIPath`	Chemin d'accès au point de terminaison où `authservice` met fin au flux OAuth. Vous devez enregistrer ce chemin d'URI plus l'hôte en tant qu'URI de redirection autorisé sur le serveur d'autorisation de `authentication.oidc.clientID`. En outre, cet URI doit être diffusé depuis le même maillage de services et la même entrée que ceux où `authservice` est activé.
`authentication.oidc.scopes`	Champ d'application OAuth qui doit être demandé dans la requête d'authentification. Liste d'identifiants séparés par des virgules utilisés pour spécifier les droits d'accès demandés en plus du champ d'application "openid", par exemple "groups,allatclaim".
`authentication.oidc.groupsClaim`	Si `idtoken` contient une revendication de groupes, utilisez ce champ pour indiquer son nom. Si spécifié, le service transmet les données de cette revendication à la revendication `groups` qui figure dans le jeton RCToken de sortie. Cette revendication doit contenir une liste de chaînes séparées par des virgules, par exemple ["group1", "group2"].
`authentication.oidc.attributeMapping`	Contient un ou plusieurs mappages de revendications à partir d'expressions CEL suivies par `idtoken`. Toutes les revendications doivent être référencées par `assertion.X`, `assertion` est référencé au jeton d'origine, par exemple `aud_copy: assertion.aud.`.
`authentication.outputJWTAudience`	Audience du jeton RCToken généré par `authservice`. Les side-cars peuvent valider le jeton RCToken entrant vis-à-vis de cette valeur d'audience.

Résoudre les problèmes

Accessibilité réseau aux IdP.

Journal possible : error: TLS handshake failed..

Vérifiez l'accessibilité en exécutant la commande curl du conteneur istio-proxy vers l'URI de l'émetteur IdP. Si la connexion ne fonctionne pas, l'utilisateur peut vérifier les règles de pare-feu ou d'autres configurations réseau pour le cluster.
Certificat émanant d'une autorité de certification racine

Journal possible : error: The server's TLS certificate did not match expectations. ou error: TLS handshake failed..

Assurez-vous que certificateAuthorityData contient le bon certificat CA racine. Lorsqu'aucun proxy HTTPS n'interrompt le trafic HTTPS, le certificat CA racine du fournisseur d'identité devrait être conservé. Dans le cas contraire, c'est celui du proxy qui devrait être conservé.
Configuration du chemin de redirection.

Observation possible : recevoir une page d'erreur 404 pendant le flux d'authentification OIDC.

L'authentification utilisateur renvoie l'en-tête "Set-Cookie" sans utiliser l'attribut de chemin. Par défaut, le navigateur utilise le répertoire de l'URL de la requête comme chemin de cookie (champ d'application du cookie associé au chemin). Nous vous recommandons donc de ne pas inclure "/" dans le chemin de redirection à moins d'en avoir besoin.
Le side-car ne peut pas récupérer jwksUri.

Dans certains cas, une restriction sidecar peut entraîner l'échec de la récupération de jwksUri. Si l'espace de noms n'est pas présent en utilisant un caractère générique (par exemple, ./* ou istio-system/*), cela ne fonctionnera pas. Vous devez ajouter manuellement l'espace de noms dans le side-car de sortie.

Questions fréquentes

Comment mettre à niveau Cloud Service Mesh avec l'authentification des utilisateurs activée ?

Suivez le processus de mise à niveau de Cloud Service Mesh et spécifiez le fichier de superposition en ajoutant --custom_overlay user-auth-overlay.yaml sur la ligne de commande asmcli install.
Quelle quantité de ressources devons-nous provisionner pour le authservice ? Et combien de requêtes par seconde peut-il gérer ?

Par défaut, authservice est configuré avec 2 processeurs virtuels et 256 Mio de mémoire. Dans une telle configuration, authservice peut gérer 500 requêtes par seconde. Pour gérer un plus grand nombre de requêtes, vous devez provisionner davantage de ressources processeur, ce qui est à peu près proportionnel à sa capacité de traitement des requêtes. Vous pouvez également configurer plusieurs instances dupliquées du authservice pour accroître l'évolutivité horizontale.