Python, Viya, OpenShift : l'accès binaire à CAS expliqué

Une fois n'est pas coutume (vous pouvez retrouver l'ensemble de mes articles sur VIYA 4 sur ce blog), je vous propose ce article qui fournit un guide exhaustif et détaillé, étape par étape, pour la configuration et l'utilisation d'une connexion binaire depuis un client Python externe vers un serveur SAS Viya 4 CAS hébergé sur OpenShift. Elle est pas belle la vie ? J'ai profité de la canicule du moment pour vous proposer un article qui aborde le cycle de vie complet de la tâche, depuis la sécurité et la mise en réseau au niveau de la plateforme jusqu'à l'implémentation du code côté client.

Le Défi

Oui, c'est un défi (si,si..) SAS Viya sur OpenShift est une combinaison puissante, mais l'intégration de clients externes nécessite de naviguer dans les modèles de sécurité et de réseau distincts des deux technologies. Les informations sont souvent fragmentées entre la documentation SAS, les blogs Red Hat et les forums communautaires. Ce article synthétise ces sources (Merci Nicolas ! une fois de plus je suis là pour vous faciliter la vie) . L'enjeu principal n'est pas de corriger une fonctionnalité défaillante, mais de percer délibérément et en toute sécurité plusieurs couches d'isolation (conteneur, pod, réseau) qui sont conçues pour maintenir la plateforme autonome par défaut. Je sais, dit comme ça, ça peut faire peut mais ne vous inquiétez pas, ça va bien se passer.

Public Cible et Prérequis

Cet article est destiné aux administrateurs OpenShift, aux administrateurs de la plateforme SAS et aux data scientists ayant des responsabilités administratives ou de développement. Une connaissance pratique des concepts de Kubernetes/OpenShift (tels que les pods, services, SCCs, et la CLI kubectl/oc) ainsi que du langage Python est supposée. Vous vous sentez perdu ? vous pouvez parcourir mes articles ( nombreux) sur Viya 4, ou me contactez pour un coup de main ;) Vous pouvez m'envoyer un message sur Linkedin, je vous répondrai sans problème : https://www.linkedin.com/in/houssetnicolas/

Technologies Clés

SAS Viya 4 : La plateforme d'analytique entièrement conteneurisée et native pour le cloud.
Red Hat OpenShift : La plateforme Kubernetes d'entreprise qui fournit l'environnement d'exécution.
SAS Cloud Analytic Services (CAS) : Le moteur d'analyse distribué et en mémoire, au cœur de Viya.
Bibliothèque Python swat : Le SAS Scripting Wrapper for Analytics Transfer, le client Python officiel pour CAS.

Enfin, un dernier conseil avant de se lancer, CONSULTEZ LA DOCUMENTATION SAS : Configure External Access to CAS

Cet article se base sur cette documentation et sur d'autres sources afin d'enrichir ce guide, mais n'oubliez pas que je ne remplace pas ( et jamais) la documentation officielle et, en cas de doute, n'hésitez pas à contacter le support SAS.

Comprendre l'Interaction des Composants

Ce premier "chapitre" établit le modèle conceptuel sur la manière dont les différentes pièces du "puzzle" s'assemblent, ce qui est crucial avant toute tentative de configuration.

Le Rôle Central de CAS

CAS est le cœur de la puissance analytique de SAS Viya, conçu pour le traitement de données en mémoire à haute performance. Il représente une charge de travail stateful avec des exigences uniques en matière de ressources et de sécurité, se distinguant de la majorité des microservices stateless de la plateforme.

Modes de Déploiement : SMP vs. MPP

L'architecture de déploiement de CAS a des implications significatives sur les ressources et la configuration réseau.

Symmetric Multi-Processing (SMP) : Un unique pod de serveur CAS, adapté aux charges de travail plus petites ou à des cas d'utilisation spécifiques. Dans cette configuration, le serveur agit comme son propre contrôleur.
Massively Parallel Processing (MPP) : Un serveur distribué avec un pod contrôleur et plusieurs pods workers, permettant un calcul massivement parallèle sur plusieurs nœuds. Cette architecture est la plus courante pour les déploiements à grande échelle et impose des exigences élevées en matière de CPU, de mémoire et de stockage persistant performant, accessible par tous les nœuds hébergeant les pods CAS.

Le Contrôleur CAS

Le contrôleur CAS est le cerveau du serveur. Toutes les connexions clientes, qu'elles soient binaires ou REST, sont établies avec le pod contrôleur. Ce dernier orchestre ensuite le travail entre les pods workers dans une configuration MPP. L'ensemble de notre effort de configuration vise à rendre ce contrôleur accessible de manière sécurisée depuis l'extérieur du cluster.

L'Architecture de SAS Viya sur OpenShift

SAS Viya n'est pas un monolithe ; c'est une suite d'applications conteneurisées et de microservices déployés sur Kubernetes. La migration vers OpenShift confère à Viya une scalabilité sans précédent par rapport aux versions antérieures.

Ségrégation des Charges de Travail et Pools de Nœuds

SAS et Red Hat recommandent fortement une architecture de référence où différents types de charges de travail Viya sont assignés à des pools de machines (node pools) OpenShift dédiés. Cette approche garantit que les charges de travail CAS, intensives en ressources, n'interfèrent pas avec les applications web stateless ou les services de calcul. Par exemple, un pool de nœuds sera dédié à CAS, un autre aux services de calcul, et un troisième aux microservices. Ce choix architectural influence directement les configurations de réseau, de stockage et de sécurité.

Un Déploiement en "Sport d'Équipe"

La complexité de la pile logicielle signifie que le déploiement et la maintenance nécessitent une collaboration étroite entre plusieurs rôles : les administrateurs d'infrastructure (matériel/virtualisation), les administrateurs OpenShift (gestion du cluster) et les administrateurs SAS (déploiement du logiciel Viya). Ce rapport délimitera les tâches par rôle pour clarifier les responsabilités.

Le Chemin de Communication Client-Serveur

La conception d'OpenShift privilégie intrinsèquement l'isolement des charges de travail au sein d'un réseau privé et sécurisé. Le déploiement par défaut de SAS Viya s'aligne sur ce principe, avec toutes les communications inter-services se produisant à l'intérieur du cluster. La demande de l'utilisateur, qui est de se connecter depuis l'extérieur, constitue une exception à ce modèle opérationnel par défaut.

Communication Intra-Cluster vs. Externe

Par défaut, les services Viya communiquent entre eux à l'intérieur du réseau défini par logiciel (SDN) d'OpenShift. Les pods peuvent s'atteindre via les noms de service Kubernetes internes (par exemple,
sas-cas-server-default-bin). Ces noms ne sont pas résolubles depuis l'extérieur du cluster.

Le Défi de l'Accès Externe

Le script Python de l'utilisateur est un client externe. Il réside en dehors de la frontière réseau du cluster. Par conséquent, un chemin réseau doit être explicitement créé pour relier le réseau externe au réseau interne du cluster. L'exposition du port binaire de CAS doit être traitée comme une décision architecturale majeure avec des ramifications de sécurité, et non comme un simple exercice de redirection de port.

L'exposition du port binaire de CAS doit être traitée comme une décision architecturale majeure avec des ramifications de sécurité, et non comme un simple exercice de redirection de port.

Flux Réseau de Haut Niveau

Client Python : S'exécute sur un ordinateur portable ou un serveur externe.
Pare-feu Externe / Groupe de Sécurité Réseau : Doit autoriser le trafic vers le point d'entrée du cluster.
Point d'Entrée du Cluster OpenShift : Typiquement une adresse IP de Load Balancer ou l'IP publique d'un nœud.
Service Kubernetes : Un service de type NodePort ou LoadBalancer qui reçoit le trafic externe.
Pod Contrôleur CAS : La destination finale du trafic, s'exécutant à l'intérieur du cluster.

Préparation du Cluster OpenShift pour l'Accès Externe à CAS

Ce chapitre fournit les procédures détaillées, basées sur la ligne de commande, pour l'administrateur OpenShift. Ces actions nécessitent des privilèges d'administrateur de cluster (cluster-admin).

Contraintes de Contexte de Sécurité (SCCs) : Accorder les Privilèges Nécessaires à CAS

OpenShift applique par défaut une politique de sécurité très stricte via la SCC restricted. Cependant, le serveur CAS a besoin de capacités spécifiques au niveau de l'hôte pour fonctionner correctement, notamment pour gérer les sessions utilisateur et la propriété des fichiers, ce que la SCC restricted interdit. Pour gérer cette situation, SAS fournit des SCCs personnalisés qui accordent ces privilèges nécessaires mais élevés.

J'ai abordé le sujet des SCC à de nombreuses reprises sur mon blog, n'hésitez pas à lire mes articles sur le sujet : Comprendre les SCC Openshift pour Viya 4.

Choix de la SCC Appropriée

L'administrateur doit choisir et appliquer l'une des SCCs suivantes, fournies dans les actifs de déploiement SAS :

cas-server-scc : La SCC minimale requise. Elle permet au serveur CAS de s'exécuter en tant qu'utilisateur non-root spécifique (par exemple, UID/GID 1001/1001) mais accorde des capacités telles que SETUID, SETGID et CHOWN à un processus racine interne (launchsvcs) qui gère les sessions.
cas-server-scc-host-launch : À utiliser lorsque les sessions CAS doivent s'exécuter sous l'identité réelle de l'hôte de l'utilisateur qui se connecte. Cela a des implications significatives en matière de sécurité et d'accès aux données et constitue une configuration plus privilégiée.
cas-server-scc-sssd : Une version spécialisée pour les environnements intégrés avec SSSD pour l'authentification.

Le tableau suivant résume les choix pour aider l'administrateur.

Nom de la SCC	Cas d'Utilisation / Objectif	Capacités Clés Accordées	Commande d'Application (`kubectl`)	Commande de Liaison (`oc`)
`cas-server-scc`	Opération standard (recommandée). Les sessions s'exécutent sous l'identité du service CAS.	`SETUID`, `SETGID`, `CHOWN`	`kubectl apply -f sas-bases/examples/cas/configure/cas-server-scc.yaml`	`oc -n <namespace> adm policy add-scc-to-user sas-cas-server -z sas-cas-server`
`cas-server-scc-host-launch`	Lancement en tant qu'hôte. Les sessions s'exécutent sous l'identité de l'utilisateur connecté. Nécessaire pour l'accès aux fichiers basés sur les permissions de l'utilisateur hôte.	`SETUID`, `SETGID`, `CHOWN`	`kubectl apply -f sas-bases/examples/cas/configure/cas-server-scc-host-launch.yaml`	`oc -n <namespace> adm policy add-scc-to-user sas-cas-server-host -z sas-cas-server`
`cas-server-scc-sssd`	Intégration SSSD. Utilisé lorsque CAS est configuré pour s'intégrer avec un SSSD personnalisé.	`SETGID`, `SETUID`, `CHOWN`	`kubectl apply -f sas-bases/examples/cas/configure/cas-server-scc-sssd.yaml`	`oc -n <namespace> adm policy add-scc-to-user sas-cas-server-sssd -z sas-cas-server`

Étapes

Appliquer le YAML de la SCC : L'administrateur doit appliquer la définition de la SCC choisie à partir des actifs de déploiement SAS.

oc apply -f sas-bases/examples/cas/configure/cas-server-scc.yaml

Lier la SCC au Compte de Service : La SCC appliquée doit être liée au compte de service sas-cas-server, qui est l'identité sous laquelle les pods CAS s'exécutent

oc -n name-of-namespace adm policy add-scc-to-user sas-cas-server -z sas-cas-server

Source : Preparing for OpenShift

Exposer le Service Binaire CAS via Kustomize

La configuration des déploiements SAS Viya est un processus déclaratif géré par Kustomize. Les modifications ne sont pas effectuées de manière impérative avec des commandes

oc, mais en modifiant des fichiers YAML et en réappliquant l'ensemble du manifeste de déploiement. Cette approche garantit que les déploiements sont reproductibles, auditables et cohérents.

Par défaut, le service binaire CAS n'est exposé qu'en interne (type ClusterIP). Pour le rendre accessible de l'extérieur, le service Kubernetes pour CAS doit être modifié à l'aide d'un transformateur Kustomize.

Le Transformateur `cas-enable-external-services.yaml`

SAS fournit un fichier transformateur d'exemple précisément à cette fin.

Copier l'Exemple : L'administrateur doit copier le fichier d'exemple dans son répertoire de configuration spécifique au site.

cp $deploy/sas-bases/examples/cas/configure/cas-enable-external-services.yaml $deploy/site-config/cas/

Modifier le Transformateur : Le fichier contient des correctifs (patches) pour activer le service binaire. La partie clé consiste à définir publishBinaryService sur true et à définir le type de service.

Contenu exemple de site-config/cas/cas-enable-external-services.yaml

Source :Configure External Access to the CAS Server

Choisir le Type de Service : `NodePort` vs. `LoadBalancer`

NodePort (Par défaut) : Expose le service sur un port statique sur l'adresse IP de chaque nœud OpenShift. C'est plus simple pour les environnements sur site ou de test, mais peut être fragile si les nœuds changent. Ce type n'est pas pris en charge pour les déploiements Viya sur AWS ou Azure.
LoadBalancer : L'approche recommandée pour les déploiements en cloud (AWS, Azure). Il provisionne un équilibreur de charge externe du fournisseur de cloud, qui fournit un point d'entrée unique et stable (nom DNS ou IP) vers le service. C'est l'option la plus robuste et prête pour la production.

Mettre à jour le `kustomization.yaml` de Base

La dernière étape consiste à ajouter une référence à ce nouveau transformateur dans le fichier kustomization.yaml principal du déploiement, afin qu'il soit appliqué lors du prochain kubectl apply.YAML

# Dans le fichier kustomization.yaml de base ($deploy/kustomization.yaml)
transformers:
-...
- site-config/cas/cas-enable-external-services.yaml

Ports Réseau et Configuration du Pare-feu

Le Port Clé : 5570

Le serveur CAS écoute les connexions de protocole binaire sur le port 5570 par défaut à l'intérieur du cluster. C'est le port cible interne vers lequel le trafic externe doit être acheminé.

Mappage des Ports Expliqué

La distinction entre le port interne et le port externe est une source fréquente de confusion.

Si vous utilisez NodePort, OpenShift allouera un port dans une plage élevée (par exemple, 30000-32767) sur chaque nœud, qui transmettra ensuite le trafic au port interne 5570. Le client se connecte à <IP_du_Nœud>:<NodePort>.
Si vous utilisez LoadBalancer, l'équilibreur de charge du fournisseur de cloud écoutera sur un port (souvent 5570 par défaut, mais configurable) et transmettra le trafic au NodePort sur les nœuds, qui à son tour le transmettra au port interne 5570. Le client se connecte à <DNS_du_LoadBalancer>:<Port>.

Règles de Pare-feu

L'administrateur doit s'assurer que tous les pare-feu réseau ou groupes de sécurité cloud (par exemple, AWS Security Groups, Azure Network Security Groups) sont configurés pour autoriser le trafic TCP entrant depuis les adresses IP du client Python vers le port NodePort ou LoadBalancer exposé.

Le tableau suivant visualise le trajet d'un paquet réseau pour démystifier la traduction de port qui se produit.

Tableau 2 : Chemin Réseau et Mappage des Ports pour la Connexion Binaire

Étape	Composant	IP/Port Source	IP/Port Destination	Protocole	Notes
1	Client Python	`IP_Client:Port_Éphémère`	`IP_LoadBalancer:5570`	TCP	Le client initie la connexion.
2	Pare-feu / NSG	`IP_Client:Port_Éphémère`	`IP_LoadBalancer:5570`	TCP	Doit autoriser ce flux.
3	Load Balancer	`IP_Client:Port_Éphémère`	`IP_Nœud:NodePort`	TCP	Le LB redirige vers un NodePort.
4	Service Kube (kube-proxy)	`IP_Client:Port_Éphémère`	`IP_Pod_CAS:5570`	TCP	Le service mappe le NodePort au port du pod.
5	Pod Contrôleur CAS	`IP_Client:Port_Éphémère`	`IP_Pod_CAS:5570`	TCP	Le pod CAS reçoit la connexion.

Implémentation de la Connexion Python SWAT

Cette section se concentre sur le data scientist ou le développeur qui écrit le code Python.

La Bibliothèque `swat` : Votre Passerelle Python vers CAS

Le paquet sassoftware/python-swat est le client Python officiel et haute performance pour CAS. Il imite une grande partie de l'API du paquet Pandas pour offrir une expérience familière aux utilisateurs de Python.

Protocoles Binaire vs. REST

SWAT prend en charge deux protocoles de communication :

REST : Utilise HTTP/S. Il est plus portable car il est en pur Python mais a une surcharge plus élevée pour le transfert de données.
Binaire (Recommandé) : Utilise un protocole binaire propriétaire et haute performance. Il nécessite des bibliothèques C précompilées (incluses dans l'installation standard pip) et offre des performances supérieures, en particulier pour le chargement/téléchargement de grands ensembles de données. Ce rapport se concentre exclusivement sur le protocole binaire.

Installation et Prérequis

Installation standard via pip : pip install swat.
Nécessite Python 64 bits (versions 3.7 à 3.12 supportées).
Sur Linux, il a une dépendance sur la bibliothèque partagée libnuma.so.1. Si elle est manquante, le paquet numactl doit être installé (par exemple, sudo yum install numactl ou sudo apt-get install numactl).

Établissement de la Connexion : L'Appel `swat.CAS()`

Le cœur de la connexion est un unique appel de fonction.Python

conn = swat.CAS(hostname=cas_host, port=cas_port,
username=cas_user, password=cas_password,
ssl_ca_list=ca_cert_path)

Détermination de `hostname` et `port`

Ces valeurs sont directement liées aux choix faits dans la Section 2.2.

Si LoadBalancer a été utilisé, hostname est le nom DNS ou l'IP de l'équilibreur de charge. port est le port sur lequel il est configuré pour écouter (par exemple, 5570).
Si NodePort a été utilisé, hostname est l'adresse IP de n'importe quel nœud worker dans le pool de nœuds CAS. port est le NodePort à numéro élevé attribué par OpenShift.

Gestion du Chiffrement TLS/SSL

SAS Viya 4 impose le TLS de bout en bout par défaut. Toutes les connexions doivent être chiffrées. Le client (

swat) doit faire confiance au certificat présenté par le serveur CAS. Le paramètre ssl_ca_list dans le constructeur swat.CAS est utilisé pour pointer vers un fichier contenant les certificats de l'Autorité de Certification (CA) de confiance. Ce paramètre n'est pas optionnel ; il est obligatoire pour une connexion réussie.

Tâche de l'Administrateur : L'administrateur OpenShift doit extraire le certificat CA racine de SAS Viya du cluster (à partir du secret Kubernetes sas-viya-ca-certificate-secret) et le fournir de manière sécurisée à la machine cliente.

Plongée dans l'Authentification : Méthodes pour le Protocole Binaire

Cette section détaille les différentes manières de fournir des informations d'identification à l'appel swat.CAS().

Méthode 1 : Nom d'Utilisateur et Mot de Passe Directs

Comme montré dans l'exemple ci-dessus. Simple, mais non sécurisé car il code en dur les informations d'identification dans les scripts. Convient uniquement pour les tests interactifs.

Méthode 2 : Utilisation d'un Fichier `.authinfo` (Recommandé pour les Scripts)

Une méthode plus sécurisée qui évite de coder les mots de passe en dur. SWAT recherche automatiquement un fichier $HOME/.authinfo ou $HOME/.netrc.

Format du Fichier :# Dans ~/.authinfo machine openshift-loadbalancer.monentreprise.com port 5570 user monutilisateur password monmotdepasse default user monutilisateur password monmotdepasse
Permissions : Le fichier DOIT avoir les permissions définies sur 600 (lecture/écriture pour le propriétaire uniquement). SWAT échouera si les permissions sont trop ouvertes. Exécutez chmod 600 ~/.authinfo.
Code Python : Les paramètres username et password peuvent être omis.Python# Suppose que.authinfo est configuré correctement conn = swat.CAS(hostname=cas_host, port=cas_port, ssl_ca_list=ca_cert_path)

Méthode 3 : Jeton d'Accès OAuth 2.0 (L'Approche Moderne)

C'est la méthode la plus nuancée et la plus alignée sur les pratiques de sécurité modernes. Bien que OAuth soit natif des API REST, le jeton d'accès peut être utilisé comme un substitut de mot de passe pour la connexion binaire swat. Le mécanisme d'authentification principal de SAS Viya pour les API est OAuth 2.0. Le serveur CAS a été configuré pour accepter un jeton OAuth valide dans le champ du mot de passe de la connexion binaire et le valider auprès du SAS Logon Manager.

Le flux d'authentification est un processus en deux étapes :

Obtenir un jeton d'accès OAuth valide : Cela se fait via des appels à l'API REST de SAS Logon.
Passer ce jeton dans l'appel swat.CAS() comme mot de passe.

Étape A : Obtenir le Jeton d'Accès Les clients (comme un script Python) doivent être enregistrés auprès du SAS Logon Manager par un administrateur pour obtenir un client_id et un client_secret. Le script effectue ensuite un appel à l'API REST vers le point de terminaison /SASLogon/oauth/token pour recevoir un jeton d'accès.

Étape B : Utiliser le Jeton avec SWAT :

Pour cet exemple je me suis basé sur la documentation ci-dessous, que je vous encourage a parcourir pour créer votre propre code python :

Validation, Sujets Avancés et Dépannage

Cette dernière section fournit les outils pour vérifier la configuration et résoudre les problèmes courants.

Vérification de la Connexion et de l'État du Serveur

La Méthode about() : La vérification la plus simple. Elle renvoie un dictionnaire avec la version de Viya et les informations sur le serveur. Un retour réussi confirme que la connexion est active.
L'Action serverstatus() : Une vérification plus détaillée qui fournit l'état des nœuds du serveur CAS (contrôleur et workers), l'utilisation du CPU, la mémoire, etc. conn.serverstatus() est inestimable pour diagnostiquer les problèmes côté serveur.
Lister les Caslibs : L'exécution de conn.caslibInfo() confirme non seulement la connexion mais aussi que l'utilisateur a les permissions nécessaires pour voir les sources de données.

Sujet Avancé : Lancement avec l'Identité de l'Hôte (`cas-server-scc-host-launch`)

Comportement par Défaut : Par défaut, toutes les sessions CAS et toutes les données qu'elles créent appartiennent à l'UID/GID du compte de service cas (par exemple, 1001/1001).
Comportement de Lancement en tant qu'Hôte : Lorsque cas-server-scc-host-launch est utilisé (voir Section 2.1), CAS utilise ses privilèges élevés (SETUID/SETGID) pour lancer le processus de session en tant que l'identité de l'hôte de l'utilisateur qui se connecte. Par exemple, si l'utilisateur dave se connecte, le processus de session CAS s'exécutera en tant qu'utilisateur dave sur le système.
Implications : C'est essentiel pour les environnements avec des permissions de système de fichiers strictes et basées sur l'utilisateur (par exemple, sur des montages NFS). Si Dave a besoin d'accéder à son répertoire personnel /nfs/home/dave, le processus CAS doit s'exécuter en tant que dave. C'est une configuration puissante mais plus complexe avec des considérations de sécurité plus profondes.

Scénarios de Dépannage Courants

Délai d'Attente de Connexion Dépassé (Connection Timed Out)
- Causes : Pare-feu bloquant le port ; hostname ou port incorrect ; le service LoadBalancer ou NodePort n'est pas en cours d'exécution ou est mal configuré.
- Diagnostic : Utilisez ping, telnet <host> <port>, ou nmap depuis la machine cliente pour tester la connectivité réseau de base. Utilisez oc get svc -n <namespace> pour vérifier l'IP externe et le port du service CAS.
- (Source : )
Échec de l'Authentification (Authentication Failed)
- Causes : Nom d'utilisateur/mot de passe incorrect ; mot de passe expiré ; le fichier .authinfo a des permissions incorrectes (différentes de 600) ; le fichier .authinfo n'a pas d'entrée machine correspondante ; le jeton OAuth est expiré ou invalide.
- Diagnostic : Vérifiez à nouveau les informations d'identification. Vérifiez les permissions de .authinfo avec ls -l. Si vous utilisez un jeton, régénérez-le et réessayez immédiatement.
- (Source : )
Erreur de Négociation SSL/TLS (par exemple, CERTIFICATE_VERIFY_FAILED)
- Causes : Le paramètre ssl_ca_list n'est pas fourni ; le chemin vers le certificat CA est incorrect ; le certificat CA fourni n'est pas le bon pour le déploiement Viya.
- Diagnostic : Assurez-vous que le paramètre ssl_ca_list pointe vers un fichier valide. Demandez à l'administrateur OpenShift de ré-exporter le secret sas-viya-ca-certificate-secret et de vérifier son contenu.
- (Source : )
Could not connect... ou tkBoot failed
- Causes : Échec de connexion générique, masquant souvent un problème TLS ou une incompatibilité de protocole (par exemple, essayer de se connecter à un port REST avec le protocole binaire).
- Diagnostic : Vérifiez que le port est bien celui du protocole binaire (5570) et non celui du protocole REST (8777). Assurez-vous que tous les paramètres TLS sont corrects.

Conclusion et Liste de Contrôle des Meilleures Pratiques

Le succès de l'établissement d'une connexion binaire externe à CAS sur OpenShift repose sur une séquence d'actions coordonnées entre les administrateurs de la plateforme et les développeurs.

Le flux de bout en bout est le suivant :

Appliquer la SCC appropriée dans OpenShift pour accorder à CAS les privilèges nécessaires.
Exposer le service binaire CAS en utilisant un transformateur Kustomize et un service de type LoadBalancer.
Configurer les pare-feu pour autoriser le trafic vers le port exposé.
Fournir au client l'hôte, le port et le certificat CA du déploiement.
Implémenter la connexion Python swat en utilisant une méthode d'authentification sécurisée comme les fichiers .authinfo ou la récupération programmatique de jetons OAuth.

Liste de Contrôle de l'Administrateur

[ ] Identifier le cas d'utilisation de la session CAS pour choisir entre cas-server-scc et cas-server-scc-host-launch.
[ ] Appliquer la SCC choisie et la lier au compte de service sas-cas-server dans le bon namespace.
[ ] Créer et configurer le transformateur cas-enable-external-services.yaml pour utiliser un service de type LoadBalancer.
[ ] Ajouter le transformateur au fichier kustomization.yaml de base.
[ ] Déployer les modifications en appliquant le manifeste Kustomize (kubectl apply -k.).
[ ] Configurer les règles de pare-feu/groupe de sécurité pour autoriser le trafic entrant sur le port du LoadBalancer depuis les IP clientes.
[ ] Extraire le certificat CA (sas-viya-ca-certificate.pem) du secret Kubernetes et le transmettre de manière sécurisée au développeur.

Liste de Contrôle du Développeur

[ ] S'assurer que la bibliothèque swat est installée dans un environnement Python 64 bits.
[ ] Sur Linux, vérifier que la dépendance libnuma.so.1 (numactl) est installée.
[ ] Obtenir l'hôte, le port et le fichier de certificat CA de l'administrateur.
[ ] Mettre en œuvre une gestion sécurisée des informations d'identification, en privilégiant l'utilisation d'un fichier .authinfo avec des permissions 600 ou la récupération de jetons OAuth.
[ ] Utiliser le paramètre ssl_ca_list dans l'appel swat.CAS() pour pointer vers le certificat CA fourni.
[ ] Inclure une gestion robuste des erreurs et des blocs try...finally pour s'assurer que les connexions sont toujours fermées.

Recommandation Finale

Pour tous les déploiements en production, l'utilisation de services de type LoadBalancer est fortement recommandée pour sa robustesse et sa stabilité. De même, l'utilisation de fichiers .authinfo ou la récupération programmatique de jetons OAuth doit être préférée à l'intégration de mots de passe en clair dans les scripts pour tous les processus scriptés et automatisés, garantissant ainsi une posture de sécurité améliorée.