Cette page explique comment connecter des clients NFS.
Avant de commencer
Installez les outils client NFS en fonction du type de distribution Linux pour préparer votre client :
Red Hat
Exécutez la commande suivante :
sudo yum install -y nfs-utils
SuSe
Exécutez la commande suivante :
sudo yum install -y nfs-utils
Debian
Exécutez la commande suivante :
sudo apt-get install nfs-common
Ubuntu
Exécutez la commande suivante :
sudo apt-get install nfs-common
Contrôle de l'accès aux volumes à l'aide de règles d'exportation
Le contrôle des accès aux volumes dans NFSv3 et NFSv4.1 est basé sur l'adresse IP du client. La règle d'exportation du volume contient jusqu'à 20 règles d'exportation. Chaque règle est une liste d'adresses IP ou de CIDR de réseau séparés par des virgules, qui définissent les clients autorisés à monter le volume. Une règle définit également le type d'accès dont disposent les clients, par exemple Lecture et écriture ou Lecture seule.
Utilisez les onglets suivants pour consulter les règles en fonction des versions de NFS :
NFS sans Kerberos
Toutes les versions NFS sans Kerberos utilisent le type de sécurité AUTH_SYS. Dans ce mode, vous devez gérer rigoureusement les règles d'exportation pour n'autoriser que les clients auxquels vous faites confiance et qui peuvent garantir l'intégrité des ID utilisateur et des ID de groupe.
Par mesure de sécurité, les serveurs NFS mappent automatiquement les appels NFS avec UID=0 (racine) à UID=65534 (anonyme), qui dispose d'autorisations limitées sur le système de fichiers. Pour en savoir plus, consultez Compression des ID utilisateur.
NFSv4.1 avec Kerberos
NFSv4.1 avec Kerberos utilise des règles d'exportation et une authentification supplémentaire avec Kerberos pour accéder aux volumes. Vous pouvez configurer des règles d'exportation pour les éléments suivants :
Kerberos uniquement (
krb5)Signature Kerberos (
krb5i)Confidentialité de Kerberos (
krb5p)
Bonnes pratiques pour les règles d'exportation
Nous vous recommandons de suivre les bonnes pratiques suivantes pour les règles d'exportation :
Classez les règles d'exportation de la plus spécifique à la moins spécifique.
N'exportez que vers les clients de confiance, tels que des clients ou des CIDR spécifiques avec les clients de confiance.
Limitez l'accès root à un petit groupe de clients d'administration de confiance.
| Règle | Clients autorisés | Accès | Accès root | Description |
|---|---|---|---|---|
| 1 | 10.10.5.3,
10.10.5.9 |
Lecture & écriture | Activé | Clients d'administration. L'utilisateur racine reste racine et peut gérer
toutes les autorisations de fichier. |
| 2 | 10.10.5.0/24 | Lecture & écriture | Désactivé | Tous les autres clients du réseau 10.10.5.0/24 sont autorisés à monter, , mais l'accès racine est mappé sur "nobody". |
| 3 | 10.10.6.0/24 | En lecture seule | Désactivé | Un autre réseau est autorisé à lire les données du volume, mais sans autorisation d'écriture. |
Une fois qu'un client a installé un volume, l'accès au niveau du fichier détermine ce qu'un utilisateur est autorisé à faire. Pour en savoir plus, consultez Contrôle des accès au niveau des fichiers NFS pour les volumes de type UNIX.
Compression des User-ID
Les règles d'exportation NFS fournissent des contrôles pour l'écrasement des ID d'utilisateur et de groupe, ce qui vous permet de remapper les ID d'utilisateur et de groupe sur un ID d'utilisateur anonyme à des fins de sécurité.
Root-squashing
Les serveurs NFS améliorent la sécurité en remappant l'utilisateur racine (UID=0) sur "nobody" (UID=65534), ce qui fait de la racine un utilisateur non privilégié pour l'accès aux fichiers sur le volume. Cette fonctionnalité est appelée compression de la racine. L'option permettant de le désactiver et de conserver les privilèges racine s'appelle no_root_squash sur les serveurs NFS.
Par défaut, les adresses IP des clients ne peuvent pas accéder aux volumes sans règle d'exportation définie. Lorsque vous créez une règle de stratégie d'exportation dans la console Google Cloud , les paramètres par défaut incluent l'accès Lecture et écriture et l'écrasement de root. L'APIGoogle Cloud , Google Cloud CLI et Terraform permettaient auparavant de contrôler l'écrasement de la racine à l'aide du paramètre has-root-access. Bien que has-root-access soit toujours accepté, il a été remplacé par le paramètre squash-mode.
Il est recommandé de créer une règle d'exportation dédiée qui active l'accès racine pour vos hôtes administrateurs de confiance et le désactive pour les autres clients. Placez cette règle en premier, avant les règles plus génériques.
Écrasement des ID d'utilisateur et de groupe
Le paramètre squash-mode permet de contrôler l'écrasement des ID d'utilisateur et de groupe en un UID anonyme, ce qui peut être utile pour les répertoires de dépôt SFTP publics. Ce paramètre remplace également le paramètre has-root-access et est compatible avec l'API, la Google Cloud CLI et Terraform.
Le paramètre squash-mode accepte les valeurs suivantes :
no-root-squash: dans ce mode, l'utilisateur racine reste racine et n'est pas remappé sur personne (UID=65534).root-squash: ce paramètre remappe l'utilisateur racine sur "nobody".all-squash: cette option permet un accès anonyme à tous les utilisateurs, y compris à la racine. Tous les utilisateurs sont remappés vers l'UID et le GID spécifiés par le paramètreanon-uid. Lorsque vous utilisezall-squash, vous devez également spécifieranon-uidet définiraccess-typesurREAD_WRITE.
Remarques
Tenez compte des points suivants pour les règles relatives aux stratégies d'exportation avec squash mode :
Une règle d'exportation n'est compatible qu'avec une seule règle
all-squash.Lorsque
all-squashest activé, l'utilisateur racine est écrasé et devient anonyme. Cette valeur peut être remplacée par une règle de priorité plus élevée qui utiliseno-root-squash.La réplication de volume n'est pas compatible avec les volumes associés à une règle d'exportation de style
squash-mode.Pour le niveau de service Flex,
all-squashne modifie pas automatiquement la propriété de l'inode racine du volume. Pour ce faire, ajoutez une règle d'exportationno-root-squash, permettant à l'utilisateur racine d'utiliserchownpour modifier le propriétaire de l'inode racine et le définir sur l'UID requis.Le paramètre
has-root-accessest accepté. Utilisezhas-root-accessousquash-mode, mais pas les deux paramètres simultanément.
Modifier un volume
Suivez les instructions ci-dessous pour mettre à jour la règle d'exportation d'un volume avec le mode squash à l'aide de Google Cloud CLI :
gcloud
Mettez à jour un volume avec une règle d'exportation en mode squash :
gcloud netapp volumes update VOLUME_ID \ --project=PROJECT_ID \ --location=LOCATION \ --export-policy=access-type=ACCESS_TYPE,squash-mode=SQUASH_MODE,anon-uid=ANON_UID,allowed-clients=ALLOWED_CLIENTS_IP_ADDRESSES
Remplacez les informations suivantes :
VOLUME_ID: ID du volume.PROJECT_ID: nom du projet dans lequel se trouve le volume.LOCATION: emplacement du volume.ACCESS_TYPE: le type d'accès doit êtreREAD_WRITE,READ_ONLYouREAD_NONE.SQUASH_MODE: la règle d'exportation doit être l'une des suivantes :NO_ROOT_SQUASH,ROOT_SQUASHouALL_SQUASH.ANON_UID: numéro UID à écraser.ALLOWED_CLIENTS_IP_ADDRESSES: liste d'adresses ou de plages d'adresses IP client autorisées, séparées par une virgule.
Les paramètres des règles d'exportation peuvent être répétés pour inclure plusieurs règles.
L'exemple suivant montre où une règle d'exportation comporte à la fois des règles root-squash et all-squash :
gcloud netapp volumes update my_volume --location=us-east4 \ --export-policy=allowed-clients=10.0.1.18,nfsv3=true,access-type=READ_WRITE,squash-mode=NO_ROOT_SQUASH \ --export-policy=allowed-clients=10.0.2.0/24,nfsv3=true,access-type=READ_WRITE,squash-mode=ALL_SQUASH,anon-uid=2000
Pour en savoir plus sur les options facultatives supplémentaires, consultez la documentation du SDK Google Cloud sur les règles d'exportation des volumes.
Instructions d'installation pour les clients NFS
Suivez les instructions ci-dessous pour obtenir des instructions de montage pour les clients NFS à l'aide de la console Google Cloud ou de Google Cloud CLI :
Console
Accédez à la page NetApp Volumes dans la console Google Cloud .
Cliquez sur Volumes.
Cliquez sur Afficher plus.
Sélectionnez Instructions d'installation.
Suivez les instructions de montage affichées dans la console Google Cloud .
Identifiez la commande d'installation et utilisez les options d'installation, sauf si votre charge de travail a des exigences spécifiques en la matière.
NFSv3 uniquement : si votre application n'utilise pas de verrous ou si vous n'avez pas configuré vos clients pour activer la communication NSM, nous vous recommandons d'ajouter l'option de montage
nolock.
gcloud
Recherchez les instructions de montage d'un volume :
gcloud netapp volumes describe VOLUME_NAME \ --project=PROJECT_ID \ --location=LOCATION \ --format="value(mountOptions.instructions)"
Remplacez les informations suivantes :
VOLUME_NAME: nom du volume.PROJECT_ID: nom du projet dans lequel se trouve le volume.LOCATION: emplacement du volume.
Pour en savoir plus sur les autres options facultatives, consultez la documentation du SDK Google Cloud sur les volumes.
Instructions supplémentaires pour NFSv4.1
Lorsque vous activez NFSv4.1 pour les volumes des niveaux de service Flex Unified, Standard, Premium et Extreme, NFSv4.2 est automatiquement activé pour ces volumes. La commande Linux mount installe toujours la version NFS la plus récente disponible, sauf si vous spécifiez la version à installer. Si vous souhaitez effectuer le montage avec NFSv4.1, utilisez le paramètre -o vers=4.1 dans votre commande de montage.
Dans NFSv3, les utilisateurs et les groupes sont identifiés par des ID d'utilisateur (UID) et des ID de groupe (GID) envoyés via le protocole NFSv3. Il est important de s'assurer que le même UID et le même GID représentent le même utilisateur et le même groupe sur tous les clients qui accèdent au volume. NFSv4 a supprimé la nécessité d'un mappage explicite des UID et des GID en utilisant des identifiants de sécurité.
Les identifiants de sécurité sont des chaînes au format <username|groupname>@<full_qualified_domain>.
bob@example.com est un exemple d'identifiant de sécurité.
Le client doit traduire les UID et GID utilisés en interne en identifiant de sécurité avant d'envoyer une requête NFSv4 au serveur. Le serveur doit traduire les identifiants de sécurité en UID et GID pour une requête entrante, et inversement pour sa réponse. L'avantage d'utiliser des traductions est que chaque client et le serveur peuvent utiliser des UID et des GID internes différents.
Toutefois, l'inconvénient est que tous les clients et le serveur doivent tenir à jour une liste de mappage entre les UID et les GID, ainsi que les noms d'utilisateurs et de groupes. Les informations de mappage sur les clients peuvent provenir de fichiers locaux tels que /etc/passwd et /etc/groups, ou d'un annuaire LDAP. La configuration de ce mappage est gérée par rpc.idmapd, qui doit s'exécuter sur votre client.
Sur les volumes NetApp, le serveur LDAP doit fournir des informations de mappage. Active Directory est le seul serveur LDAP compatible avec RFC2307bis.
Lorsque vous utilisez Kerberos pour NFSv4, l'identifiant de sécurité stocke les principaux Kerberos au format username@DOMAINNAME, où DOMAINNAME (en majuscules) devient le nom du domaine.
ID numériques
Pour les utilisateurs qui ne souhaitent pas configurer les mappages de noms et qui préfèrent utiliser NFSv4 en remplacement de NFSv3, NFSv4 a introduit une option appelée numeric ID, qui envoie des chaînes de texte encodées UID et GID en tant qu'identifiants de sécurité. Cela simplifie le processus de configuration pour les utilisateurs.
Vous pouvez vérifier le paramètre de votre client à l'aide de la commande suivante :
cat /sys/module/nfs/parameters/nfs4_disable_idmapping
La valeur par défaut est Y, ce qui active les ID numériques. NetApp Volumes accepte l'utilisation d'ID numériques.
Configurer rpc.idmapd sur le client NFS
Quel que soit le type d'ID ou d'identifiants de sécurité que vous utilisez, il est nécessaire de configurer rpc.idmapd sur votre client NFS. Si vous avez suivi les instructions d'installation des utilitaires client dans la section Avant de commencer, il devrait déjà être installé, mais peut-être pas en cours d'exécution. Certaines distributions le démarrent automatiquement à l'aide de systemd lorsque vous montez les premiers volumes NFS. La configuration minimale requise pour rpc.idmapd consiste à configurer le paramètre de domaine. Sinon, la racine utilisateur sera affichée comme "nobody" avec UID=65534 or 4294967295.
Suivez les instructions ci-dessous pour configurer rpc.idmapd sur votre client NFS :
Sur votre client, ouvrez le fichier
/etc/idmapd.confet remplacez le paramètre de domaine par l'un des suivants :Si votre volume n'est pas activé pour LDAP,
domain = defaultv4iddomain.com.Si votre volume est activé pour LDAP,
domain = <FDQN_of_Windows_Domain>.
Activez les modifications apportées à
rpc.idmapden exécutant la commande suivante :nfsidmap -c
Compatibilité avec NFSv4.2
Les niveaux de service Flex Unifié, Standard, Premium et Extreme sont désormais compatibles avec le protocole NFSv4.2 en plus de NFSv4.1 sur les volumes pour lesquels NFSv4.1 est déjà activé.
Lors de l'installation d'un volume NFS, la commande d'installation Linux sélectionne automatiquement la version NFS la plus récente disponible. Le montage automatique d'un volume compatible avec NFSv4.1 est défini par défaut sur NFSv4.2, sauf si l'option de montage vers=4.1 est explicitement spécifiée.
NetApp Volumes est compatible avec les attributs étendus NFS xattrs avec NFSv4.2. L'utilisation et les limites de xattrs, telles que détaillées dans le TR-4962, s'appliquent également.
Connecter Linux à LDAP
Si vous utilisez des groupes étendus NFSv3 ou NFSv4.1 avec des identifiants de sécurité, vous avez configuré NetApp Volumes pour qu'il utilise votre Active Directory comme serveur LDAP à l'aide d'un Active Directory associé à un pool de stockage.
Pour que les informations utilisateur soient cohérentes entre le client et le serveur NFS, vous devrez peut-être configurer votre client pour qu'il utilise Active Directory comme service de nom LDAP pour les informations sur les utilisateurs et les groupes.
Utilisez les ressources suivantes pour configurer LDAP :
Lorsque vous utilisez NFS Kerberized, vous devrez peut-être utiliser les guides de déploiement mentionnés dans cette section pour configurer LDAP et assurer la cohérence entre le client et le serveur.
Étapes suivantes
Connectez des volumes de grande capacité avec plusieurs points de terminaison de stockage.