Après avoir installé OpenShift Container Platform, vous pouvez développer et personnaliser votre cluster en fonction de vos besoins, notamment en prenant des mesures pour préparer les utilisateurs.
10.1. Comprendre la configuration du fournisseur d'identité
Le plan de contrôle d'OpenShift Container Platform comprend un serveur OAuth intégré. Les développeurs et les administrateurs obtiennent des jetons d'accès OAuth pour s'authentifier auprès de l'API.
En tant qu'administrateur, vous pouvez configurer OAuth pour qu'il spécifie un fournisseur d'identité après l'installation de votre cluster.
10.1.1. À propos des fournisseurs d'identité dans OpenShift Container Platform
Par défaut, seul un utilisateur kubeadmin existe sur votre cluster. Pour spécifier un fournisseur d'identité, vous devez créer une ressource personnalisée (CR) qui décrit ce fournisseur d'identité et l'ajouter au cluster.
Les noms d'utilisateur OpenShift Container Platform contenant /, :, et % ne sont pas pris en charge.
10.1.2. Fournisseurs d'identité pris en charge
Vous pouvez configurer les types de fournisseurs d'identité suivants :
| Fournisseur d'identité | Description |
|---|
|
htpasswd
|
Configurer le fournisseur d'identité htpasswd pour qu'il valide les noms d'utilisateur et les mots de passe par rapport à un fichier plat généré à l'aide de htpasswd.
|
|
Keystone
|
Configurez le fournisseur d'identité keystone pour intégrer votre cluster OpenShift Container Platform avec Keystone afin d'activer l'authentification partagée avec un serveur OpenStack Keystone v3 configuré pour stocker les utilisateurs dans une base de données interne.
|
|
LDAP
|
Configurer le fournisseur d'identité ldap pour valider les noms d'utilisateur et les mots de passe par rapport à un serveur LDAPv3, en utilisant l'authentification par liaison simple.
|
|
Authentification de base
|
Configurer un fournisseur d'identité basic-authentication pour que les utilisateurs puissent se connecter à OpenShift Container Platform avec des informations d'identification validées par rapport à un fournisseur d'identité distant. L'authentification de base est un mécanisme générique d'intégration du backend.
|
|
En-tête de la demande
|
Configurez un fournisseur d'identité request-header pour identifier les utilisateurs à partir des valeurs d'en-tête des requêtes, telles que X-Remote-User. Il est généralement utilisé en combinaison avec un proxy d'authentification, qui définit la valeur de l'en-tête de la requête.
|
|
GitHub ou GitHub Enterprise
|
Configurez un fournisseur d'identité github pour valider les noms d'utilisateur et les mots de passe par rapport au serveur d'authentification OAuth de GitHub ou de GitHub Enterprise.
|
|
GitLab
|
Configurer un fournisseur d'identité gitlab pour utiliser GitLab.com ou toute autre instance GitLab comme fournisseur d'identité.
|
|
Google
|
Configurer un fournisseur d'identité google en utilisant l 'intégration OpenID Connect de Google.
|
|
OpenID Connect
|
Configurer un fournisseur d'identité oidc pour l'intégrer à un fournisseur d'identité OpenID Connect à l'aide d'un flux de code d'autorisation.
|
Après avoir défini un fournisseur d'identité, vous pouvez utiliser RBAC pour définir et appliquer des autorisations.
10.1.3. Paramètres du fournisseur d'identité
Les paramètres suivants sont communs à tous les fournisseurs d'identité :
| Paramètres | Description |
|---|
|
name
|
Le nom du fournisseur est préfixé aux noms des utilisateurs du fournisseur pour former un nom d'identité.
|
|
mappingMethod
|
Définit la manière dont les nouvelles identités sont associées aux utilisateurs lorsqu'ils se connectent. Entrez l'une des valeurs suivantes :
- demande
-
Valeur par défaut. Fournit un utilisateur avec le nom d'utilisateur préféré de l'identité. L'opération échoue si un utilisateur portant ce nom est déjà associé à une autre identité.
- consultation
-
Recherche une identité existante, un mappage d'identité d'utilisateur et un utilisateur, mais ne provisionne pas automatiquement les utilisateurs ou les identités. Cela permet aux administrateurs de clusters de configurer les identités et les utilisateurs manuellement ou à l'aide d'un processus externe. L'utilisation de cette méthode nécessite le provisionnement manuel des utilisateurs.
- générer
-
Fournit à un utilisateur le nom d'utilisateur préféré de l'identité. Si un utilisateur ayant le nom d'utilisateur préféré est déjà associé à une identité existante, un nom d'utilisateur unique est généré. Par exemple,
myuser2. Cette méthode ne doit pas être utilisée en combinaison avec des processus externes qui nécessitent des correspondances exactes entre les noms d'utilisateur de OpenShift Container Platform et les noms d'utilisateur du fournisseur d'identité, tels que la synchronisation de groupe LDAP.
- ajouter
-
Fournit à un utilisateur le nom d'utilisateur préféré de l'identité. S'il existe déjà un utilisateur avec ce nom d'utilisateur, l'identité est associée à l'utilisateur existant, en s'ajoutant à toutes les associations d'identités existantes pour l'utilisateur. Nécessaire lorsque plusieurs fournisseurs d'identité sont configurés pour identifier le même ensemble d'utilisateurs et correspondre aux mêmes noms d'utilisateur.
|
Lorsque vous ajoutez ou modifiez des fournisseurs d'identité, vous pouvez faire correspondre les identités du nouveau fournisseur aux utilisateurs existants en définissant le paramètre mappingMethod sur add.
10.1.4. Exemple de CR de fournisseur d'identité
La ressource personnalisée (CR) suivante montre les paramètres et les valeurs par défaut que vous utilisez pour configurer un fournisseur d'identité. Cet exemple utilise le fournisseur d'identité htpasswd.
- 1
Ce nom de fournisseur est préfixé aux noms d'utilisateurs du fournisseur pour former un nom d'identité.
- 2
Contrôle la manière dont les correspondances sont établies entre les identités de ce fournisseur et les objets User.
- 3
Un secret existant contenant un fichier généré à l'aide de
htpasswd.
