NFS/Kerberos

Kerberos は NFS に利用可能な数少ないセキュリティメカニズムの一つです。Kerberos は強力なユーザー認証とデータ暗号化を提供し、NFSv4 を使用することでクライアントとサーバー間の UIDs/GIDs の一致が不要になります。

Kerberos には NFSv4 が推奨されます。NFSv3 で Kerberos を有効にすることは可能ですが、補助的な NFSv3 プロトコル（例えば「マウント」プロトコル）がセキュアでないため、100% のカバレッジは提供されません。また、NFSv3 には idmapping がないため、Kerberos の使用性が大幅に低下します。

前提条件

Kerberos は KDC （Key Distribution Center）サービスがどこかで動作している必要があります。MIT Kerberos （krb5）に付属する krb5-kdc.service は、Active Directory や FreeIPA のような複雑さが必要ない小規模設定に適しています。2 番目のオプションは Heimdal で、一部の BSD や Arch 上の heimdal^AUR で見つかります。

Kerberos と共に NFSv4 の idmapping がとても重要になります。サーバーとクライアントはどちらも同じ idmapping ドメインを設定している必要があります：

/etc/idmapd.conf

[General]
Domain = example.com

サーバーの設定

各 NFS サーバーは、KDC 上に nfs/server.fqdn の Kerberos プリンシパルを作成し、その鍵をサーバーの /etc/krb5.keytab に追加する必要があります。

ノート:

It is recommended to also have the standard host/ principal there as well, for other purposes.

fileserv# kadmin -p frob/admin
Password for frob/admin@EXAMPLE.COM: *********
kadmin:  addprinc -nokey nfs/fs.example.com
kadmin:  ktadd nfs/fs.example.com

サーバー上で gssproxy.service を有効化し開始する必要があります。

ヒント: 以前のシステムでは rpc.svcgssd を使用していましたが、現代の nfs-utils には存在せず、gssproxy に完全に置き換えられています。

gssproxy は NFS サーバーのサポートで事前に設定されています（標準パッケージの一部として /etc/gssproxy/24-nfs-server.conf ファイルが含まれています）そして、NFS サービスの keytab を標準の場所に置く以外に調整する必要はありません。

/etc/exports では、sec= オプションで Kerberos 認証フレーバーを提供する必要があります：

/home    *(rw,sec=krb5p)
/usr     10.147.0.0/16(rw,sec=krb5p:krb5i:krb5:sys) *(rw,sec=krb5p)

ノート: 廃止された gss/krb5p(...) 構文を使用しないでください。まだ動作しますが、もはや使用すべきではありません。

利用可能なフレーバーは以下の通りです：

• krb5p は「プライバシー」（Kerberos ベースの暗号化）を提供します。インターネット上で使用するには十分なセキュリティですが、LAN 上でのスループットが低下する可能性があるため、RPC-with-TLS 内で krb5 を使用することを検討してください。
• krb5i は「完全性」（Kerberos ベースの MAC）を提供しますが、暗号化は提供しません。パケット改ざんから保護するため、静的データを提供する際に有用かもしれません。
• krb5 は認証のみを提供し、データの完全性や暗号化はありません。RPC-over-TLS を xprtsec= を通じて有効化している、または Kerberos をそれ自体「安全な」LAN（例：WireGuard トンネルを通じて）上で運用している場合は良い選択ですが、公開ネットワーク上でクリアな状態で使用するのは避けてください。
• sys は従来の UID ベース（非 Kerberos）の NFS セキュリティモードです。

Client configuration

In addition to users, each NFS client should have a machine Kerberos principal in /etc/krb5.keytab, which will be used in situations where user Kerberos tickets are not yet available – in particular, it will be needed to actually mount the filesystem at boot time before any users have logged in yet (or if mounting is done via autofs). More generally, all operations done "as root" will be authenticated as the machine principal.

ヒント: The machine identity is also mandatory for some internal NFS operations if NFSv4.0 or NFSv4.1 are used, although no longer mandatory in NFSv4.2.

Unlike in the server case, the client machine does not need an nfs/ principal specifically – it is enough to have the generic host/the.fqdn principal. (See the rpc.gssd manual page for what it looks for.)

The client must have rpc-gssd.service active (i.e. the rpc.gssd daemon).

Options used when mounting the filesystems are very similar to the options used in /etc/exports; you can specify one or more flavors using the sec= option. Although the client will automatically use the strongest mode offered, it is nevertheless recommended to explicitly require e.g. sec=krb5p to prevent downgrade attacks.

Once the filesystem has been mounted, root may already access it (using the machine's Kerberos credentials), but every non-root user needs their own Kerberos tickets to be present. This means either having the user manually run kinit for themselves, or setting up pam-krb5 to acquire tickets during login (which only works for password-based logins), or using gssproxy or k5start(1) (from kstart^AUR) to acquire tickets from a keytab file.

ヒント: You will likely need to set up k5start to renew tickets as they expire a few hours after being acquired.