À propos des protocoles de système de fichiers compatibles

Filestore est compatible avec les protocoles de système de fichiers suivants :

NFSv3

  • Disponible dans tous les niveaux de service.
  • Compatible avec la communication bidirectionnelle entre le client et le serveur.
    • Utilise plusieurs ports.
    • Crée un canal de confiance pour le trafic et les opérations réseau.
  • Offre une configuration rapide pour l'accès POSIX standard.

NFSv4.1

  • Disponible dans les niveaux de service zonal, régional et Enterprise.
  • Prise en charge par le pilote CSI Filestore pour créer des instances zonales ou Enterprise et les monter avec la sémantique NFSv4.1.
  • Compatible avec les configurations de pare-feu modernes et conforme aux exigences de conformité en matière de sécurité réseau.
    • La communication est toujours initiée par le client et toujours assurée par un seul port de serveur, 2049.
    • Compatible avec l'authentification du client et du serveur.
      • Nécessite l'authentification RPCSEC_GSS, qui est implémentée à l'aide de LDAP et Kerberos, tous deux disponibles dans le service géré pour Microsoft Active Directory.
      • Compatible avec LDAP et Kerberos pour l'authentification (krb5), les vérifications de l'intégrité des messages (krb5i) et le chiffrement des données en transit (krb5p).
      • Offre la compatibilité avec les ACL de fichiers NFSv4.1 pour le client et le serveur.

Chaque protocole est mieux adapté à des cas d'utilisation spécifiques. Le tableau suivant compare les spécifications de chaque protocole :

Spécification NFSv3 NFSv4.1
Niveaux de service compatibles Tous les niveaux de service Zonale, régionale et Enterprise
Communication bidirectionnelle Oui Non. La communication est toujours initiée par le client à l'aide du port de serveur 2049.
Authentification Non Oui. Nécessite l'authentification RPCSEC_GSS, implémentée à l'aide de LDAP et Kerberos, tous deux disponibles dans Managed Service pour Microsoft Active Directory.
Compatible avec les listes de contrôle d'accès (LCA) aux fichiers ou aux répertoires Non Oui. Chaque liste peut contenir jusqu'à 50 entrées de contrôle d'accès (ACE).
Compatibilité avec les groupes Jusqu'à 16 groupes Prise en charge d'un nombre illimité de groupes lorsqu'ils sont connectés à Microsoft AD géré.
Paramètre de sécurité sys. Crée un canal de confiance. sys. Crée un canal de confiance. krb5. Authentifie le client et le serveur. krb5i. Fournit des contrôles d'authentification et d'intégrité des messages.krb5p Fournit l'authentification, des vérifications de l'intégrité des messages et le chiffrement des données en transit.
Latence des opérations Aucun La latence des opérations augmente avec le niveau de sécurité sélectionné.
Type de récupération Sans état Avec état
Type de verrouillage de fichier Network Lock Manager (NLM). Le verrou est contrôlé par le client. Verrouillage consultatif basé sur un bail. Le verrou est contrôlé par le serveur.
Prise en charge des échecs du client Non Oui
Compatible avec l'accès aux services privés Oui Oui
Compatible avec Private Service Connect (disponibilité générale sur liste d'autorisation) Non Oui

Avantages de NFSv3

Le protocole NFSv3 permet une configuration rapide pour l'accès POSIX standard.

Limites de NFSv3

Voici une liste des limites de NFSv3 :

  • Il ne dispose pas de l'authentification ni du chiffrement du client et du serveur.
  • La gestion des échecs côté client est insuffisante.

Avantages de NFSv4.1

Le protocole NFSv4.1 utilise la méthode d'authentification RPCSEC_GSS, qui est implémentée à l'aide de LDAP et Kerberos pour fournir l'authentification du client et du serveur, des vérifications de l'intégrité des messages et le chiffrement des données en transit.

Ces fonctionnalités de sécurité rendent le protocole NFSv4.1 compatible avec les exigences de conformité modernes en matière de sécurité réseau :

  • Utilise un seul port de serveur, 2049, pour toutes les communications, ce qui simplifie les configurations de pare-feu.

  • Compatible avec les listes de contrôle d'accès (LCA) aux fichiers NFSv4.1.

    • Chaque LCA peut contenir jusqu'à 50 entrées de contrôle d'accès (ACE) par fichier ou répertoire. Cela inclut les enregistrements d'héritage.

  • Prise en charge d'un nombre illimité de groupes lors de l'utilisation de l'intégration Managed Microsoft AD.

  • Prise en charge améliorée de la gestion des échecs client avec le verrouillage consultatif basé sur un bail.

    • Le client doit vérifier la connexion continue avec le serveur. Si le client ne renouvelle pas le bail, le serveur libère le verrou et le fichier devient disponible pour tout autre client demandant l'accès par le biais d'un bail de verrouillage. Dans NFSv3, si un client est supprimé alors qu'il est verrouillé, un autre client, tel qu'un nouveau nœud GKE, ne peut pas accéder au fichier.

  • Il est compatible avec la récupération avec état.

    • Contrairement à NFSv3, NFSv4.1 est un protocole avec état basé sur TCP et les connexions. L'état du client et du serveur lors de la session précédente peut être rétabli après la récupération.

Service géré pour Microsoft Active Directory

Bien que le service géré pour Microsoft Active Directory (Microsoft AD géré) ne soit pas une exigence stricte, il s'agit de la seule solution gérée par Google Cloudqui soit compatible avec LDAP et Kerberos, deux exigences du protocole Filestore NFSv4.1.

Nous encourageons vivement les administrateurs à utiliser le service géré pour Microsoft Active Directory (Microsoft AD géré) afin d'implémenter et de gérer LDAP et Kerberos.

En tant que solution gérée par Google Cloud, Managed Microsoft AD offre les avantages suivants :

  • Offre un déploiement multirégional, avec la possibilité de prendre en charge jusqu'à cinq régions sur le même domaine.

    • Réduit la latence en veillant à ce que les utilisateurs et leurs serveurs de connexion respectifs soient plus proches.

  • Compatible avec les exigences POSIX RFC 2307 et RFC 2307bis pour l'implémentation de NFSv4.1.

  • Automatise le mappage des identifiants uniques (UID) et des identifiants uniques globaux (GUID) des utilisateurs.

  • Vous pouvez créer des utilisateurs et des groupes dans Managed Microsoft AD ou les y migrer.

  • Les administrateurs peuvent créer une approbation de domaine avec le domaine Active Directory (AD) et LDAP actuel, autogéré et sur site. Avec cette option, la migration n'est pas nécessaire.

  • Fournit un SLA

Contrôle des accès et comportements supplémentaires

  • Les ACE NFSv4.1 Filestore sont gérés sous Linux à l'aide des commandes suivantes :

    • nfs4_setfacl : créez ou modifiez des ACE sur un fichier ou un répertoire.
    • nfs4_getfacl : liste les ACE d'un fichier ou d'un répertoire.

  • Chaque ACL peut contenir jusqu'à 50 ACE. Six entrées sont réservées aux ACE générées automatiquement par les opérations du client chmod. Vous pourrez modifier ces ACE après leur création.

    Les enregistrements ACE générés automatiquement représentant les bits de mode sont listés dans l'ordre de priorité suivant :

    • DENY and ALLOW ACEs pour OWNER@
    • DENY and ALLOW ACEs pour GROUP@

    • DENY and ALLOW ACEs pour EVERYONE@

      Si de telles ACE sont déjà présentes, elles seront réutilisées et modifiées en fonction des nouveaux bits de mode appliqués.

  • Filestore NFSv4.1 n'est compatible avec la vérification de l'accès requis qu'en mode POSIX RWX (lecture, écriture et exécution). Il ne fera pas la différence entre les opérations write append et write qui modifient le contenu ou la spécification SETATTR. L'utilitaire nfs4_setfacl accepte également RWX comme raccourci et active automatiquement tous les indicateurs appropriés.

  • nfs4_getfacl ne traduit pas le compte principal lui-même. L'utilitaire nfs4_getfacl affichera les valeurs numériques UID et GUID pour les principaux. Par conséquent, les comptes principaux spéciaux OWNER@, GROUP@ et EVERYONE@ s'affichent.

  • Que vous utilisiez ou non Managed Microsoft AD, lorsque vous travaillez avec AUTH-SYS et l'utilitaire nfs4_setfacl, les administrateurs doivent spécifier les UID et GUID numériques, et non les noms d'utilisateur. Cet utilitaire n'est pas en mesure de traduire les noms en ces valeurs. Si l'ID n'est pas fourni correctement, l'instance Filestore utilisera l'ID nobody par défaut.

  • Lorsque vous spécifiez des autorisations d'écriture pour un fichier, ou même pour des fichiers concernés par une ACE héritée, l'ACE doit inclure les indicateurs w (écriture) et a (ajout).

  • Lorsque vous vérifiez les autorisations pour SETATTR, la réponse renvoyée est semblable à POSIX de la manière suivante :

    • Le super-utilisateur ou l'utilisateur ROOT peut tout faire.
    • Seul le propriétaire du fichier peut définir les bits de mode, les LCA et les codes temporels sur une heure et un groupe spécifiques, comme l'un des GUID auxquels il appartient.
    • Les utilisateurs autres que le propriétaire du fichier peuvent afficher les attributs, y compris la LCA.

  • Une seule ACE englobe les autorisations effectives et celles en héritage uniquement. Contrairement à d'autres implémentations NFSv4.1, Filestore ne réplique pas automatiquement les ACE héritées pour faire la distinction entre les ACE effectives et celles qui sont uniquement héritées.

Limites de NFSv4.1

Le protocole NFSv4.1 présente les limites suivantes :

  • Limites générales

    • Lorsque vous restaurez une sauvegarde, la nouvelle instance doit utiliser le même protocole que l'instance source.
    • Lorsque vous utilisez l'un des paramètres de sécurité Kerberos authentifiés, les utilisateurs peuvent s'attendre à une certaine latence des opérations. La latence augmente à chaque niveau de sécurité.
    • Le protocole NFSv4.1 n'est pas compatible avec les ACE AUDIT et ALARM.
    • L'audit des accès aux données n'est pas pris en charge.

  • Limites de GKE

    Le protocole NFSv4.1 ne peut pas être combiné avec les multipartages Filestore pour GKE. Cette fonctionnalité n'est compatible qu'avec NFSv3. Pour obtenir la liste complète des versions de GKE compatibles avec chaque protocole et niveau de service Filestore, consultez le tableau de compatibilité dans Accéder aux instances Filestore avec le pilote CSI Filestore.

  • Limites de Microsoft AD géré

    • Une fois configuré, ne supprimez pas le domaine Managed Microsoft AD ni l'appairage de réseau. Cela rendra le partage Filestore inaccessible.
    • Le seul mécanisme d'authentification compatible est RPCSEC_GSS, qui est implémenté à l'aide de LDAP et Kerberos (tous deux disponibles dans Managed Microsoft AD).
    • Pour qu'une instance Filestore rejoigne Managed Microsoft AD via un VPC partagé, vous devez utiliser gcloud ou l'API Filestore, et non Google Cloud.
    • Le nom de domaine Managed Microsoft AD ne doit pas dépasser 56 caractères.

Étape suivante