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

Les deux méthodes nécessitent une connexion LDAP pour la gestion des identités UNIX et des informations d'utilisateur et de groupe UNIX valides renseignées (voir la section"LDAP" ) et ne sont disponibles qu'avec les instances NetApp Volumes-Performance. Pour utiliser des volumes de style de sécurité NTFS avec NFS, vous devez utiliser un double protocole (SMB et NFSv3) ou un double protocole (SMB et NFSv4.1), même si aucune connexion SMB n'est établie. Pour utiliser les ACL NFSv4.1 avec les montages NFSv3, vous devez sélectionner Both (NFSv3/NFSv4.1) comme type de protocole.

Les bits de mode UNIX standard ne fournissent pas le même niveau de granularité dans les autorisations que les ACL NTFS ou NFSv4.x. Le tableau suivant compare la granularité des autorisations entre les bits du mode NFSv3 et les ACL NFSv4.1. Pour plus d'informations sur les ACL NFSv4.1, consultez "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 conformément aux limites des paquets RPC. NFS Kerberos fournit jusqu'à 32 groupes et les ACL NFSv4 suppriment la limitation au moyen d'ACL utilisateur et groupe granulaires (jusqu'à 1024 entrées par ACE).

De plus, Google Cloud NetApp Volumes fournit une prise en charge de groupe étendue pour étendre le nombre maximal de groupes pris en charge jusqu'à 32. Cela nécessite une connexion LDAP à un serveur LDAP contenant des identités d'utilisateur et de groupe UNIX valides. Pour plus d'informations sur la configuration de ceci, voir "Création et gestion des volumes NFS" dans la documentation Google.

Avec NFSv3, le client et le serveur n'ont jamais besoin de confirmer que l'utilisateur qui tente une lecture ou une écriture avec un ID numérique est un utilisateur valide ; il est simplement implicitement approuvé. Cela ouvre le système de fichiers à des violations potentielles simplement en usurpant un identifiant numérique. Pour éviter des failles de sécurité comme celle-ci, plusieurs options sont disponibles pour Google Cloud NetApp Volumes.

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

En raison des fonctionnalités de sécurité supplémentaires de NFSv4.1, certaines dépendances externes sont impliquées et n'étaient pas nécessaires pour utiliser NFSv3 (de la même manière que SMB nécessite des dépendances telles qu'Active Directory).

Google Cloud NetApp Volumes prend en charge les ACL NFSv4.x, qui offrent des avantages distincts par rapport aux autorisations de style POSIX normales, tels que les suivants :

Les ACL NFSv4 sont différentes des ACL au niveau des fichiers Windows (ACL NTFS) mais possèdent des fonctionnalités similaires. Cependant, dans les environnements NAS multiprotocoles, si des ACL NFSv4.1 sont présentes et que vous utilisez un accès à double protocole (NFS et SMB sur les mêmes ensembles de données), les clients utilisant SMB2.0 et versions ultérieures ne pourront pas afficher ou gérer les ACL à partir des onglets de sécurité Windows.

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

Lorsqu'un client définit une ACL NFSv4.1 sur un fichier lors d'une opération SETATTR, Google Cloud NetApp Volumes définit cette ACL sur l'objet, remplaçant toute ACL existante. S'il n'y a pas d'ACL sur un fichier, les autorisations de mode sur le fichier sont calculées à partir de OWNER@, GROUP@ et EVERYONE@. S'il existe des bits SUID/SGID/STICKY sur le fichier, ils ne sont pas affectés.

Lorsqu'un client obtient une ACL NFSv4.1 sur un fichier au cours d'une opération GETATTR, Google Cloud NetApp Volumes lit l'ACL 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 est renvoyée au client.

L'accès est refusé si un DENY ACE est présent dans l'ACL ; l'accès est accordé si un ALLOW ACE existe. Cependant, 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 ACL de sécurité (SACL) et d'une ACL discrétionnaire (DACL). Lorsque NFSv4.1 interagit avec CIFS/SMB, la DACL est mappée un à un avec NFSv4 et CIFS. La DACL se compose des ACE ALLOW et DENY.

Si une base chmod est exécuté sur un fichier ou un dossier avec des ACL NFSv4.1 définies, les ACL d'utilisateur et de groupe existantes sont conservées, mais les ACL par défaut OWNER@, GROUP@, EVERYONE@ sont modifiées.

Un client utilisant les ACL NFSv4.1 peut définir et afficher les ACL pour les fichiers et les répertoires du système. Lorsqu'un nouveau fichier ou sous-répertoire est créé dans un répertoire qui possède une ACL, cet objet hérite de toutes les ACE de l'ACL qui ont été marquées avec l' "drapeaux d'héritage" .

Si un fichier ou un répertoire possède une ACL NFSv4.1, cette ACL 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 ACL NFSv4 sur les répertoires parents (éventuellement avec les modifications appropriées) à condition que les ACE aient été marqués avec les indicateurs d'héritage corrects.

Lorsqu'un fichier ou un répertoire est créé à la suite d'une demande NFSv4, l'ACL sur le fichier ou le répertoire résultant dépend du fait que la demande de création de fichier inclut une ACL ou uniquement des autorisations d'accès aux fichiers UNIX standard. L'ACL dépend également du fait que le répertoire parent possède ou non une ACL.

Les autorisations ACL NFSv4.1 utilisent une série de valeurs de lettres majuscules et minuscules (telles que rxtncy ) pour contrôler l'accès. Pour plus d'informations sur ces valeurs de lettres, voir "COMMENT FAIRE : Utiliser l'ACL NFSv4" .

"Les ACL NFSv4 offrent la possibilité d'offrir l'héritage ACL" . L'héritage ACL signifie que les fichiers ou dossiers créés sous des objets avec des ACL NFSv4.1 définies peuvent hériter des ACL en fonction de la configuration du "Drapeau d'héritage ACL" .

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

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

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

Un type de A signifie « permettre ». Les indicateurs d'héritage 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 AUDIT, il n'est pas nécessaire de définir les indicateurs d'audit. Pour plus d'informations sur les ACL NFSv4.1, consultez "http://linux.die.net/man/5/nfs4_acl" .

Si l'ACL 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), l'ACL peut ne pas se comporter comme prévu ou la modification de l'ACL peut ne pas s'appliquer et générer une erreur.

Les exemples d’erreurs incluent :

Les autorisations NFSv4.1 peuvent inclure des attributs DENY explicites pour OWNER, GROUP et EVERYONE. C'est parce que les ACL NFSv4.1 sont refusées par défaut, ce qui signifie que si une ACL n'est pas explicitement accordée par une ACE, elle est refusée. Les attributs DENY explicites remplacent tous les ACE d'ACCÈS, explicites ou non.

Les ACE DENY sont définis avec une balise d'attribut de D .

Dans l'exemple ci-dessous, GROUP@ dispose de toutes les autorisations de lecture et d'exécution, mais se voit refuser tout accès en écriture.

Les ACE DENY doivent être évités autant que possible car ils peuvent être déroutants et compliqués ; les ACL ALLOW qui ne sont pas explicitement définies sont implicitement refusées. Lorsque les ACE DENY sont définis, l'accès peut être refusé aux utilisateurs alors qu'ils s'attendent à ce qu'il leur soit accordé.

L'ensemble d'ACE précédent équivaut à 755 en 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 DENY explicite défini sur TOUT LE MONDE.

NFSv4.1 exploite la logique de mappage de domaine d'ID comme couche de sécurité pour aider à vérifier qu'un utilisateur tentant d'accéder à un montage NFSv4.1 est bien celui qu'il prétend être. Dans ces cas, le nom d'utilisateur et le nom de groupe provenant du client NFSv4.1 ajoutent une chaîne de nom et l'envoient à l'instance Google Cloud NetApp Volumes . Si cette combinaison de nom d'utilisateur/nom de groupe et de chaîne d'identification ne correspond pas, l'utilisateur et/ou le groupe est alors écrasé par l'utilisateur nobody par défaut spécifié dans le /etc/idmapd.conf fichier sur le client.

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

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

Si LDAP est activé dans Google Cloud NetApp Volumes, Google Cloud NetApp Volumes automatise le domaine d'ID NFS pour le modifier en fonction de ce qui est configuré pour le domaine de recherche dans DNS et les clients n'auront pas besoin d'être modifiés, 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 un nom de groupe dans des fichiers locaux ou LDAP, la chaîne de domaine est utilisée et les ID de domaine non correspondants sont écrasés sur personne. Si Google Cloud NetApp Volumes ne parvient pas à trouver un nom d'utilisateur ou un nom de groupe dans les fichiers locaux ou LDAP, la valeur d'ID numérique est utilisée et le client NFS résout correctement le nom (ceci est similaire au comportement NFSv3).

Sans modifier le domaine d'ID NFSv4.1 du client pour qu'il corresponde à celui utilisé par le volume Google Cloud NetApp Volumes , vous voyez le comportement suivant :

Ce qui suit montre les résultats du scénario précédent :

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

Pour plus d'informations sur ce problème et comment le résoudre, consultez la section «NFSv4.1 et l'utilisateur/groupe nobody ."

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 comme étant la propriété de user:group combinaison de nobody:nobody .

Par exemple:

Et l'ID numérique est 99 .

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

Qui n'est personne ?

Le nobody l'utilisateur dans NFSv4.1 est différent du nfsnobody utilisateur. Vous pouvez voir comment 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 fichier et peut être défini comme n'importe quel utilisateur que vous souhaitez utiliser.

Pourquoi cela arrive-t-il ?

Étant donné que la sécurité via le 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 transférer cet utilisateur vers un utilisateur qui n'aura normalement aucun accès aux fichiers et dossiers appartenant aux utilisateurs et aux groupes.

Quand tu vois 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é à la casse peut entrer en jeu ici.

Par exemple, si user1@CVSDEMO.LOCAL (uid 1234, gid 1234) accède à une exportation, Google Cloud NetApp Volumes doit pouvoir trouver user1@CVSDEMO.LOCAL (uid 1234, gid 1234). Si l'utilisateur dans Google Cloud NetApp Volumes est USER1@CVSDEMO.LOCAL, il ne correspondra pas (USER1 majuscule contre user1 minuscule). Dans de nombreux cas, vous pouvez voir ce qui suit dans le fichier de messages sur le client :

Le client et le serveur doivent tous deux convenir qu'un utilisateur est bien celui qu'il prétend être. Vous devez donc vérifier les éléments suivants pour vous assurer que l'utilisateur que le client voit dispose des mêmes informations que l'utilisateur que Google Cloud NetApp Volumes voit.

Dans presque tous les cas, si vous voyez nobody dans les listes d'utilisateurs et de groupes des 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 utilisateur et groupe entre les clients et Google Cloud NetApp Volumes.

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

En plus d'utiliser /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 correctement mappés au domaine NFSv4.

Par exemple, voici la sortie de la commande après qu'un utilisateur qui peut être trouvé par le client et Google Cloud NetApp Volumes accède à un montage NFSv4.x :

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

Le nfsidmap -l la sortie montre à l'utilisateur pcuser dans l'affichage mais pas netapp-user ; il s'agit de l'utilisateur anonyme dans notre règle de politique d'exportation(65534 ).