À propos des protocoles de système de fichiers compatibles

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

NFSv3

  • Disponible avec tous les niveaux de service.
  • Accepte 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 d'entreprise.
  • Compatible avec les configurations de pare-feu modernes et compatible avec les exigences de conformité en matière de sécurité réseau.
    • La communication est toujours initiée par le client et toujours servie 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, toutes 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 une compatibilité avec les LCA de fichiers NFSv4.1 pour le client et le serveur.

Chaque protocole est le plus 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 Zonales, régionales et d'entreprise
Communication bidirectionnelle Oui Non. La communication est toujours initiée par le client via le port serveur 2049.
Authentification Non Oui. Nécessite l'authentification RPCSEC_GSS, implémentée à l'aide de LDAP et de Kerberos, toutes deux disponibles dans le service géré pour Microsoft Active Directory.
Compatible avec les listes de contrôle d'accès (LCA) de fichiers ou de répertoires Non Oui. Jusqu'à 50 entrées de contrôle d'accès (ACE) par liste sont acceptées.
Assistance Groupes Jusqu'à 16 groupes Prise en charge illimitée des groupes lorsque vous êtes connecté à 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 vérifications d'authentification et d'intégrité des messages.krb5p. Fournit l'authentification, les contrôles d'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 Gestionnaire de verrouillages réseau. La serrure est contrôlée par le client. Verrouillage consultatif basé sur le bail. Le verrouillage est contrôlé par le serveur.
Compatible avec les défaillances des clients Non Oui
Accepte l'accès aux services privés Non Non

Avantages de NFSv3

Le protocole NFSv3 permet de configurer rapidement l'accès POSIX standard.

Limites de NFSv3

Voici une liste des limites de NFSv3:

  • L'accès aux services privés n'est pas pris en charge.
  • L'authentification et le chiffrement du client et du serveur sont insuffisants.
  • La gestion des échecs côté client est insuffisante.

Avantages de NFSv4.1

Le protocole NFSv4.1 utilise l'authentification RPCSEC_GSS. , qui est implémentée à l'aide de LDAP et Kerberos pour fournir des données et l'authentification du serveur, les contrôles de l'intégrité des messages le chiffrement.

Ces fonctionnalités de sécurité rendent le protocole NFSv4.1 compatible avec les exigences de conformité de la sécurité du réseau:

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

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

    • Chaque LCA accepte 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 illimitée des groupes lors de l'intégration au service Microsoft AD géré.

  • Améliore la gestion des échecs client grâce au verrouillage consultatif basé sur les baux.

    • Le client doit vérifier que la connexion au serveur est maintenue. Si le client ne renouvelle pas le bail, le serveur libère le verrouillage et le fichier devient disponible pour tout autre client demandant l'accès via 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.

  • Compatible avec la reprise après sinistre avec état.

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

Service géré pour Microsoft Active Directory

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

Les administrateurs sont vivement encouragés à utiliser le service géré pour Microsoft Active Directory (service Microsoft AD géré) pour implémenter et gérer LDAP et Kerberos.

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

  • Permet un déploiement multirégional, avec jusqu'à cinq régions d'un 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 normes POSIX RFC 2307 et RFC 2307bis, qui sont des exigences pour l'implémentation de NFSv4.1.

  • Automatise la mise en correspondance des utilisateurs avec les identifiants uniques (UID) et les identifiants uniques globaux (GUID).

  • Les utilisateurs et les groupes peuvent être créés ou migrés vers le service Microsoft AD géré.

  • Les administrateurs peuvent créer une approbation de domaine avec l'environnement sur site actuel, un domaine Active Directory (AD) et LDAP autogéré. 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 éléments suivants : commandes:

    • nfs4_setfacl: créer ou modifier les ACE sur un fichier ou un répertoire.
    • nfs4_getfacl : liste les ACE sur un fichier ou un répertoire.

  • Chaque ACL accepte jusqu'à 50 ACE. Six entrées sont réservées aux ACE générées automatiquement créées par les opérations chmod client. Ces ACE peuvent être modifiés après leur création.

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

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

    • DENY and ALLOW ACEs pour EVERYONE@

      Si ces campagnes existent déjà, elles seront réutilisées et modifiées en fonction des nouveaux bits de mode appliqués.

  • Filestore NFSv4.1 ne permet de vérifier l'accès requis que dans le mode POSIX RWX (lecture, écriture et exécution). Il ne distinguera pas Les opérations write append et write qui modifient le contenu ou SETATTR spécifique. L'utilitaire nfs4_setfacl accepte également RWX comme raccourci et active automatiquement tous les indicateurs appropriés.

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

  • Que vous utilisiez le service Microsoft AD géré ou non, lorsque vous travaillez avec AUTH-SYS et l'utilitaire nfs4_setfacl, les administrateurs doivent spécifier les valeurs numériques UID et GUID, et non les noms d'utilisateur. Cet utilitaire n'est pas en mesure convertir les noms en ces valeurs. S'il n'est pas fourni correctement, L'instance Filestore utilise par défaut l'ID nobody.

  • Lorsque vous spécifiez des autorisations d'écriture pour un fichier, ou même pour des fichiers affectés par un ACE hérité, l'ACE doit inclure à la fois w (écriture) et a (ajout) options.

  • Lorsque vous vérifiez les autorisations pour SETATTR, la réponse renvoyée est semblable à POSIX comme suit :

    • Le super-utilisateur ou l'utilisateur ROOT peut faire n'importe quoi.
    • 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 ACE englobe à la fois les autorisations effectives et les autorisations d'héritage uniquement. Contrairement aux autres implémentations NFSv4.1, Filestore ne réplique pas automatiquement les ACE hérités dans le but de distinguer les ACE efficaces et les ACE hérités uniquement.

Limites de NFSv4.1

Voici la liste des limites de NFSv4.1 :

  • Le protocole NFSv4.1 ne peut pas être combiné aux fonctionnalités suivantes :

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

  • Une fois configurés, ne supprimez pas Microsoft AD géré et l'appairage réseau. Cela rendrait le partage Filestore inaccessible pendant son installation sur un client, ce qui rend vos données inaccessibles. Google Cloud n'est pas responsable des pannes causées par les actions d’un administrateur ou d’un utilisateur.

  • Lorsqu'ils utilisent l'un des paramètres de sécurité Kerberos authentifiés, les utilisateurs peuvent : s'attendent à 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é. La latence augmente à mesure que le niveau de sécurité augmente.

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

  • La solution NFSv4.1 Filestore nécessite l'authentification RPCSEC_GSS. Cette méthode d'authentification n'est implémentée qu'avec LDAP et Kerberos, tous deux disponibles dans Microsoft AD géré. Les autres mécanismes d'authentification ne sont pas acceptés.

  • L'accès aux services privés n'est pas pris en charge.

  • Si vous souhaitez qu'une instance Filestore rejoigne Microsoft AD géré via un VPC partagé, vous devez utiliser gcloud ou l'API Filestore. Vous ne pouvez pas joindre l'instance au service Microsoft AD géré à l'aide du console Google Cloud.

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

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

  • Lors de la restauration d'une sauvegarde, la nouvelle instance doit utiliser le même protocole que l'instance source.

Étape suivante