À 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.
  • Pris 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 LCA 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 le service géré 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 associé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 (GA 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 comporte pas d'authentification ni de chiffrement du client et du serveur.
  • La gestion des échecs du 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 des accès (LCA) aux fichiers NFSv4.1.

    • Chaque LCA peut contenir jusqu'à 50 entrées de contrôle des 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 Microsoft AD géré.

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

    • Le client doit vérifier la continuité de la connexion 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 (par exemple, un nouveau nœud GKE) ne peut pas accéder au fichier.

  • Compatible avec la récupération avec état.

    • Contrairement à NFSv3, NFSv4.1 est un protocole avec état basé sur TCP et sur 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 prend en charge à la fois LDAP et Kerberos, qui sont tous deux requis pour le protocole Filestore NFSv4.1.

Nous encourageons vivement les administrateurs à utiliser le service géré pour Microsoft Active Directory (Microsoft AD géré) pour implémenter et 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 les uns des autres.

  • 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 contrat de niveau de service.

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 accepter 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 pouvez 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 le OWNER@
    • DENY and ALLOW ACEs pour le 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 en soi. L'utilitaire nfs4_getfacl affichera les ID 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 elle n'est pas fournie correctement, l'instance Filestore utilisera par défaut l'ID nobody.

  • 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 :

    • 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.

  • Un seul 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

Voici une liste des limites de NFSv4.1 :

  • Le protocole NFSv4.1 ne peut pas être combiné avec les multipartages Filestore pour GKE.

  • Le protocole NFSv4.1 n'est pas compatible avec AUDIT and ALARM ACEs. Filestore ne prend pas en charge l'audit des accès aux données.

  • Une fois la configuration effectuée, ne supprimez pas Microsoft AD géré ni l'appairage de réseau. Cela rend le partage Filestore inaccessible lorsqu'il est monté sur un client, ce qui rend vos données inaccessibles. Google Cloud n'est pas responsable des pannes causées par les actions des administrateurs ou des utilisateurs.

  • 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. Les taux de latence varient en fonction du niveau de service et du paramètre de sécurité spécifiés. La latence augmente à chaque niveau de sécurité.

  • L'audit des accès aux données n'est pas pris en charge.

  • La solution Filestore NFSv4.1 utilise l'authentification RPCSEC_GSS, qui est implémentée à l'aide de LDAP et Kerberos, tous deux disponibles dans Managed Microsoft AD. Filestore NFSv4.1 peut également être utilisé sans mécanisme d'authentification, comme NFSv3. Les autres mécanismes d'authentification ne sont pas acceptés.

  • Si vous souhaitez qu'une instance Filestore rejoigne Managed Microsoft AD via un VPC partagé, vous devez utiliser gcloud ou l'API Filestore. Vous ne pouvez pas joindre l'instance à Microsoft AD géré à l'aide de la consoleGoogle Cloud .

  • Le nom de domaine Managed Microsoft AD ne doit pas dépasser 56 caractères.

  • Pour créer une instance Enterprise, vous devez exécuter des opérations directement via l'API Filestore. Pour en savoir plus, consultez Niveaux de service.

  • Lorsque vous restaurez une sauvegarde, la nouvelle instance doit utiliser le même protocole que l'instance source.

Étapes suivantes