Connetti i client NFS

Questa pagina descrive come connettere i client NFS.

Prima di iniziare

Se utilizzi un firewall per controllare il traffico di rete e vuoi consentire il traffico NFS, consulta Regole firewall per l'accesso ai volumi NFS.

Installa gli strumenti client NFS in base al tipo di distribuzione Linux per preparare il client:

RedHat

Esegui questo comando:

sudo yum install -y nfs-utils

SuSe

Esegui questo comando:

sudo yum install -y nfs-utils

Debian

Esegui questo comando:

sudo apt-get install nfs-common

Ubuntu

Esegui questo comando:

sudo apt-get install nfs-common

Controllo dell'accesso ai volumi tramite le policy di esportazione

Il controllo dell'accesso ai volumi in NFSv3 e NFSv4.1 si basa sull'indirizzo IP del client. La policy di esportazione del volume contiene fino a 20 regole di esportazione. Ogni regola è un elenco separato da virgole di indirizzi IP o CIDR di rete che definiscono i client consentiti abilitati a montare il volume. Una regola definisce anche il tipo di accesso dei client, ad esempio Lettura e scrittura o Sola lettura.

Utilizza le seguenti schede per esaminare le policy in base alle versioni NFS:

NFS senza Kerberos

Tutte le versioni NFS senza Kerberos utilizzano il tipo di sicurezza AUTH_SYS. In questa modalità, devi gestire attentamente le regole di esportazione per consentire solo ai client di cui ti fidi e che possono garantire l'integrità dell'ID utente e dell'ID gruppo.

Come misura di sicurezza, i server NFS mappano automaticamente le chiamate NFS con UID=0 (root) a UID=65534 (anonimo), che ha autorizzazioni limitate sul file system. Per saperne di più, consulta Compressione dell'ID utente.

NFSv4.1 con Kerberos

NFSv4.1 con Kerberos utilizza le policy di esportazione e l'autenticazione aggiuntiva tramite Kerberos per accedere ai volumi. Puoi configurare le regole di esportazione da applicare a:

  • Solo Kerberos (krb5)

  • Firma Kerberos (krb5i)

  • Privacy Kerberos (krb5p)

Best practice per le policy di esportazione

Consigliamo le seguenti best practice per le policy di esportazione:

  • Ordina le regole di esportazione dalla più specifica alla meno specifica.

  • Esporta solo ai client attendibili, ad esempio client o CIDR specifici con i client attendibili.

  • Limita l'accesso root a un piccolo gruppo di client di amministrazione attendibili.

Regola Client consentiti Accesso Accesso root Descrizione
1 10.10.5.3,
10.10.5.9		 Lettura e scrittura On Client di amministrazione. L'utente root rimane root e può gestire
tutte le autorizzazioni dei file.
2 10.10.5.0/24 Lettura e scrittura Off Tutti gli altri client della rete 10.10.5.0/24 sono autorizzati a montare,
ma l'accesso root viene mappato a nessuno.
3 10.10.6.0/24 Sola lettura Off Un'altra rete è autorizzata a leggere i dati dal volume, ma
non a scriverli.

Dopo che un client monta un volume, l'accesso a livello di file determina le azioni consentite a un utente. Per saperne di più, consulta Controllo dell'accesso a livello di file NFS per i volumi in stile UNIX.

Gestire le policy di esportazione

Utilizza le seguenti istruzioni per aggiornare la policy di esportazione di un volume utilizzando Google Cloud CLI.

gcloud

Aggiornare un volume con una policy di esportazione

Aggiorna un volume con una regola della policy di esportazione:

gcloud netapp volumes update VOLUME_ID \
  --project=PROJECT_ID \
  --location=LOCATION \
  --export-policy=access-type=ACCESS_TYPE,allowed-clients=ALLOWED_CLIENTS_IP_ADDRESSES,has-root-access=TRUE_OR_FALSE,nfsv3=NFSV3,nfsv4=NFSV4

Sostituisci le seguenti informazioni:

  • VOLUME_ID: l'ID del volume.

  • PROJECT_ID: il nome del progetto in cui si trova il volume.

  • LOCATION: la località del volume.

  • ACCESS_TYPE: il tipo di accesso deve essere uno tra READ_WRITE, READ_ONLY o READ_NONE.

  • ALLOWED_CLIENTS_IP_ADDRESSES: un elenco di indirizzi IP o intervalli di client consentiti separati da virgole.

  • NFSV3: imposta su true o false per applicare questa regola a NFSv3.

  • NFSV4: imposta su true o false per applicare questa regola a NFSv4.

Aggiungere più regole della policy di esportazione

Per aggiungere più regole di esportazione, ripeti il blocco di parametri export-policy. Ogni blocco di parametri export-policy è costituito da più coppie chiave-valore nel seguente formato:

--export-policy=KEY1=VALUE1,KEY2=VALUE2,KEY3=VALUE3...

Esempio: utilizzo di due punti e virgola come separatore

Se specifichi più indirizzi IP o CIDR per allowed-clients, Google Cloud CLI potrebbe non analizzare correttamente i valori perché il flag --export-policy utilizza le virgole come separatore predefinito tra chiavi diverse come access-type e nfsv3. Se un valore, ad esempio allowed-clients, contiene anche virgole, l'analizzatore non può distinguere tra una nuova coppia chiave-valore e un indirizzo IP aggiuntivo nell'elenco allowed-clients. Per distinguere queste virgole, configura Google Cloud CLI in modo che utilizzi un separatore di parametri diverso con l'escape di Google Cloud CLI.

Il comando seguente mostra l'esempio di Best practice per le policy di esportazione. La prima regola utilizza i due punti come separatore di parametri per analizzare correttamente l'elenco allowed-clients separato da virgole. La seconda e la terza regola utilizzano la virgola predefinita come separatore.

gcloud netapp volumes update my_volume --location=us-east4 \
--export-policy=^:^access-type=READ_WRITE:allowed-clients="10.10.5.3,10.10.5.9":nfsv3=true:nfsv4=true:has-root-access=true \
--export-policy=access-type=READ_WRITE,allowed-clients=10.0.5.0/24,nfsv3=true,has-root-access=false \
--export-policy=access-type=READ_ONLY,allowed-clients=10.0.6.0/24,nfsv3=true,has-root-access=false

Esempio: utilizzo di squash-mode come parametro

L'esempio seguente utilizza il parametro alternativo squash-mode per creare una regola NO_ROOT_SQUASH per gli host amministratori e una regola ALL_SQUASH per un intervallo CIDR.

gcloud netapp volumes update my_volume --location=us-east4 \
--export-policy=^:^allowed-clients="10.10.5.3,10.10.5.9":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

Per saperne di più sui flag facoltativi aggiuntivi, consulta SDK Google Cloud per la policy di esportazione dei volumi.

Compressione dell'ID utente

Le policy di esportazione NFS forniscono controlli per la compressione dell'ID utente e dell'ID gruppo, che consente di rimappare gli ID utente e gruppo a un ID utente anonimo per motivi di sicurezza.

Compressione root

I server NFS migliorano la sicurezza rimappando l'utente root (UID=0) a nessuno (UID=65534), il che rende root un utente senza privilegi per l'accesso ai file sul volume. Questa funzionalità è nota come compressione root. L'opzione per disattivarla e mantenere i privilegi di root è chiamata no_root_squash sui server NFS.

Per impostazione predefinita, i volumi senza una policy di esportazione definita non sono accessibili agli indirizzi IP client. Quando crei una regola della policy di esportazione nella Google Cloud console, le impostazioni predefinite includono l'accesso Lettura e scrittura e la compressione root. In precedenza, l' Google Cloud API, Google Cloud CLI e Terraform supportavano il controllo della compressione root utilizzando il parametro has-root-access. Sebbene has-root-access sia ancora accettato, è stato sostituito dal parametro squash-mode.

Come best practice, crea una regola di esportazione dedicata che abiliti l'accesso root per gli host amministratori attendibili e disabiliti l'accesso root per gli altri client. Inserisci questa regola per prima, prima delle regole più generiche.

Compressione dell'ID utente e dell'ID gruppo

Il parametro squash-mode consente di controllare la compressione degli ID utente e gruppo in un UID anonimo, che può essere utile per le directory casella personale SFTP pubbliche. Questo parametro sostituisce anche il parametro has-root-access ed è supportato dall'API, da Google Cloud CLI e da Terraform.

Il parametro squash-mode accetta i seguenti valori:

  • no-root-squash: in questa modalità, l'utente root rimane root e non viene rimappato a nessuno (UID=65534).

  • root-squash: questa impostazione rimappa l'utente root a nessuno.

  • all-squash: questa opzione fornisce l'accesso anonimo a tutti gli utenti, inclusa la root. Tutti gli utenti vengono rimappati all'UID e al GID specificati dal parametro anon-uid. Quando utilizzi all-squash, devi anche specificare anon-uid e impostare access-type su READ_WRITE.

Considerazioni

Tieni presente quanto segue per le regole della policy di esportazione con squash mode:

  • Una policy di esportazione supporta una sola regola all-squash.

  • Quando all-squash è abilitato, l'utente root viene compresso in anonimo. Questa impostazione può essere sostituita da una regola con priorità più alta che utilizza no-root-squash.

  • La replica dei volumi non è supportata per i volumi con una regola della policy di esportazione in stile squash-mode.

  • Per il livello di servizio Flex File, all-squash non modifica automaticamente la proprietà dell'inode root del volume. Per ottenere questo risultato, aggiungi una regola di esportazione no-root-squash, che consente all'utente root di utilizzare chown per modificare la proprietà dell'inode root nell'UID richiesto.

  • Il parametro has-root-access è supportato. Utilizza has-root-access o squash-mode; non utilizzare entrambi i parametri contemporaneamente.

  • Per il livello di servizio Flex Unified, all-squash non è supportato.

Istruzioni di montaggio per i client NFS

Utilizza le seguenti istruzioni per ottenere le istruzioni di montaggio per i client NFS utilizzando la Google Cloud console, Google Cloud CLI o la modalità ONTAP.

Console

  1. Nella Google Cloud console, vai alla pagina NetApp Volumes.

    Vai a NetApp Volumes

  2. Fai clic su Volumi.

  3. Fai clic su Mostra altro.

  4. Seleziona Istruzioni di montaggio.

  5. Segui le istruzioni di montaggio visualizzate nella Google Cloud console.

  6. Identifica il comando di montaggio e utilizza le opzioni di montaggio, a meno che il tuo workload non abbia requisiti specifici per le opzioni di montaggio.

    Solo NFSv3: se la tua applicazione non utilizza i blocchi o non hai configurato i client per abilitare la comunicazione NSM, ti consigliamo di aggiungere l'opzione di montaggio nolock.

gcloud

Cerca le istruzioni di montaggio per un volume:

 gcloud netapp volumes describe VOLUME_NAME \
    --project=PROJECT_ID \
    --location=LOCATION \
    --format="value(mountOptions.instructions)"

Sostituisci le seguenti informazioni:

  • VOLUME_NAME: il nome del volume.

  • PROJECT_ID: il nome del progetto in cui si trova il volume.

  • LOCATION: la località del volume.

Per saperne di più sui flag facoltativi aggiuntivi, consulta la documentazione dell'SDK Google Cloud sui volumi.

Modalità ONTAP

Segui questi passaggi per identificare il nome host o l'indirizzo IP del volume e il percorso di esportazione:

  1. Cerca tutte le interfacce di rete per il servizio data_cifs.

  2. Determina il percorso di esportazione, che corrisponde al percorso di giunzione specificato per il volume.

  3. Crea il percorso di montaggio nel formato <var>IP</var>:<var>junction-path</var>. Aggiungi le opzioni di montaggio richieste.

Dopo aver identificato i comandi richiesti, consulta la modalità ONTAP per istruzioni su come inviare i comandi ONTAP al pool di archiviazione.

Istruzioni aggiuntive per NFSv4.1

Quando abiliti NFSv4.1 per i volumi dei livelli di servizio Flex Unified, Standard, Premium ed Extreme, NFSv4.2 viene abilitato automaticamente per questi volumi. Il comando di montaggio Linux monta sempre la versione NFS più alta disponibile, a meno che tu non specifichi la versione da montare. Se vuoi eseguire il montaggio con NFSv4.1, utilizza il parametro -o vers=4.1 nel comando di montaggio.

In NFSv3, utenti e gruppi vengono identificati da ID utente (UID) e ID gruppo (GID) inviati tramite il protocollo NFSv3. È importante assicurarsi che lo stesso UID e GID rappresentino lo stesso utente e gruppo su tutti i client che accedono al volume. NFSv4 ha eliminato la necessità di una mappatura esplicita di UID e GID utilizzando gli identificatori di sicurezza. Gli identificatori di sicurezza sono stringhe formattate come <username|groupname>@<full_qualified_domain>. Un esempio di identificatore di sicurezza è bob@example.com. Il client deve tradurre gli UID e i GID utilizzati internamente in un identificatore di sicurezza prima di inviare una richiesta NFSv4 al server. Il server deve tradurre gli identificatori di sicurezza in UID e GID per una richiesta in entrata e viceversa per la risposta. Il vantaggio dell'utilizzo delle traduzioni è che ogni client e il server possono utilizzare UID e GID interni diversi. Tuttavia, lo svantaggio è che tutti i client e il server devono mantenere un elenco di mappatura tra UID e GID e nomi di utenti e gruppi. Le informazioni di mappatura sui client possono provenire da file locali come /etc/passwd e /etc/groups o da una directory LDAP. La configurazione di questa mappatura è gestita da rpc.idmapd, che deve essere eseguita sul client.

In NetApp Volumes, LDAP deve fornire informazioni di mappatura, con Active Directory come unico server LDAP compatibile con RFC2307bis supportato. Quando utilizzi Kerberos per NFSv4, l'identificatore di sicurezza memorizza le entità Kerberos nel formato username@DOMAINNAME, dove DOMAINNAME (in lettere maiuscole) diventa il nome del realm.

ID numerici

Per gli utenti che non vogliono configurare le mappature dei nomi e utilizzano invece NFSv4 come sostituzione di NFSv3, NFSv4 ha introdotto un'opzione chiamata numeric ID, che invia stringhe di testo codificate UID e GID come identificatori di sicurezza. Questo semplifica la procedura di configurazione per gli utenti.

Puoi controllare l'impostazione del client utilizzando il seguente comando:

     cat /sys/module/nfs/parameters/nfs4_disable_idmapping

Il valore predefinito è Y, che abilita gli ID numerici. NetApp Volumes supporta l'utilizzo di ID numerici.

Configurare rpc.idmapd sul client NFS

Indipendentemente dal tipo di ID o identificatori di sicurezza utilizzati, è necessario configurare rpc.idmapd sul client NFS. Se hai seguito le istruzioni di installazione per le utilità client nella sezione Prima di iniziare , dovrebbe essere già installato, ma potrebbe non essere in esecuzione. Alcune distribuzioni lo avviano automaticamente utilizzando systemd quando monti i primi volumi NFS. La configurazione minima richiesta per rpc.idmapd è la configurazione dell'impostazione del dominio. In caso contrario, l'utente root verrà visualizzato come nessuno con UID=65534 or 4294967295.

Utilizza le seguenti istruzioni per configurare rpc.idmapd sul client NFS:

  1. Sul client, apri il file /etc/idmapd.conf e modifica il parametro del dominio in uno dei seguenti:

    • Se il volume non è abilitato per LDAP, domain = defaultv4iddomain.com.

    • Se il volume è abilitato per LDAP, domain = <FDQN_of_Windows_Domain>.

  2. Attiva le modifiche a rpc.idmapd eseguendo il comando seguente:

     nfsidmap -c

Supporto di NFSv4.2

I livelli di servizio Flex Unified, Standard, Premium ed Extreme ora supportano il protocollo NFSv4.2 oltre a NFSv4.1 sui volumi per cui è già abilitato NFSv4.1.

Quando monti un volume NFS, il comando di montaggio Linux seleziona automaticamente la versione NFS più alta disponibile. Il montaggio di un volume abilitato per NFSv4.1 utilizza automaticamente NFSv4.2 come impostazione predefinita, a meno che non venga specificata esplicitamente l'opzione di montaggio vers=4.1.

NetApp Volumes supporta gli attributi estesi NFS xattrs con NFSv4.2. Si applicano anche l'utilizzo e le limitazioni di xattrs, come descritto in TR-4962, sono anche applicabili.

Regole firewall per l'accesso ai volumi NFS

NFS utilizza più porte per comunicare tra il client e un server. Per la comunicazione tra Google Compute Engine e NetApp Volumes, queste porte non sono bloccate per impostazione predefinita. Se utilizzi un firewall, devi abilitare l'accesso alle seguenti porte per l'intero CIDR PSA di NetApp Volume o per i singoli indirizzi IP del volume:

  • 111 TCP/UDP portmapper

  • 635 TCP/UDP mountd

  • 2049 TCP/UDP nfsd

  • 4045 TCP/UDP nlockmgr (solo per NFSv3)

  • 4046 TCP/UDP status (solo per NFSv3)

Gli indirizzi IP per NetApp Volumes vengono assegnati automaticamente dall'intervallo CIDR assegnato al servizio durante il peering di rete. Per saperne di più, consulta Configurare l'accesso privato ai servizi.

Utilizzo dei blocchi di avviso con NFSv3

Se utilizzi i blocchi di avviso con NFSv3, devi eseguire il daemon rpc.statd sul client per supportare Network Lock Manager, che funziona con NFS per fornire il blocco di file e record di avviso in stile System V sulla rete. Il client NFS deve aprire una porta in entrata per rpc.statd per ricevere i callback di Network Lock Manager. Nella maggior parte delle distribuzioni Linux, rpc.statd viene avviato quando monti la prima condivisione NFS. Utilizza una porta casuale che puoi identificare utilizzando il comando rpcinfo -p. Per rendere rpc.statd compatibile con i firewall, configuralo in modo che utilizzi una porta statica.

Per impostare le porte statiche per rpc.statd, consulta le seguenti risorse:

Se non utilizzi i blocchi di avviso NFSv3 o Network Lock Manager, puoi montare le condivisioni NFSv3 con l'opzione di montaggio nolock.

NFSv4.1 implementa la funzione di blocco all'interno del protocollo NFSv4.1, che viene eseguito sulla connessione TCP avviata dal client al server NFSv4.1 sulla porta 2049. Il client non deve aprire le porte firewall per il traffico in entrata.

Connettere Linux a LDAP

Se utilizzi i gruppi estesi NFSv3 o NFSv4.1 con identificatori di sicurezza, hai configurato NetApp Volumes in modo che utilizzi Active Directory come server LDAP utilizzando un Active Directory collegato a un pool di archiviazione.

Per mantenere informazioni utente coerenti tra client e server NFS, potrebbe essere necessario configurare il client in modo che utilizzi Active Directory come servizio di nomi LDAP per le informazioni su utenti e gruppi.

Utilizza le seguenti risorse per configurare LDAP:

Quando utilizzi NFS con Kerberos, potrebbe essere necessario utilizzare le guide al deployment menzionate in questa sezione per configurare LDAP e garantire la coerenza tra client e server.

Passaggi successivi

Connetti volumi di capacità elevata con più endpoint di archiviazione.