Principes architecturaux

GSS-API ne fournit pas de protocole lui-même, mais définit un ensemble cohérent de fonctions capables de s’interfacer avec divers fournisseurs de mécanismes de sécurité (par exemple krb5, spnego ou ntlmssp). Cette conception repose sur trois piliers :

• Indépendance vis-à-vis du mécanisme : Le code applicatif invoque des fonctions génériques comme gss_acquire_cred() ou gss_init_sec_context(), tandis que le système charge dynamiquement le module approprié via libgssapi_krb5.so ou un autre fournisseur.
• Séparation stricte entre contexte et données : Une fois établi, un contexte de sécurité (gss_ctx_id_t) est utilisé exclusivement pour protéger les flux applicatifs, sans réexécuter l’authentification à chaque appel.
• Interopérabilité binaire : Les structures teles que gss_name_t ou gss_buffer_desc sont définies de façon portable, garantissant que des binaires compilés sur une distribution peuvent fonctionner sur une autre, tant que la bibliothèque libgssapi est disponible.

Fonctionnement typique d’une session sécurisée

Une interaction GSS-API suit généralement ce cycle :

1. Le client obtient des identifiants via gss_acquire_cred(), souvent à partir d’un ticket Kerberos existant dans le cache local.
2. Il initialise un contexte avec gss_init_sec_context(), produisant un jeton binaire à envoyer au serveur.
3. Le serveur appelle gss_accept_sec_context() pour valider le jeton, puis renvoie un jeton de réponse si nécessaire (échange pouvant être itératif).
4. Lorsque le contexte est finalisé, les deux parties peuvent utiliser gss_wrap() pour chiffrer ou signer des messages, et gss_unwrap() pour les traiter côté récepteur.

Exemples d’intégration systèmes

Sécurisation des connexions SSH

Dans un environnement d’entreprise utilisant Kerberos, il est possible d’éliminer les saisies de mot de passe manuelles :

# /etc/ssh/sshd_config
GSSAPIAuthentication yes
GSSAPICleanupCredentials yes
# Redémarrer le service
sudo systemctl restart sshd

Après avoir obtenu un ticket avec kinit admin@EXAMPLE.COM, une connexion ssh user@server s’établit automatiquement via GSS-API, sans nécessiter d’authentification supplémentaire ni exposer de secret sur le réseau.

Protection des métadonnées dans Lustre

Pour empêcher l’accès non autorisé aux informations de fichiers dans un cluster Lustre, on active le mode krb5p :

lctl set_param -n gss.service.krb5p.enabled=1
lctl set_param -n gss.types=krb5p

Cela applique un chiffrement AES-256 aux requêtes entre le client Lustre et le serveur MDS, rendant inutilisables les paquets capturés en clair par un attaquant sur le réseau interne.

Authentification mutuelle dans les API REST

Lorsqu’un client Python doit dialoguer avec un service HTTP protégé par SPNEGO, il peut employer la bibliothèque gssapi ainsi :

import gssapi

target = gssapi.Name('HTTP/webapi.example.com@EXAMPLE.COM', gssapi.NameType.hostbased_service)
ctx = gssapi.SecurityContext(name=target, usage='initiate')

# Échange initial de jetons
token_in = None
while not ctx.complete:
    token_out = ctx.step(token_in)
    if token_out:
        # Envoi vers le serveur via en-tête Authorization: Negotiate <base64>
        pass
    token_in = server_response_token  # reçu depuis le serveur

# Protection d’un message
protected = ctx.wrap(b'{"action":"read"}', encrypt=True)

Optimisation et diagnostic

Les performances dépendent fortement du choix du mécanisme :

• Utiliser krb5i (intégrité seule) plutôt que krb5p (intégrité + confidentialité) réduit significativement la charge CPU sur des volumes élevés de petites requêtes.
• Un délai anormal lors de l’initialisation d’un contexte signale souvent un problème de synchronisation horaire avec le KDC : vérifier avec ntpstat ou chronyc tracking.
• En cas d’échec silencieux de l’authentification GSS-API dans SSH, désactiver temporairement SELinux (setenforce 0) permet de confirmer si une règle de politique bloque l’accès au cache Kerberos.