プベウム(1)

システムのルート・ユーザーは、Linux PAMレルムを介して常にログインでき、制約のない管理者です。このユーザは削除できませんが、属性は変更できます。システムメールはこのユーザに割り当てられたメールアドレスに送信されます。

Linux PAM はホスト・システム・ユーザーに対応するため、ユーザーがログインを許可される各ノードにシステム・ユーザーが存在する必要があります。ユーザーは通常のシステムパスワードで認証します。このレルムはデフォルトで追加され、削除することはできません。設定可能な点では、管理者はレルムからのログインで二要素認証を要求したり、レルムをデフォルトの認証レルムとして設定したりすることができます。

Proxmox VE認証サーバのレルムは、シンプルなUnixライクなパスワードストアです。 レルムはデフォルトで作成され、Linux PAMと同様に、利用可能な設定項目は、レルムのユーザに二要素認証を要求する機能と、ログイン時のデフォルトレルムとして設定する機能のみです。

他のProxmox VEレルムタイプとは異なり、ユーザは他のシステムに対して認証するのではなく、Proxmox VEを通じて作成および認証されます。したがって、このタイプのユーザーは作成時にパスワードを設定する必要があります。

ユーザ認証に外部LDAPサーバを使用することもできます(OpenLDAPなど)。このレルム・タイプでは、ユーザはユーザ属性名(user_attr)フィールドで指定されたユーザ名属性を使用して、ベース・ドメイン名(base_dn)の下で検索されます。

サーバーとオプションのフォールバック・サーバーを設定し、SSLで接続を暗号化することができます。さらに、ディレクトリとグループに対してフィルタを設定することができます。フィルタにより、レルムの範囲をさらに制限することができます。

例えば、あるユーザーが次のようなLDIFデータセットで表現されているとします：

ベース・ドメイン名はou=People,dc=ldap-test,dc=comで、ユーザ属性はuidです。

Proxmox VE がユーザーを照会および認証する前に LDAP サーバーに認証 (バインド) する必要がある場合、/etc/pve/domains.cfg のbind_dnプロパティでバインド ドメイン名を構成できます。そのパスワードは、/etc/pve/priv/ldap/<realmname>.pw(例えば、/etc/pve/priv/ldap/my-ldap.pw) に格納する必要があります。このファイルには、生のパスワードを1行で記述します。

証明書を検証するには、capath を設定する必要があります。LDAPサーバのCA証明書を直接設定するか、信頼されたCA証明書を含むシステムパス(/etc/ssl/certs)を設定することができます。 さらに、verifyオプションを設定する必要があり、これはウェブインターフェイス上でも行うことができます。

LDAPサーバ・レルムの主な設定オプションは以下のとおりです：

Microsoft ADをレルムとして設定するには、サーバアドレスと認証ドメインを指定する必要があります。Active Directoryは、オプションのフォールバックサーバ、ポート、SSL暗号化など、LDAPと同じプロパティのほとんどをサポートしています。 さらに、設定後、 同期操作によってユーザをProxmox VEに自動的に追加することができます。

LDAPと同様に、Proxmox VEがADサーバにバインドする前に認証が必要な場合は、バインド・ユーザ（bind_dn）プロパティを構成する必要があります。このプロパティは通常、Microsoft ADではデフォルトで必要です。

Microsoft Active Directoryの主な構成設定は以下のとおりです：

LDAP ベースのレルム(LDAP & Microsoft Active Directory)のユーザーとグループを Proxmox VE に手動で追加するのではなく、自動的に同期することができます。 同期オプションには、Web インターフェイスのAuthenticationパネルの Add/Edit ウィンドウ、またはpveum realm add/modifyコマンドからアクセスできます。その後、GUI のAuthenticationパネルから、または以下のコマンドを使用して同期操作を実行できます：

ユーザとグループはクラスタ全体の構成ファイル/etc/pve/user.cfg に同期されます。

OpenID Connectの主な設定オプションは以下のとおりです：

スマートフォンやセキュリティーキーを紛失してアカウントから永久にロックされる事態を避けるため、複数のセカンドファクターを設定することができます。

レルム強制 TOTP、YubiKey OTP に加え、以下の二要素認証が利用可能です：

WebAuthn がサポートされる前は、U2F はユーザーが設定できました。既存のU2Fファクターは引き続き使用できますが、サーバー上で設定された後は、WebAuthnに切り替えることをお勧めします。

これは、認証レルムを追加または編集する際に、TFAドロップダウン・ボックスで利用可能な方法の1つを選択することで行うことができます。 レルムがTFAを有効にすると、それが要件となり、TFAが設定されたユーザのみがログインできるようになります。

現在、2つの方法があります：

YubiCloudを使用する方法、または独自の認証サーバをホストする方法については、YubiKey OTPのドキュメントを参照してください。

第二の要因は、パスワードが何らかの形で漏れたり推測されたりした場合に、ユーザーを保護するためのものです。しかし、いくつかの要素は総当たりで破られる可能性があります。このため、第2要素によるログインに何度も失敗すると、ユーザーはロックアウトされます。

TOTPの場合、8回失敗すると、ユーザーのTOTPファクターは無効になります。回復キーでログインすると解除されます。TOTP が唯一の利用可能な要素であった場合、管理者の介入が必要であり、ユーザに直ちにパスワードの変更を要求することが強く推奨されます。

FIDO2/Webauthnとリカバリキーはブルートフォースアタックの影響を受けにくいため、リミットは高くなりますが（100回）、それを超えるとすべてのセカンドファクターが1時間ブロックされます。

管理者は、UIのユーザーリストまたはコマンドラインから、いつでもユーザーの二要素認証を解除することができます：

ユーザは、ログイン時にTOTPまたはWebAuthnを第二要素として有効にするかどうかを、ユーザ一覧のTFAボタンから選択できます (レルムがYubiKey OTP を強制している場合を除く)。

ユーザーはいつでも1回限りのリカバリキーを追加して使用することができます。

TFAウィンドウを開くと、TOTP認証を設定するためのダイアログが表示されます。Secret」フィールドには鍵を入力します。鍵は「Randomize」ボタンでランダムに生成することができます。ほとんどのTOTPアプリは、発行者名と対応するOTP値を表示します。ユーザ名はTOTPアプリの QR コードにも含まれます。

キーを生成すると、FreeOTP などのほとんどの OTP アプリで使用できる QR コードが表示されます。その後、ユーザーは、現在のユーザーパスワード（root としてログインしている場合を除く）と、TOTPキーを正しく使用できることを、現在のOTP値を検証コードフィールドに入力して適用ボタンを押すことで確認する必要があります。

サーバーの設定は不要です。スマートフォンにTOTPアプリ（例えばFreeOTP）をインストールし、Proxmox VEのウェブインターフェースを使用してTOTPファクターを追加するだけです。

WebAuthnを動作させるには、2つのものが必要です：

これらの両方の要件を満たすと、[Datacenter] → [Permissions] → [Two Factor] の[Two Factor]パネルで WebAuthn 設定を追加できます。

データセンター → 権限 → Two FactorのTwo Factorパネルで回復キーのセットを作成するだけです。

ユーザーがWebAuthn認証を使用できるようにするには、有効な SSL 証明書を持つ有効なドメインを使用する必要があります。

これは/etc/pve/datacenter.cfgで行います。例えば

ユーザーがU2F認証を使用できるようにするには、有効なSSL証明書を持つ有効なドメインを使用する必要がある場合があります。そうでない場合、ブラウザによっては警告が表示されたり、U2Fの使用を完全に拒否したりする場合があります。最初に、AppId
[AppIdhttps://developers.yubico.com/U2F/App_ID.html]
を設定する必要があります。

これは/etc/pve/datacenter.cfgで行います。例えば

1つのノードの場合、AppIdは単純にウェブインターフェースのアドレスで、ブラウザで使用されているものと全く同じで、上記のようにhttps://、ポートも含みます。ブラウザによっては、AppIdのマッチングが他のブラウザよりも厳しい場合があることに注意してください。

複数のノードを使用する場合、appid.json
[Multi-facet apps:https://developers.yubico.com/U2F/App_ID.html]
ファイルを提供する別のhttpsサーバーを用意するのが、ほとんどのブラウザと互換性があるようです。すべてのノードが同じトップレベルドメインのサブドメインを使用している場合、AppId として TLD を使用すれば十分かもしれません。ただし、ブラウザによってはこれを受け入れない場合があることに注意してください。

U2F認証を有効にするには、TFAウィンドウのU2Fタブを開き、現在のパスワードを入力し（rootでログインしていない場合）、Registerボタンを押します。 サーバーが正しく設定され、ブラウザがサーバーから提供されたAppIdを受け入れると、U2Fデバイスのボタンを押すよう促すメッセージが表示されます（YubiKeyの場合、ボタンのランプが1秒間に約2回、安定して点滅するはずです）。

FirefoxユーザーはU2Fトークンを使う前にabout:configで security.webauth.u2fを有効にする必要があるかもしれません。

ロールは単に権限のリストです。Proxmox VEには定義済みのロールが多数用意されており、ほとんどの要件を満たすことができます。

GUIで定義済みのロール一式を見ることができます。

GUIまたはコマンドラインから新しいロールを追加できます。

GUIからDatacenterの Permissions → Rolesタブに移動し、Createボタンをクリックします。そこでロール名を設定し、Privilegesドロップダウンメニューから必要な権限を選択できます。

コマンドラインからロールを追加するには、例えばpveumCLIツールを使用します：

権限とは、特定のアクションを実行する権利のことです。管理を簡単にするために、権限のリストはロールにグループ化されます。権限はロールの一部でなければユーザやパスに直接割り当てることができないことに注意してください。

現在、以下の特権をサポートしています：

アクセス許可は、仮想マシン、ストレージ、リソースプールなどのオブジェクトに割り当てられます。 ファイルシステムのようなパスを使用して、これらのオブジェクトにアクセスします。これらのパスは自然なツリーを形成し、上位レベル（より短いパス）のパーミッションは、オプションでこの階層内に伝搬することができます。

パスはテンプレート化できます。API 呼び出しがテンプレート化されたパスのパーミッションを必要とする場合、パスには API 呼び出しのパラメータへの参照が含まれることがあります。こ れ ら の参照は中かっ こ で指定 し ます。一部のパラメータは、APIコールのURIから暗黙的に取得されます。例えば、/nodes/mynode/status を呼び出すときのパーミッションパス/nodes/{node}は、/nodes/mynode のパーミッションを必要とし、/access/aclへの PUT 要求のパス{path}は、メソッドのパスパラメータを参照します。

いくつか例を挙げましょう：

プールを使用すると、仮想マシンとデータストアのセットをグループ化できます。そして、プール(/pool/{poolid}) にパーミッションを設定するだけで、そのパーミッションはすべてのプールメンバーに継承されます。これは、アクセス制御を簡素化する素晴らしい方法です。

必要なAPI権限は個々のメソッドごとに文書化されており、https://pve.proxmox.com/pve-docs/api-viewer/。

パーミッションはリストとして指定され、ロジックとアクセスチェック関数のツリーとして解釈できます：

管理者が、（rootアカウントを使わずに）完全な管理者権限を持つユーザーグループを作りたいと思うことはあり得ます。

そのためには、まずグループを定義します：

次に役割を割り当てます：

最後に、新しい管理者グループにユーザーを追加します：

PVEAuditorロールをユーザーまたはグループに割り当てることで、ユーザーに読み取り専用アクセス権を与えることができます。

例 1: ユーザjoe@pveにすべてを表示することを許可します。

例 2: ユーザjoe@pveにすべての仮想マシンを表示できるようにします。

ユーザ管理をユーザjoe@pveに委譲したい場合は、次のようにします：

ユーザjoe@pveはユーザの追加と削除、パスワードなどのユーザ属性の変更ができるようになりました。これは非常に強力なロールであり、選択されたレルムとグループに制限したい場合がほとんどでしょう。以下の例では、joe@pveはレルムpve内のユーザを変更することができます：

APIトークンの権限は、常に対応するユーザの権限のサブセットです。つまり、APIトークンを使用して、バックユーザが権限を持たないタスクを実行することはできません。このセクションでは、トークン所有者の権限をさらに制限するために、別の権限を持つAPIトークンを使用する方法を示します。

すべてのVMで、ユーザーjoe@pveにロールPVEVMAdminを与えます：

別の権限を持つ新しいAPIトークンを追加します。このAPIトークンは、VM情報の表示のみ許可されます（監視目的など）：

ユーザーとトークンの権限を確認します：

通常、企業はいくつかの小さな部門に分かれており、それぞれの部門にリソースを割り当てたり、管理タスクを委任したりするのが一般的です。ここでは、ソフトウェア開発部門のためのプールを設定したいとします。まず、グループを作成します：

次に、そのグループのメンバーである新しいユーザーを作成します：

そして、開発部門が使用するリソース・プールを作成します：

最後に、そのプールに権限を割り当てることができます：

当社のソフトウェア開発者は、そのプールに割り当てられたリソースを管理できるようになりました。