2.3. Authentification de l'API
Les requêtes adressées à l'API OpenShift Container Platform sont authentifiées à l'aide des méthodes suivantes :
- Jetons d'accès OAuth
-
Obtenu à partir du serveur OAuth de OpenShift Container Platform à l'aide des paramètres
<namespace_route>/oauth/authorizeet<namespace_route>/oauth/token. -
Envoyé en tant qu'en-tête
Authorization: Bearer…. -
Envoyé en tant qu'en-tête du sous-protocole websocket sous la forme
base64url.bearer.authorization.k8s.io.<base64url-encoded-token>pour les requêtes websocket.
-
Obtenu à partir du serveur OAuth de OpenShift Container Platform à l'aide des paramètres
- Certificats clients X.509
- Nécessite une connexion HTTPS au serveur de l'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 qu'ils s'authentifient.
Toute demande comportant un jeton d'accès ou un certificat non valide est rejetée par la couche d'authentification avec une erreur 401.
Si aucun jeton d'accès ou certificat n'est présenté, la couche d'authentification attribue l'utilisateur virtuel system:anonymous et le groupe virtuel system:unauthenticated à la demande. Cela permet à la couche d'autorisation de déterminer quelles demandes, le cas échéant, un utilisateur anonyme est autorisé à faire.
2.3.1. Serveur OAuth de OpenShift Container Platform
Le master OpenShift Container Platform comprend un serveur OAuth intégré. Les utilisateurs obtiennent des jetons d'accès OAuth pour s'authentifier auprès de 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 correspond cette identité, crée un jeton d'accès pour cet utilisateur et renvoie le jeton pour utilisation.
2.3.1.1. Demandes de jetons OAuth
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 OpenShift Container Platform :
| Client OAuth | Utilisation |
|---|---|
|
|
Demande des jetons à |
|
|
Demande de jetons avec un user-agent qui peut gérer les défis |
<namespace_route>fait référence à la route de l'espace de noms. On le trouve en exécutant la commande suivante :$ oc get route oauth-openshift -n openshift-authentication -o json | jq .spec.host
Toutes les demandes de jetons OAuth impliquent une requête à <namespace_route>/oauth/authorize. La plupart des intégrations d'authentification placent un proxy d'authentification devant ce point de terminaison, ou configurent OpenShift Container Platform pour valider les informations d'identification par rapport à un fournisseur d'identité de soutien. Les demandes adressées à <namespace_route>/oauth/authorize peuvent provenir d'agents utilisateurs qui ne peuvent pas afficher de pages de connexion interactives, telles que la CLI. Par conséquent, OpenShift Container Platform prend en charge l'authentification à l'aide d'un défi WWW-Authenticate en plus des flux de connexion interactifs.
Si un proxy d'authentification est placé devant le point de terminaison <namespace_route>/oauth/authorize, il envoie aux agents utilisateurs non authentifiés, qui ne sont pas des navigateurs, des défis WWW-Authenticate au lieu d'afficher une page de connexion interactive ou de rediriger vers un flux de connexion interactif.
Pour éviter les attaques de type cross-site request forgery (CSRF) contre les clients des navigateurs, n'envoyez des défis d'authentification de base que si un en-tête X-CSRF-Token figure sur la demande. Les clients qui s'attendent à recevoir des défis Basic WWW-Authenticate doivent attribuer à cet en-tête une valeur non vide.
Si le proxy d'authentification ne prend pas en charge les défis WWW-Authenticate ou si OpenShift Container Platform 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.
2.3.1.2. L'usurpation d'identité de l'API
Vous pouvez configurer une requête à l'API OpenShift Container Platform pour qu'elle agisse comme si elle provenait d'un autre utilisateur. Pour plus d'informations, voir User impersonation dans la documentation Kubernetes.
2.3.1.3. Mesures d'authentification pour Prometheus
OpenShift Container Platform capture les métriques système Prometheus suivantes lors des tentatives d'authentification :
-
openshift_auth_basic_password_countcompte le nombre de tentatives de saisie du nom d'utilisateur et du mot de passe suroc login. -
openshift_auth_basic_password_count_resultcompte le nombre de tentatives d'utilisation du nom d'utilisateur et du mot de passeoc loginpar résultat,successouerror. -
openshift_auth_form_password_countcompte le nombre de tentatives de connexion à la console web. -
openshift_auth_form_password_count_resultcompte le nombre de tentatives de connexion à la console web par résultat,successouerror. -
openshift_auth_password_totalcompte le nombre total de tentatives de connexion àoc loginet à la console web.
