Red Hat Summit Red Hat SummitSupportConsoleDéveloppeursCommencer un essaiContact

2.3. Authentification de l’API

Les demandes à l’API dédiée OpenShift sont authentifiées en utilisant les méthodes suivantes:

Jetons d’accès OAuth
  • Obtenu à partir du serveur OpenShift Dedicated OAuth à l’aide des points de terminaison <namespace_route>/oauth/autorisation et <namespace_route>/oauth/token.
  • Envoyé en tant qu’autorisation: Bearer…​ en-tête.
  • Envoyé comme un en-tête de sous-protocole websocket dans le formulaire base64url.bearer.authorization.k8s.io.<base64url-encoded-token> pour les requêtes websocket.
Certificats de client x.509
  • Nécessite une connexion HTTPS au serveur API.
  • Vérifié par le serveur API par rapport à un ensemble d’autorités de certification de confiance.
  • Le serveur API crée et distribue des certificats aux contrôleurs pour s’authentifier.

Chaque demande avec un jeton d’accès invalide ou un certificat invalide est rejetée par le calque d’authentification avec une erreur 401.

En l’absence de jeton d’accès ou de certificat, la couche d’authentification attribue le système: utilisateur virtuel anonyme et le groupe virtuel système:non authentifié à la demande. Cela permet à la couche d’autorisation de déterminer quelles requêtes, le cas échéant, un utilisateur anonyme est autorisé à faire.

2.3.1. Le serveur OAuth dédié à OpenShift
Copier lien

Le maître dédié OpenShift inclut un serveur OAuth intégré. Les utilisateurs obtiennent des jetons d’accès OAuth pour s’authentifier à l’API.

Lorsqu’une personne demande un nouveau jeton OAuth, le serveur OAuth utilise le fournisseur d’identité configuré pour déterminer l’identité de la personne qui fait la demande.

Il détermine ensuite à quel utilisateur cette identité cartographie, crée un jeton d’accès pour cet utilisateur, et retourne le jeton pour utilisation.

2.3.1.1. Demandes de jetons OAuth
Copier lien

Chaque demande de jeton OAuth doit spécifier le client OAuth qui recevra et utilisera le jeton. Les clients OAuth suivants sont automatiquement créés lors du démarrage de l’API dédiée OpenShift:

Expand
Client OAuthL’utilisation

le client OpenShift-browser

Demande des jetons à <namespace_route>/oauth/token/request avec un agent utilisateur capable de gérer les connexions interactives. [1]

le client OpenShift-Challenging

Demandes de jetons avec un agent utilisateur capable de gérer les défis WWW-Authenticate.

  1. <namespace_route> fait référence à la route de l’espace de noms. Ceci est trouvé en exécutant la commande suivante: 

    $ oc get route oauth-openshift -n openshift-authentication -o json | jq .spec.host
    Copy to Clipboard Toggle word wrap

Les demandes de jetons OAuth impliquent une demande de <namespace_route>/oauth/autorisation. La plupart des intégrations d’authentification placent un proxy authentifiant devant ce point de terminaison, ou configurent OpenShift Dedicated pour valider les informations d’identification par rapport à un fournisseur d’identité de support. Les demandes de <namespace_route>/oauth/autorisation peuvent provenir d’agents utilisateurs qui ne peuvent pas afficher des pages de connexion interactives, telles que le CLI. Ainsi, OpenShift Dedicated prend en charge l’authentification à l’aide d’un défi WWW-Authenticate en plus des flux de connexion interactifs.

Lorsqu’un proxy authentifiant est placé devant le point de terminaison <namespace_route>/oauth/autoriser, il envoie des défis WWW-Authenticate non authentiques et non navigateurs, plutôt que d’afficher une page de connexion interactive ou de rediriger vers un flux de connexion interactif.

Note

Afin d’éviter les attaques de faux de requêtes intersites (CSRF) contre les clients du navigateur, n’envoyer des défis d’authentification de base que si un en-tête X-CSRF-Token est sur la demande. Les clients qui s’attendent à recevoir les défis de base WWW-Authenticate doivent définir cette en-tête à une valeur non vide.

Lorsque le proxy d’authentification ne peut pas prendre en charge les défis WWW-Authenticate, ou si OpenShift Dedicated est configuré pour utiliser un fournisseur d’identité qui ne prend pas en charge les défis WWW-Authenticate, vous devez utiliser un navigateur pour obtenir manuellement un jeton à partir de <namespace_route>/oauth/token/request.

Retour au début
Red Hat logoGithubredditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance. Découvrez nos récentes mises à jour.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez le Blog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

Theme

© 2025 Red Hat