Les autorisations bits du mode couvrent uniquement le propriétaire, le groupe et tous les autres éléments de la sémantique, ce qui signifie qu'aucun contrôle granulaire des accès utilisateur n'est mis en place pour les données NFSv3 de base. Google Cloud NetApp volumes ne prend pas en charge les listes de contrôle d'accès POSIX ni les attributs étendus (tels que chattr). Les listes de contrôle d'accès granulaires ne sont donc possibles que dans les scénarios suivants avec NFSv3 :

Les deux méthodes requièrent une connexion LDAP pour la gestion des identités UNIX et des informations valides sur les utilisateurs et les groupes UNIX (voir la section "« LDAP »") et sont disponibles uniquement avec les instances NetApp volumes-Performance. Pour utiliser des volumes de style de sécurité NTFS avec le protocole NFS, vous devez utiliser le protocole double (SMB et NFS v3) ou le double protocole (SMB et NFS v4.1), même si aucune connexion SMB n'est établie. Pour utiliser les listes de contrôle d'accès NFSv4.1 avec montages NFSv3, vous devez sélectionner Both (NFSv3/NFSv4.1) comme type de protocole.

Les bits standard en mode UNIX ne fournissent pas le même niveau de granularité dans les autorisations que les ACL NTFS ou NFSv4.x fournissent. Le tableau suivant compare la granularité des autorisations entre les bits en mode NFS v3 et les ACL NFSv4.1. Pour plus d'informations sur les listes de contrôle d'accès NFSv4.1, voir "Nfs4_acl - listes de contrôle d'accès NFSv4".

Enfin, l'appartenance au groupe NFS (dans NFSv3 et NFSV4.x) est limitée à un maximum par défaut de 16 pour AUTH_SYS selon les limites de paquets RPC. NFS Kerberos fournit jusqu'à 32 groupes et les ACL NFSv4 suppriment la limite par le biais de listes de contrôle d'accès granulaires des utilisateurs et des groupes (jusqu'à 1024 entrées par ACE).

De plus, Google Cloud NetApp volumes offre une prise en charge de groupe étendue pour étendre le nombre maximal de groupes pris en charge jusqu'à 32. Pour ce faire, une connexion LDAP à un serveur LDAP qui contient des identités d'utilisateur et de groupe UNIX valides est nécessaire. Pour plus d'informations sur cette configuration, reportez-vous à la section "Création et gestion des volumes NFS" de la documentation Google.

Avec NFSv3, le client et le serveur n'ont jamais à confirmer que l'utilisateur qui tente de lire ou d'écrire avec un ID numérique est un utilisateur valide ; il est simplement implicitement approuvé. Cela ouvre le système de fichiers jusqu'à des failles potentielles simplement en usurper n'importe quel ID numérique. Pour éviter des failles de sécurité de ce type, Google Cloud NetApp volumes propose plusieurs options.

En fin de compte, la sécurité NFS est limitée à la version de protocole que vous utilisez. NFS v3, bien que plus performant que NFSv4.1, n'offre pas le même niveau de sécurité.

En raison des fonctions de sécurité ajoutées dans NFSv4.1, certaines dépendances externes étaient impliquées dans l'utilisation de NFSv3 (semblable au mode d'utilisation requis par SMB, comme Active Directory).

Google Cloud NetApp volumes prend en charge les listes de contrôle d'accès NFSv4.x, qui offrent des avantages distincts par rapport aux autorisations de type POSIX normales, mais aussi les options suivantes :

Les ACL NFSv4 ne sont pas plus les ACL de niveau fichier (ACL NTFS) de Windows, mais possèdent une fonctionnalité similaire. Cependant, dans les environnements NAS multiprotocoles, si vous disposez de listes de contrôle d'accès NFSv4.1 et que vous utilisez un accès double protocole (NFS et SMB sur les mêmes datasets), les clients qui utilisent SMB2.0 et versions ultérieures ne pourront pas afficher ni gérer les listes de contrôle d'accès à partir des onglets de sécurité Windows.

Pour référence, les termes suivants sont définis :

Lorsqu'un client définit une liste de contrôle d'accès NFSv4.1 sur un fichier lors d'une opération SETATTR, Google Cloud NetApp volumes définit cette liste de contrôle d'accès sur l'objet, en remplacement de toute liste de contrôle d'accès existante. S'il n'y a pas de liste de contrôle d'accès sur un fichier, les autorisations de mode sur ce fichier sont calculées à partir DE OWNER@, GROUP@ et EVERYONE@. S'il existe des SUID/SGID/bits COLLANTS sur le fichier, ils ne sont pas affectés.

Lorsqu'un client obtient une liste de contrôle d'accès NFSv4.1 sur un fichier au cours d'une opération GETATTR, Google Cloud NetApp volumes lit la liste de contrôle d'accès NFSv4.1 associée à l'objet, construit une liste d'ACE et renvoie la liste au client. Si le fichier possède une liste de contrôle d’accès NT ou des bits de mode, une liste de contrôle d’accès est construite à partir de bits de mode et renvoyée au client.

L'accès est refusé si une ACE DE REFUS est présente dans la liste de contrôle d'accès ; l'accès est accordé si une ACE D'AUTORISATION existe. Toutefois, l'accès est également refusé si aucun des ACE n'est présent dans l'ACL.

Un descripteur de sécurité se compose d'une liste de contrôle d'accès (SACL) et d'une liste de contrôle d'accès discrétionnaire (DACL). Lorsque NFSv4.1 interagit avec CIFS/SMB, le DACL est mappé à NFSv4 et CIFS. La DACL se compose des ACCE AUTORISER et REFUSER.

Si un niveau de base chmod Est exécuté sur un fichier ou un dossier avec les ACL NFSv4.1 définies, les listes de contrôle d'accès utilisateur et groupe existantes sont conservées, mais le PROPRIÉTAIRE par défaut@, GROUPE@, EVERYONE@ ACL sont modifiés.

Un client utilisant des listes de contrôle d’accès NFSv4.1 peut définir et afficher des listes de contrôle d’accès pour les fichiers et les répertoires du système. Lorsqu'un nouveau fichier ou sous-répertoire est créé dans un répertoire comportant une liste de contrôle d'accès, cet objet hérite de tous les ACE de la liste de contrôle d'accès qui ont été marqués avec le nom approprié "indicateurs d'héritage".

Si un fichier ou un répertoire possède une liste de contrôle d'accès NFSv4.1, cette liste de contrôle d'accès est utilisée pour contrôler l'accès, quel que soit le protocole utilisé pour accéder au fichier ou au répertoire.

Les fichiers et les répertoires héritent des ACE des listes de contrôle d'accès NFSv4 sur les répertoires parents (éventuellement avec les modifications appropriées) tant que les ACE ont été balisés avec les indicateurs d'héritage corrects.

Lorsqu'un fichier ou un répertoire est créé à la suite d'une requête NFSv4, la liste de contrôle d'accès du fichier ou répertoire résultant dépend du fait que la demande de création de fichier inclut une liste de contrôle d'accès ou uniquement les autorisations d'accès aux fichiers UNIX standard. La liste de contrôle d’accès dépend également de la présence ou non d’une liste de contrôle d’accès dans le répertoire parent.

Les autorisations de listes de contrôle d'accès NFSv4.1 utilisent une série de valeurs de lettres majuscules et minuscules (par exemple rxtncy) pour contrôler l'accès. Pour plus d'informations sur ces valeurs de lettre, reportez-vous à la section "COMMENT : utiliser NFSv4 ACL".

"Les ACL NFSv4 permettent d'offrir l'héritage ACL". L'héritage ACL signifie que les fichiers ou les dossiers créés sous des objets avec des listes de contrôle d'accès NFSv4.1 peuvent hériter des listes de contrôle d'accès basées sur la configuration du "Indicateur d'héritage ACL".

"Umask" est utilisé pour contrôler le niveau d'autorisation auquel les fichiers et dossiers sont créés dans un répertoire sans intervention de l'administrateur. Par défaut, Google Cloud NetApp volumes permet à umask de remplacer les listes de contrôle d'accès héritées, ce qui correspond au comportement attendu par "RFC 5661".

Les ACL NFSv4.1 ont un formatage spécifique. L'exemple suivant est un ensemble ACE sur un fichier :

L'exemple précédent suit les directives de format ACL de :

Un type de A signifie « autoriser ». Les indicateurs hériter ne sont pas définis dans ce cas, car le principal n'est pas un groupe et n'inclut pas l'héritage. De plus, comme l'ACE n'est pas une entrée D'AUDIT, il n'est pas nécessaire de définir les indicateurs d'audit. Pour plus d'informations sur les listes de contrôle d'accès NFSv4.1, voir "http://linux.die.net/man/5/nfs4_acl".

Si la liste de contrôle d’accès NFSv4.1 n’est pas définie correctement (ou si une chaîne de nom ne peut pas être résolue par le client et le serveur), la liste de contrôle d’accès peut ne pas se comporter comme prévu, ou si la modification de la liste de contrôle d’accès échoue à s’appliquer et générer une erreur.

Les exemples d'erreurs sont les suivants :

Les autorisations NFSv4.1 peuvent inclure des attributs DE REFUS explicites pour LE PROPRIÉTAIRE, LE GROUPE et TOUT LE MONDE. En effet, les listes de contrôle d’accès NFSv4.1 étant des listes de contrôle d’accès par défaut, ce qui signifie que si une liste de contrôle d’accès n’est pas explicitement accordée par une ACE, elle est alors refusée. Les attributs DE REFUS explicite remplacent les ACE D'ACCÈS, explicites ou non.

LES ACE DE REFUS sont définis avec une balise d'attribut de D.

Dans l'exemple ci-dessous, GROUP@ est autorisé à toutes les autorisations de lecture et d'exécution, mais a refusé tout accès en écriture.

DANS la mesure du possible, LES ACE DE REFUS doivent être évités parce qu'ils peuvent être confus et compliqués ; AUTORISER les listes de contrôle d'accès qui ne sont pas explicitement définies sont refusées implicitement. Lorsque LES ACE DE REFUS sont définis, les utilisateurs peuvent se voir refuser l'accès lorsqu'ils s'attendent à bénéficier de l'accès.

L'ensemble précédent d'ACE est équivalent à 755 bits de mode, ce qui signifie :

Cependant, même si les autorisations sont ajustées à l'équivalent 775, l'accès peut être refusé en raison du REFUS explicite défini sur TOUT LE MONDE.

NFSv4.1 s'appuie sur la logique de mappage de domaine d'ID en tant que couche de sécurité pour garantir qu'un utilisateur qui tente d'accéder à un montage NFSv4.1 est en effet celui qu'il prétend être. Dans ce cas, le nom d'utilisateur et le nom de groupe provenant du client NFSv4.1 ajoute une chaîne de nom et l'envoie à l'instance Google Cloud NetApp volumes. Si cette combinaison nom d'utilisateur/groupe et chaîne d'ID ne correspond pas, l'utilisateur et/ou le groupe sont écrasés par l'utilisateur par défaut spécifié dans le /etc/idmapd.conf fichier sur le client.

Cette chaîne d'ID est une exigence pour le respect correct des autorisations, en particulier lorsque des ACL NFSv4.1 et/ou Kerberos sont utilisés. Par conséquent, des dépendances au serveur de service de noms, telles que les serveurs LDAP, sont nécessaires pour assurer la cohérence entre les clients et Google Cloud NetApp volumes afin de garantir une résolution correcte des identités de nom d'utilisateur et de groupe.

Google Cloud NetApp volumes utilise une valeur de nom de domaine à ID statique par défaut de defaultv4iddomain.com. Les clients NFS utilisent par défaut le nom de domaine DNS pour ses paramètres de nom de domaine ID, mais vous pouvez ajuster manuellement l'ID nom de domaine dans /etc/idmapd.conf.

Si LDAP est activé dans Google Cloud NetApp volumes, Google Cloud NetApp volumes automatise le domaine d'ID NFS afin de modifier ce qui est configuré pour le domaine de recherche dans DNS. Il n'est donc pas nécessaire de modifier les clients sauf s'ils utilisent des noms de recherche de domaine DNS différents.

Lorsque Google Cloud NetApp volumes peut résoudre un nom d'utilisateur ou de groupe dans des fichiers locaux ou LDAP, la chaîne de domaine est utilisée et les ID de domaine non correspondants sont mis à jour avec personne. Si Google Cloud NetApp volumes ne trouve pas de nom d'utilisateur ou de groupe dans les fichiers locaux ou LDAP, la valeur de l'ID numérique est utilisée et le client NFS résout le nom correctement (fonctionnalité similaire à celle de NFSv3).

Sans modifier le domaine d'ID NFSv4.1 du client pour correspondre à ce que le volume Google Cloud NetApp volumes utilise, vous observez le comportement suivant :

Voici les résultats du scénario précédent :

Lorsque les domaines d'ID client et serveur correspondent, voici l'apparence de la même liste de fichiers :

Pour plus d'informations sur ce problème et sur la façon de le résoudre, reportez-vous à la section «NFSv4.1 et personne utilisateur/groupe. »

Si vous prévoyez d'utiliser Kerberos avec NFS, vous devez disposer des éléments suivants avec Google Cloud NetApp volumes :

L'un des problèmes les plus courants rencontrés avec une configuration NFSv4.1 est lorsqu'un fichier ou un dossier est affiché dans une liste à l'aide de ls appartenant au user:group combinaison de nobody:nobody.

Par exemple :

Et l'ID numérique est 99.

Dans certains cas, le fichier peut indiquer le propriétaire correct, mais nobody en tant que groupe.

Qui n'est personne?

Le nobody L'utilisateur dans NFSv4.1 est différent de nfsnobody utilisateur. Vous pouvez afficher la manière dont un client NFS voit chaque utilisateur en exécutant le id commande :

Avec NFSv4.1, le nobody l'utilisateur est l'utilisateur par défaut défini par le idmapd.conf et peut être défini comme n'importe quel utilisateur que vous voulez utiliser.

Pourquoi cela se produit-il ?

Étant donné que la sécurité par mappage de chaînes de noms est un principe clé des opérations NFSv4.1, le comportement par défaut lorsqu'une chaîne de noms ne correspond pas correctement est de court-courser cet utilisateur à un utilisateur qui n'aura normalement pas accès aux fichiers et dossiers appartenant aux utilisateurs et aux groupes.

Lorsque vous voyez nobody Pour l'utilisateur et/ou le groupe dans les listes de fichiers, cela signifie généralement que quelque chose dans NFSv4.1 est mal configuré. La sensibilité de la casse peut être ici en jeu.

Par exemple, si utilisateur1@CVSDEMO.LOMEDRY (uid 1234, gid 1234) accède à une exportation, Google Cloud NetApp volumes doit être en mesure de trouver utilisateur1@CVSDEMO.LO2L (uid 1234, gid 1234). Si l'utilisateur des volumes Google Cloud NetApp est USER1@CVSDEMO.LOMEDERL, il ne correspond pas (UTILISATEUR1 en majuscules contre UTILISATEUR1 en minuscules). Dans de nombreux cas, vous pouvez voir ce qui suit dans le fichier de messages sur le client :

Le client et le serveur doivent accepter que l'utilisateur soit effectivement ce qu'il prétend être. Vous devez donc vérifier les points suivants pour vous assurer que l'utilisateur voit bien les mêmes informations que l'utilisateur voit dans Google Cloud NetApp volumes.

Dans la plupart des cas, si vous voyez nobody dans les listes d'utilisateurs et de groupes de clients, le problème est la traduction de l'ID de domaine du nom d'utilisateur ou de groupe entre Google Cloud NetApp volumes et le client NFS. Pour éviter ce scénario, utilisez LDAP pour résoudre les informations d'utilisateur et de groupe entre les clients et Google Cloud NetApp volumes.

Si vous utilisez NFSv4.1, un mappage de chaîne de nom a lieu lors des opérations NFS, comme décrit précédemment.

En plus de l'utilisation /var/log/messages Pour trouver un problème avec les ID NFSv4, vous pouvez utiliser le "nfsidmap -l" Commande sur le client NFS pour afficher les noms d'utilisateur qui sont correctement mappés au domaine NFSv4.

Par exemple, il s'agit du résultat de la commande lorsqu'un utilisateur trouvé par le client et que Google Cloud NetApp volumes accède à un montage NFSv4.x :

Lorsqu'un utilisateur qui ne se mappe pas correctement dans le domaine ID NFSv4.1 (dans ce cas, netapp-user) essaie d'accéder au même montage et touche un fichier, ils sont affectés nobody:nobody, comme prévu.

Le nfsidmap -l la sortie affiche l'utilisateur pcuser à l'écran, mais pas netapp-user; il s'agit de l'utilisateur anonyme dans notre règle d'export-policy (65534).