root 以外のユーザに対してアクセスを許可するには、特定のグループがソケットを所有し、アクセスできるように設定する必要があります (下記の例では、 libvirt グループに対して許可する例を示しています) 。この認証方式は、ローカルとリモートの SSH 接続で使用することができます。

Polkit を利用した Unix ソケット向けのアクセス制御は、ローカルからの接続における openSUSE Leap の既定の認証方式です。そのため、 libvirt 側の設定は不要です。 Polkit の認証方式を有効化していれば、両方のソケットに対するパーミッションは 0777 に設定され、ソケットにアクセスしようとするそれぞれのアプリケーション側で、 Polkit による認証が必要になります。

重要: Polkit の認証はローカル接続にのみ対応する件について

Polkit はリモートに対する認証には対応していませんので、 VM ホストサーバ 自身からのローカル接続にのみ使用することができます 。

libvirt のソケットへのアクセスに対しては、 2 種類のポリシーが存在しています:

既定では、読み書き可能なソケットに対するアクセスのポリシーは、 root のパスワード入力を一度だけ求め、その時点およびその後のセッションでは、そのまま権限を許可する設定になっています。

root のパスワードを入力させることなく、一般ユーザからソケットにアクセスできるようにするには、 /etc/polkit-1/rules.d 内にルールを作成する必要があります。たとえば /etc/polkit-1/rules.d/10-grant-libvirt ファイルを下記の内容で作成すると、 libvirt グループに所属する全てのメンバーに対して、ソケットへのアクセスを許可するようになります:

polkit.addRule(function(action, subject) {
  if (action.id == "org.libvirt.unix.manage" && subject.isInGroup("libvirt")) {
    return polkit.Result.YES;
  }
});

SASL はユーザ名とパスワードによる認証を提供する仕組みで、データの暗号化 (既定では digest-md5) にも対応しています。 SASL は独自のユーザデータベースを利用して認証を行う仕組みであるため、 VM ホストサーバ 内にユーザを作成する必要はありません。また、 SASL は TCP 接続を利用し、 TLS/SSL にも対応しています。

重要: digest-md5 暗号化による純粋な TCP と SASL による認証について

他の方法で TCP の接続が暗号化されていない限り、 digest-md5 暗号化による認証を行っても、本番環境では十分なセキュリティであるとは言えません。このような構成は、テスト環境でのみ使用することをお勧めします。

ヒント: TLS/SSL を利用した SASL 認証について

TLS/SSL によるリモートからのアクセスを許可する場合、 クライアント側で 証明書の鍵ファイルのアクセスを制限することで、間接的にアクセスを制御することができます。ただし、多くのクライアントを設定する場合、設定ミスを引き起こしやすい構成でもあります。 TLS による認証を行う際は、 SASL による認証も同時に行うものとして、サーバ側でも追加の制御を行うようにしてください。

SASL 認証を設定するには、下記の手順を実施します:

ヒント: virsh と SASL の認証の関係について

SASL 認証を使用している場合、 virsh コマンドで接続を行うと、毎回ユーザ名とパスワードを尋ねられるようになります。 virsh をシェルモードで動作させると、この手間を省くことができます。

SASL はユーザ名とパスワードによる認証を提供するだけでなく、データの暗号化の機能も提供します。また、 SASL は独自のデータベースを使用する方式であるため、 VM ホストサーバ 内にユーザを作成しておく必要もありません。 libvirt に対して SASL の認証を設定する場合、 TLS/SSL 接続を利用することもできます。これらの接続の設定方法について、詳しくは 11.3.2.4.2項 「VNC over TLS/SSL: クライアント設定」 をお読みください。

VNC 向けに SASL 認証を設定するには、下記の手順を実施します:

注記: 対応する VNC ビューアについて

現時点では、 SASL 認証は 仮想マシンマネージャ と virt-viewer でのみ対応しています。これらのビューアは、 TLS/SSL 接続にも対応しています。

VNC サーバへのアクセスは、パスワード単独での認証で制限することもできます。この場合、全ての VM ゲスト に対してグローバルパスワードを設定するか、それぞれのゲストに対して個別にパスワードを設定することができます。なお、後者は VM ゲスト の設定ファイル内に記述します。

注記: グローバルパスワードの設定について

パスワード単独で認証を設定する場合、それぞれの VM ゲスト に対してパスワードを設定している場合でも、グローバルパスワードを設定しておくことをお勧めします。これにより、マシンごとのパスワードを設定し忘れた場合でも、代替となるパスワードが設定されることになりますので、最低限の保護は実現することができます。なお、グローバルパスワードは、マシンに対してそれ以外のパスワードが設定されていない場合にのみ適用されます。

警告: VNC プロトコルのセキュリティについて

VNC プロトコルは安全なプロトコルであるとは考えられていません。パスワードは暗号化されて送信されるものの、暗号鍵と暗号化されたパスワードの両方を傍受することができてしまえば、解読できてしまう危険性があるためです。そのため、 TLS/SSL で別途暗号化を行って VNC 接続するか、 SSH の暗号化トンネルを介して接続することをお勧めします。 virt-viewer や 仮想マシンマネージャ, Remmina (詳しくは 4.2項 「Remmina: リモートデスクトップクライアント」 をお読みください) では、いずれの方式にも対応しています。

TLS (Transport Layer Security) では証明書を利用することで、 2 台のコンピュータ間の通信を暗号化します。接続を開始する側のコンピュータが常に 「クライアント」 となり、 「クライアント証明書」 を利用して接続を行います。また、接続を受け付ける側のコンピュータが常に 「サーバ」 となり、こちらも 「サーバ証明書」 を利用することになります。このような方式により、 VM ホストサーバ を中央のデスクトップから一括管理することができるようになっています。

どちらのコンピュータからも接続を行うような場合、双方がクライアント証明書とサーバ証明書の両方を持つ必要があります。これはたとえば、 VM ゲスト を一方のホストから他方のホストに移行させるような場合に当てはまります。

また、それぞれの x509 証明書には、対応する機密鍵ファイルが存在しています。証明書ファイルと機密鍵ファイルは一対で使用します。また、正しく証明書が認識されるようにするため、証明機関 (CA) と呼ばれる機関で署名され、発行された証明書を使用することをお勧めします。また、クライアントの証明書もサーバの証明書も、同じ CA から発行されているものでなければなりません。

重要: ユーザ認証について

TLS/SSL によるリモート接続は、 2 台のコンピュータ間で特定の方向で認証を行い、通信を確立する処理を行うためのものです。特定のユーザにのみアクセスを許可したい場合は、クライアント側で証明書にアクセスすることのできるユーザを制限してください。詳しくは 11.3.2.5項 「アクセス制限 (セキュリティ面の考慮事項)」 をお読みください。

libvirt では SASL を利用してサーバ側でユーザ認証を行うこともできます。こちらについては 11.3.2.6項 「TLS ソケット向けの SASL を利用した中央管理型ユーザ認証」 をお読みください。

VM ホストサーバ が接続を受け付ける側になります。そのため、 VM ホストサーバ には サーバ 証明書をインストールする必要があります。 CA の証明書もインストールする必要があります。証明書の準備を整えたら、 libvirt 側で TLS サポートを有効化することができます。

重要: TLS を有効化して libvirtd を再起動する場合の注意事項

libvirt で TLS を有効化した場合は、必ずサーバの証明書も設定しておいてください。証明書が設定されていないと、 libvirtd の再起動が失敗します。また、証明書を変更した場合も、 libvirtd の再起動が必要となります。

クライアントとは、接続を行うのことを指します。そのため、 クライアント 証明書をインストールする必要があります。また、 CA の証明書についてもインストールを行う必要があります。

現時点では、 TLS を利用した VNC 接続の暗号化は、少数のツールでしかサポートしていません。 tightvnc や tigervnc などの一般的な VNC ビューアは、 TLS/SSL に対応していません。 仮想マシンマネージャ と virt-viewer を除くと、 TLS/SSL に対応しているビューアは remmina のみとなります (詳しくは 4.2項 「Remmina: リモートデスクトップクライアント」 をお読みください) 。

11.3.2.4.2 VNC over TLS/SSL: クライアント設定 #Edit source

クライアント側でやるべきことは、選択したクライアントで認識される場所に、 x509 のクライアント証明書を配置するだけです。ただ残念なことに、 仮想マシンマネージャ と virt-viewer は、それぞれ別々の場所に証明書を配置する仕組みになっています。 仮想マシンマネージャ は全てのユーザに反映できるシステム全体の場所のほか、ユーザごとの個別の場所も用意されています。 Remmina (詳しくは 4.2項 「Remmina: リモートデスクトップクライアント」 をお読みください) では、リモートの VNC セッションの接続を開始する際に証明書の場所を尋ねます。

仮想マシンマネージャ (virt-manager)

リモートのホストに接続するには、まず 仮想マシンマネージャ を 11.3.2.3項 「クライアントの設定とテスト」 で説明している手順に従って設定する必要があります。 VNC で接続できるようにするには、クライアントの証明書をそれぞれ下記の場所に配置します:

システム全体に適用する場合の場所

/etc/pki/CA/cacert.pem

/etc/pki/libvirt-vnc/clientcert.pem

/etc/pki/libvirt-vnc/private/clientkey.pem

ユーザ単体で使用する場合の場所

/etc/pki/CA/cacert.pem

~/.pki/libvirt-vnc/clientcert.pem

~/.pki/libvirt-vnc/private/clientkey.pem

virt-viewer

virt-viewer では、下記の場所にあるシステム全体の設定のみを読み込みます:

/etc/pki/CA/cacert.pem

/etc/pki/libvirt-vnc/clientcert.pem

/etc/pki/libvirt-vnc/private/clientkey.pem

重要: 証明書へのアクセス制限について

11.3.2.5項 「アクセス制限 (セキュリティ面の考慮事項)」 で説明している内容に従って、証明書へのアクセスを制限するようにしてください。

x509 証明書は 2 つのものから作られています。 1 つは一般に公開する証明書そのもの、そしてそれに対応する機密鍵です。これらの両方を使用することで認証を行うことができる仕組みです。そのため、クライアント証明書と機密鍵にアクセスができてしまえば、あとは自由に VM ホストサーバ にアクセスできることになってしまいます。サーバ証明書の場合、証明書と機密鍵にアクセスできてしまえば、誰でも VM ホストサーバ になりすますことができてしまいます。このようなことが発生しないようにするため、少なくとも機密鍵については、できる限りアクセス制限を厳しく設定する必要があります。これを実現するのに最も簡単な方法は、アクセスパーミッションを利用してアクセスを制限する方法です。

tls_allowed_dn_list = [
   "C=US,L=Provo,O=SUSE Linux Products GmbH,OU=*,CN=venus.example.com,EMAIL=*",
   "C=DE,L=Nuremberg,O=SUSE Linux Products GmbH,OU=Documentation,CN=*"]

> certtool -i --infile /etc/pki/libvirt/clientcert.pem | grep "Subject:"

> sudo systemctl restart libvirtd

TLS では、直接的なユーザ認証を行うことはできません。実現するとすれば、 11.3.2.5項 「アクセス制限 (セキュリティ面の考慮事項)」 で説明している手順に従って、クライアント側で証明書に対する読み込みアクセス権 (パーミッション) を設定することができるくらいです。ただし、中央管理型でサーバベースのユーザ認証が必要となる場合、 libvirt では TLS 上で SASL (Simple Authentication and Security Layer) を使用するようにして、ユーザ認証を行うことができます。設定方法に関する詳細は、 11.1.1.3項 「SASL を利用したユーザ名とパスワードによる認証」 をお読みください。