Kasm (VDI/DaaS/RBI) - Partie 2

Introduction

L’article précédent sur Kasm avait comme ambition d’introduire la solution et de présenter l’architecture de lab à mettre en œuvre. Si vous n’avez pas parcouru ce dernier, je vous invite à le faire avant de démarrer celui-ci.

Kasm est à présent installé sur une machine virtuelle Rocky Linux 9.6 exécutée sur un nœud XCP-ng.

Le serveur est déployé dans ma DMZ web afin de pouvoir être atteint depuis l’extérieur via l’URL https://kasm.coolcorp.fr.

Cette même URL est exposée via Traefik comme une ressource externe à mon cluster Kubernetes, Kasm étant totalement hors de mon infrastructure K8S. J’ai néanmoins expliqué dans mon premier article comment bénéficier des avantages de Traefik , notamment avec l’intégration de Cert-Manager pour l’automatisation des certificats, avec une application non présente sur Kubernetes.

Pour rappel également, cette URL en coolcorp.fr est destinée uniquement à l’accès externe.

En interne, je passe par l’URL https://kasm.coolcorp.priv, dont le certificat est lui associé à ma PKI Windows interne.

Cette URL interne est réservée à l’administration de Kasm.

Pour cela je peux utiliser le compte admin par défaut généré à l’installation de Kasm.

N’hésitez pas encore une fois à parcourir mon précédent article pour en apprendre davantage.

Configuration de Kasm

Mise en place de l'authentification OAuth2/OIDC avec Azure Entra ID

Partie Azure

Pour démarrer la suite du déploiement du lab, on va commencer par l’intégration de l’authentification sur la partie publique via Azure Entra ID et la combinaison OAUTH2 (gestion autorisation) et OIDC (OpenID Connect: gestion authentification).

Ceci pour tirer parti de l’annuaire cloud de Microsoft, lui-même synchronisé avec mon Active Directory interne.

Je ne vais pas rentrer dans le détail à ce niveau, mais c’est une logique d’authentification qu’on retrouve beaucoup en entreprise.

À noter qu’il n’est pas nécessaire d’avoir un annuaire interne, ce que nous allons voir maintenant est valable également pour des architectures basées uniquement sur Azure Entra ID.

Le fonctionnement consiste à déclarer une apps dans son tenant Azure pour laquelle on va générer un secret. Ce secret ainsi que l’ID de notre application seront configurés dans Kasm, qui pourra, par ce biais, solliciter l’application Azure créée dans Azure Entra ID et relayer l’authentification utilisateur à ce dernier. Si l’authentification réussit, un token de session contenant des informations sur l’utilisateur validé est renvoyé à Kasm. Ce dernier pourra ensuite proposer les différentes ressources accessibles à ce user.

L’avantage de ce type de méthode est d’exploiter des mécanismes d’authentification moderne, qui peut en plus bénéficier des protections de Azure Entra ID comme les règles d’accès conditionnel et la mise en place de bonne pratique de sécurité (imposer l’usage du MFA (Mutiple Factor Authentication)).

Dans mon cas, n’ayant qu’un compte gratuit, je n’ai pas accès aux règles d’accès conditionnel, mais il m’est possible d’activer le MFA sans pour autant pouvoir paramétrer son comportement ; MS se laissant le droit d’identifier ou non le besoin du MFA en fonction de l’emplacement de connexion. C’est une des limitations de la version gratuite de Azure Entra ID, mais on peut néanmoins se former sur son usage et mettre en place les prérequis nécessaires.

On se dirige donc vers sa console d'administation Azure Entra ID de son tenant Azure.

À ce niveau on se place dans App Registration.

Puis on crée son application, nommée ici pour l’exemple « app-coolcorp-kasm ». Je vous invite d’ailleurs à suivre une nomenclature précise pour vos apps d’authentification.

J'autorise l’usage de cette application uniquement à des users de mon tenant via l’option par défaut.

Mon application est de type web, et la page de redirection va être celle de mon exposition publique de kasm complétée par l’arborescence api faisant référence à oidc pour le callback.

Soit: https://kasm.coolcorp.fr/api/oidc_callback.

Une fois l’application en place, on obtient plusieurs éléments qu’il va être nécessaire de mettre de côté.

• L’application ID: c’est ce qui référence l’application nouvellement créée coté MS
• Directory ID: c’est l’ID du tenant Azure dans lequel est enregistrée l’application (dans l’exemple, mon tenant)

Ce n’est pas suffisant pour permettre à Kasm de solliciter l’apps pour y déléguer l’authentification.

Pour terminer, il faut créer un secret dans le menu de l’apps Certificates & Secret.

On génère un nouveau secret.

On configure une date d’expiration pour ce dernier, idéalement pour des questions de sécurité, il est préférable de ne pas dépasser 6 mois, voire 3 mois pour des éléments critiques.

Comme il s’agit d’un lab, je vais me permettre d’être un peu plus laxiste et passé à 12 mois.

On obtient ensuite une valeur de secret: cette dernière est bien évidemment critique et sensible. Elle doit être sauvegardée dans un emplacement sécurisé. À noter qu’il ne vous sera plus possible de la faire apparaitre une fois montrée une première fois. Si elle est perdue, il faudra regénérer un nouveau secret.

Attention, le secret ID n’est pas la valeur du secret.

Pour terminer cette partie "enregistrement de l’application", il faut passer par l’option API Permission.

À ce niveau il va falloir ajouter des autorisations pour permettre à l’application d’accéder à des attributs supplémentaires associés à l’utilisateur, afin de fournir ces éléments dans le token qui sera fourni à Kasm.

Pour cela, on ajoute la permission email, openid, profile en plus de User.read, qui devrait déjà être présente.

Il ne faut pas oublier de cliquer sur Grant admin consent for default directory pour valider ces autorisations.

Une fois l’enregistrement de l’application terminé, on peut revenir au menu principal d’Azure Entra pour basculer sur l’option All Application et choisir l’application nouvellement créée.

Le but est d’assigner un nombre restreint d’utilisateurs pouvant être authentifiés via cette application.

Pour ma part, je vais simplement ajouter mon utilisateur synchronisé depuis mon AD locale.

Avant de fermer la console Azure, vérifiez au niveau global de votre tenant, dans la section Security, que l’option Your organization is protected by security default est activée. Dans un tenant gratuit, cela garantit un minimum de sécurité en laissant Microsoft gérer la politique d’authentification, notamment l’usage du MFA.

Pour ceux qui dispose d’un tenant payant, les options sont bien plus avancées à ce niveau, et je vous encourage fortement à mettre en place des règles d’accès conditionnels associées à l’application (restriction sur les devices à utiliser, sur les zones géographiques de connexion…).

C’est terminé pour Azure.

Partie Kasm

Il va falloir maintenant traiter la partie Kasm pour y déclarer cette délégation d’authentification.

Pour cela, on exploite l’URL interne (dans mon cas, https://kasm.coolcorp.priv) pour s’authentifier avec le compte administrateur (pour plus de détails, voir mon premier article).

Dans la partie Access Management, on clique sur Authentication, puis sur OpenID.

Puis sur Add Config.

On déclare une configuration Azure Entra.

Si vous activez « Auto Login », votre user sera automatiquement redirigé vers la mire d’authentification Azure Entra ID s’il accède à vote plateforme Kasm via le hostname que vous indiquez juste en dessous. (Dans mon cas kasm.coolcorp.fr).

En entreprise, cela peut être pratique si l’utilisateur s’est déjà authentifié sur Azure Entra avec un compte de l’annuaire d’entreprise. S’il accède à Kasm, il bénéficiera du SSO pour directement accéder aux ressources publiées.

Après cela, vous devez entrer les données récupérées à partir de l’application déclarée précédemment, c’est-à-dire l'ID Client et le Secret.

Quant à l’Autorisation url et la Token url, elles sont composées de la manière suivante:

• https://login.microsoftonline.com/$id_tenant/oauth2/v2.0/authorize
• https://login.microsoftonline.com/$id_tenant/oauth2/v2.0/token

Pour la partie User Info Url, il faut saisir cette URL:

https://graph.microsoft.com/oidc/userinfo

Dans le champ scope, on spécifie les informations sur l’utilisateur que l’on souhaite récupérer dans le jeton d’authentification correspondant aux autorisations qu'on a ajouté dans l'apps azure. En l’occurrence:

• L’openid
• L’email
• Le profil
• Le champ user read

Comme attribute de login, dans username attribute on retient l’email de l’utilisateur.

Dans ma configuration exemple, je n’utilise pas de notion de groupe.

L’option redirect URL doit correspondre à ce qui a été mis dans ce même champ au niveau de l’apps azure, soit dans mon cas:

https://kasm.coolcorp.fr/api/oidc_callback

On peut cliquer sur save pour enregistrer la configuration.

Si la délégation d’authentification est en place, afin que Kasm puisse exploiter Azure Entra ID comme source de confiance, l’utilisateur, bien que présent coté Azure Entra n’est pas encore dans la base de Kasm.

Pour cela il faut se rendre dans Acces Management, puis sur Users pour créer ce dernier.

On indique qu’il est rattaché au profil d'authentification OIDC qu'on a créé et surtout on utilise comme Username son adresse email. Ceci pour faire correspondre au choix qui a été fait du côté du paramétrage OpenID réalisé juste avant.

Maintenant que la partie connexion publique est traitée, il est temps de déclarer des ressources afin que Kasm puisse les exposer à l’utilisateur une fois connecté.

Configuration des ressouces à exposer

Exposition W11 physique via RDP

La première ressource que je vais vouloir proposer dans mon cas est l’accès à mon PC fixe sous W11 via une connexion RDP.

On commence par se rendre dans l’option Infrastructure, puis sur Server pour cliquer sur Add.

On précise le protocole à utiliser, soit dans mon cas RDP.

On indique l’adresse IP ou le hostname de la cible à atteindre. (Attention aux ouvertures de flux réseau dans le cas de firewall intermédiaire).

Pour le reste, je laisse les options par défaut, jusqu’à arriver au paramètre Kasm Desktop Service Installed que je vais activer afin de récupérer un Registration Token.

En effet, pour rendre l’expérience plus efficace, je vais déployer sur mon poste fixe l’agent Kasm. Ce n’est pas une obligation, mais sa présence va permettre une interaction plus avancée, comme l’upload de fichier et d’autres avantages intéressants.

L’agent est disponible sur le site de kasm.

On récupère la version propre à son OS, puis on lance l’installation.

Une fois arrivé à la fin de l’assistant, on remplit les informations demandées pour la configuration de l’agent.

Soit l’URL de l’API de KASM, dans mon cas, l’accès interne, soit kasm.coolcorp.priv.

C’est à ce niveau que je renseigne le token récupéré précédemment dans la console d’administration de Kasm.

Attention, le serveur Kasm doit pouvoir se connecter à l’agent sur le port TCP 4902, il faut que l’accès soit ouvert pour que l’enregistrement de l’agent fonctionne. Dans mon cas, j’ai dû créer une règle sur mon firewall OPNsense (n’hésitez pas à lire l’introduction à Kasm ou j’explique où j’ai situé mon serveur et le détail sur la partie réseau associée).

Si tout va bien, vous devriez avoir la fenêtre suivante:

Du coté de Kasm, vous devriez avoir ce résultat.

La ressource « RDP » pour mon PC fixe étant créée dans Kasm, je dois maintenant la proposer dans un Workspace.

C’est le principe de base de Kasm; on crée des ressources à exposer de différents types, puis on les associe à des workspaces, qu’on va pouvoir proposer à un utilisateur ou un groupe d’utilisateurs.

On se rend donc dans la partie Workspace du menu d’administration de Kasm.

On clique sur Add Workspace.

On spécifie le type de Workspace, en l’occurrence un workspace Server, on lui donne un nom parlant, par exemple pour moi, comme il s’agit de l’accès à mon PC fixe, j’indique le nom de ce dernier en précisant qu’il s’agit d’un accès RDP.

Je précise également une petite description.

Et je sélectionne la ressource que j’ai créée juste avant.

Je peux ajouter une icône au format svg si besoin pour une meilleure illustration du workspace.

Exposition Linux VM via ssh (accès api KUB)

La seconde ressource que je vais vouloir exposer est un accès à mon cluster Kubernetes.

Pour cela, on va à nouveau se rendre dans la section Server pour créer une nouvelle ressource.

Cette fois-ci je vais donner le nom de l’API de mon cluster Kubernetes.

Ce n’est plus RDP que je vais utiliser, mais SSH.

Je vais faire pointer la ressource vers l’IP de mon premier control plane en retenant l’option de static Credentials.

Je dois donc indiquer le login de connexion, soit pour moi « admink8s », qui est un utilisateur existant sur mon nœud control plane K8S (voir mon cookbook kubernetes).

Je ne vais pas rentrer dans le détail sur cette partie, mais l’idée est d’avoir au préalable créé une clef SSH directement sur mon node K8S pour ce user, via la commande:

ssh-keygen -t ed25519 -a 100 -C "kasm@admink8s"

J’ai indiqué un password de protection associé à la clef privée, puis j’ai récupéré la valeur de cette dernière pour la renseigner (ainsi que son mot de passe) dans l’interface de Kasm au niveau de ma ressource.

Cette manipulation a pour but de mettre en avant le fait qu’on puisse également utiliser Kasm comme une sorte de bastion.

L’utilisateur final peut facilement accéder à un contenu SSH via Kasm sans avoir à saisir de détails de connexion, car ces informations sont directement intégrées dans les paramètres de la ressource publiée.

Dans mon exemple, je pourrais accéder directement à mon nœud Kubernetes en tant qu’utilisateur admink8s sans avoir besoin de connaitre ses détails d’authentification.

Comme pour mon server RDP, je vais créer ensuite un workspace de type Server, mais cette fois-ci en y faisant référence à ma connexion SSH pointant vers mon premier control plane.

Ici aussi, je peux mettre un logo au besoin pour différentier davantage mon workspace.

Exposition Instance Chrome éphémère

Avant de tester le tout, je vais créer un dernier workspace. Sans doute le plus intéressant pour une configuration Kasm.

Ce workspace ne va pas être de type Server comme les deux autres, mais Container.

Je n’ai pas eu à créer de composant serveur dédié à Docker avant, car, étant sur une installation Kasm monoserveur, celui-ci fait déjà office par défaut d’agent Docker. Ce qui implique que c’est le serveur Kasm lui-même qui va exécuter les conteneurs que je pourrais être amené à déployer et à exposer. C’est important à noter.

D’ailleurs on peut le voir dans le menu Infrastructure.

Si on revient à mon workspace Container, je vais dédier celui-ci à l’exécution d’un navigateur Chrome.

Il va s’agir de pouvoir lancer un browser éphémère, isolé du reste. Ça peut s’avérer extrêmement pratique pour différents besoins, comme accéder temporairement à une ressource web qui serait elle-même bloquée depuis son lieu de connexion (webmailpar par exemple). On peut aussi vouloir tester l’accès à une URL dont la légitimité fait douter et s’assurer qu’on y accède via un environnement maîtrisé ou depuis une sandbox.

Dans le cas de ce workspace, l’idée est d’avoir, à la demande, le lancement d’un conteneur disposant d'une version de chrome pilotable via un streaming de flux, faire ce qu’on a faire et, une fois la session terminée, détruire le conteneur.

.

Pour ce besoin, Kasm est livré avec un accès à un registre spécifique maintenu par l'entreprise derriere Kasm et qui contient déjà plusieurs images Docker prêtes à l’emploi.

Il suffit de sélectionner l’image dont on a besoin, par exemple pour moi Chrome, pour l’associer à son workspace.

Toutes les options qui suivent permettent de paramétrer le conteneur, notamment les ressources qui vont être rattachées à ce dernier.

Je laisse ici les options par défaut.

Test des accès et observations

Si je reviens à la liste de mes Workspaces, j’en ai désormais trois de disponibles.

Deux de type Server: l’un pour l’accès RDP à ma machine physique et l’autre avec un accès SSH pour l’accès à mon premier control plane Kubernetes.

Le troisième workspacede type Container est celui qu’on vient de créer, dédié à l’exécution d’une instance Chrome éphémère.

Pour ceux qui se demanderaient quelles autres images sont disponibles. Il suffit de cliquer sur Registry.

Le choix est déjà très large.

À savoir qu’il est possible de déclarer votre propre registry pour y présenter vos images custom (sous conditions d'y intégrer certaines spécificités pour un usage avec Kasm).

Autre fait intéressant à savoir, dans une installation multinœud (voir le premier article), vous pouvez disposer de plusieurs proxy docker, voir Kubernetes directement pour pouvoir paramétrer des pools dédiés à l’exécution de vos conteneurs.

Il est ainsi possible de construire toute une architecture dédiée au provisionnement de différentes ressources en fonction des besoins exprimées.

Avec bien étendu, la capacité de proposer des accès différents et des ressources différentes par utilisateurs ou groupe d’utilisateurs.

Par exemple, dans mon cas, mon compte se trouve dans le groupe All Users.

J’ai donné accès à ce groupe à mes trois workspaces.

Je devrais donc pouvoir accéder, via cet utilisateur, à l’ensemble des ressources que j’ai créées, ceci depuis l’extérieur avec un simple navigateur Web pointant vers https://kasm.coolcorp.fr.

C’est d’ailleurs ce que je vais tester tout de suite.

Le fait de taper https://kasm.coolcorp.fr me redirige immédiatement vers la mire d’authentification Azure Entra (puis que j’ai activé l’option Auto Login).

Une fois connecté, Azure me renvoie vers Kasm et j’ai le plaisir d’y voir mes Workspaces.

Je peux accéder à chacun d’entre eux sans difficulté.

Que ce soit pour accéder à mon PC fixe via RDP,

à mon API Kub grâce à l’accès SSH,

ou au lancement d’une instance Chrome éphémère.

La magie est que tout se fait à travers une simple connexion internet et un navigateur web. Sans autre consultation que des pages HTTPS.

Le streaming du conteneur est une des spécificités de Kasm. Pour rappel, un conteneur n’a pas d’interface graphique, mais les images proposées par Kasm inclus un serveur de rendu, comme X11, Xvfb ou TurboVNC.

Ce serveur intégré à l’image va pouvoir fournir un canal de streaming via des protocoles comme noVNC ou d’autres références basées sur WebRTC pour afficher dans le navigateur de l’utilisateur l’interface graphique de l’application conteneurisée et interagir avec cette dernière.

Kasm sert donc de « passerelle » en diffusant l’affichage vers le navigateur client.

Voici un schéma simplifié:

Pour en revenir à l’expérience utilisateur, une fois connecté sur le menu d’accueil, je retrouve toutes mes sessions actives et je peux basculer de l’une à l’autre pour reprendre mon travail ou décider de fermer celles qui me sont devenues inutiles.

Par exemple, si je supprime ma session Chrome, le conteneur sous-jacent est détruit, et tout est effacé de ma navigation.

Côté interface d’administration (via l’URL https://kasm.coolcorp.priv), on peut suivre tout ce qui se passe sur la plateforme.

Avec le listing et le détail de toutes les sessions ouvertes.

On dispose également d’un suivi des consommations en termes de ressources des composants.

C’est vraiment très complet et très utile.

Côté user, je peux décider de mettre fin à toutes mes sessions d’un seul coup.

Conclusion

Nous voilà arrivés à la fin de la découverte de Kasm, à travers deux articles dédiés. Pour moi c’est clairement une superbe exploration et une plateforme très intéressante.

Pour répondre à ma question de base posée lors du premier article, à savoir est-ce que Kasm peut se montrer être une alternative à VMware Horizon…je vais faire une réponse de Normand: ça dépend.

Cela sera conditionné par les usages recherchés. Dans sa version gratuite, Kasm ne va pas pouvoir provisionner automatiquement des VMs sur un vCenter pour ensuite les mettre à disposition d’utilisateurs.

Mais il sera néanmoins possible via d’autres mécanismes, notamment avec la publication RDP et SSH de pouvoir donner des accès à des environnements de travail déjà en place.

Cependant, la version premium de Kasm propose VMware vSphere AutoScale, qui semble capable de gérer ces cas d’utilisation de VDI à la demande.

La publication d’application est aussi possible via une approche différente d’acteurs comme Citrix, mais cela reste parfaitement réalisable via la capacité de Kasm de streamer du contenu conteneurisé, sachant qu’il est possible de persister la donnée, même si ce n’est pas le comportement par défaut.

En tout cas, il est certain que je vais continuer à utiliser cette plateforme dans mon lab et à développer mes compétences sur celle-ci, car je la trouve extrêmement pertinente sur le marché IT et très utile pour de nombreuses situations.