Вопросы Теги

Ограничить доступ к виртуальным машинам KVM для определенных пользователей

На моем сервере у меня есть виртуальная машина KVM под названием «cards2». Он был создан путем выполнения (от имени root): 

# virt-install --connect qemu:///system --virt-type kvm --name cards2 --ram 2048 --disk /var/kvm/cards2.qcow,size=3 --vcpus=8 --cdrom /var/kvm/debian-8.5.0-amd64-netinst.iso --vnc --os-type linux --network network=default

Образ имеет разрешения: 

# ls -l /var/kvm/cards2.qcow 
-rwxr-xr-x 1 libvirt-qemu libvirt-qemu 3221225472 Aug 17 18:49 /var/kvm/cards2.qcow

Однако я заметил, что любой пользователь с доступом SSH может получить доступ к виртуальной машине, выполнив: 

virt-viewer --connect qemu+ssh://username@hostname.example.com/system vmname

(Обратите внимание, эта команда выполняется удаленно , а не на сервере. Это подключается к гипервизору с помощью URI подключения qemu + ssh: // эта команда выполняется удаленно , а не на сервере. Это подключается к гипервизору с URI подключения qemu + ssh: // эта команда выполняется удаленно , а не на сервере. Это подключается к гипервизору с URI подключения qemu + ssh: //username@hostname.example.com путем туннелирования через SSH)

Пользователь имя пользователя является только членом группы имя пользователя . При использовании SSH с учетной записью имя пользователя список виртуальных машин кажется пустым: 

$ virsh list --all
 Id    Name                           State
----------------------------------------------------

И я также не могу подключиться через сокет при выполнении следующих действий по SSH: 

$ virsh --connect qemu:///system list --all
error: Failed to connect socket to '/var/run/libvirt/libvirt-sock': Permission denied

Я также попытался удалить права доступа ко всем файлам / usr / bin / vir * для пользователей, не входящих в группу kvm : 

# chown root:kvm /usr/bin/vir*
# chmod o-rx /usr/bin/vir*
# ls /usr/bin/vir* -l
-rwxr-x--- 1 root kvm  321120 Jul  1 04:46 /usr/bin/virsh
-rwxr-x--- 1 root kvm   32184 Dec  7  2013 /usr/bin/virt-alignment-scan
-rwxr-x--- 1 root kvm   28128 Dec  7  2013 /usr/bin/virt-cat
-rwxr-x--- 1 root kvm    9774 Sep 29  2014 /usr/bin/virt-clone
-rwxr-x--- 1 root kvm   10277 Sep 29  2014 /usr/bin/virt-convert
-rwxr-x--- 1 root kvm     806 Dec  7  2013 /usr/bin/virt-copy-in
-rwxr-x--- 1 root kvm     808 Dec  7  2013 /usr/bin/virt-copy-out
-rwxr-x--- 1 root kvm   54584 Dec  7  2013 /usr/bin/virt-df
-rwxr-x--- 1 root kvm   33312 Dec  7  2013 /usr/bin/virt-edit
-rwxr-x--- 1 root kvm   54536 Dec  7  2013 /usr/bin/virt-filesystems
-rwxr-x--- 1 root kvm   30112 Dec  7  2013 /usr/bin/virt-format
-rwxr-x--- 1 root kvm   14656 Jul  1 04:46 /usr/bin/virt-host-validate
-rwxr-x--- 1 root kvm    7944 Sep 29  2014 /usr/bin/virt-image
-rwxr-x--- 1 root kvm   44696 Dec  7  2013 /usr/bin/virt-inspector
-rwxr-x--- 1 root kvm   36992 Sep 29  2014 /usr/bin/virt-install
-rwxr-x--- 1 root kvm    5338 Dec  7  2013 /usr/bin/virt-list-filesystems
-rwxr-x--- 1 root kvm    6686 Dec  7  2013 /usr/bin/virt-list-partitions
-rwxr-x--- 1 root kvm   53816 Dec  7  2013 /usr/bin/virt-ls
-rwxr-x--- 1 root kvm   18641 Dec  7  2013 /usr/bin/virt-make-fs
-rwxr-x--- 1 root kvm    9600 Jul  1 04:46 /usr/bin/virt-pki-validate
-rwxr-x--- 1 root kvm   36264 Dec  7  2013 /usr/bin/virt-rescue
-rwxr-x--- 1 root kvm 1322488 Dec  7  2013 /usr/bin/virt-resize
-rwxr-x--- 1 root kvm 1231256 Dec  7  2013 /usr/bin/virt-sparsify
-rwxr-x--- 1 root kvm 1289592 Dec  7  2013 /usr/bin/virt-sysprep
-rwxr-x--- 1 root kvm    8949 Dec  7  2013 /usr/bin/virt-tar
-rwxr-x--- 1 root kvm     804 Dec  7  2013 /usr/bin/virt-tar-in
-rwxr-x--- 1 root kvm     806 Dec  7  2013 /usr/bin/virt-tar-out
-rwxr-x--- 1 root kvm      55 Jul 12  2012 /usr/bin/virtualenv
-rwxr-x--- 1 root kvm  132400 May 28  2012 /usr/bin/virt-viewer
-rwxr-x--- 1 root kvm   23886 Dec  7  2013 /usr/bin/virt-win-reg
-rwxr-x--- 1 root kvm    3531 Jul  1 04:46 /usr/bin/virt-xml-validate

И хотя теперь я не могу получить доступ ни к одной из этих команд через обычный SSH-соединение, я все еще могу вызвать виртуальную машину, запустив virt-viewer удаленно (как указано выше) через туннель SSH.

Итак, как я могу сделать так, чтобы только определенные учетные записи пользователей имели доступ к виртуальные машины?

Edit:

Here ' drive = drive-ide0-1-0, id = ide0-1-0 -netdev tap, fd = 23, id = hostnet0 -device rtl8139, netdev = hostnet0, id = net0, mac = 52: 54: 00: c6: 14: 68, bus = pci.0, addr = 0x3 -chardev pty, id = charserial0 -device isa-serial, chardev = charserial0, id = serial0 -vnc 127.0.0.1:3 -vga cirrus -device virtio-balloon-pci , id = balloon0, bus = pci.0, addr = 0x4

Edit 2:

С другой стороны, это проблема только для virt-viewer , а не для ] virsh .

Например, вот некоторые команды, выполняемые на удаленном клиенте: 

$ virsh --connect qemu+ssh://unauthorized-user@server.com/system
error: failed to connect to the hypervisor
error: End of file while reading data: nc: unix connect failed: Permission denied: Input/output error

$ virsh --connect qemu+ssh://authorized-user@server.com/system
Welcome to virsh, the virtualization interactive terminal.

Type:  'help' for help with commands
       'quit' to quit
4
задан 18 August 2016 в 07:37
3 ответа

K Понял. virt-viewer не взаимодействует с libvirtd - он соединяется по ssh с хостом и устанавливает туннель для доступа к виртуальным дисплеям VNC ваших ВМ (127.0.0.1:5903 в моем случае). Это трудно исправить, если не установить межсетевой экран VNC на 127.0.0.1. В противном случае обычные пользователи обычно могут делать TCP соединения с localhost. Я понятия не имею, как вы можете разрешить только root, возможно, есть способ.

Возможно, это делает selinux?

Linux: Allow/restricted IP bind permissions by user

Так что проще всего было бы установить VNC пароль. Вы могли бы сделать такие вещи, как ограничение переадресации и X11forwarding в SSH, но это может быть не на 100% безопасно, и может вызвать проблему и для root. И пользователи все еще могут получить доступ к 127.0.0.1/vnc после входа в систему.

Обновление

По словам Майка (другой ответ) и Майкла Хэмптона (комментарии), вы можете использовать TLS для связи с VNC, а не пароль, так что вы получите довольно приличную безопасность, если пароли не достаточно хороши для вас. Реквизиты к ним обоим, я понятия не имел.

http://wiki.libvirt.org/page/VNCTLSSetup

и

https://www.suse.com/documentation/sles11/book_kvm/data/sec_libvirt_connect_remote.html#sec_libvirt_connect_remote_tls

3
ответ дан 3 December 2019 в 03:16

Как ответ Райана говорит выше, «virt-viewer не взаимодействует с libvirtd». libvirtd и VNC (к которому подключается virt-viewer) имеют полностью отдельные методы аутентификации . VNC может быть защищен с помощью

  • аутентификации с одним паролем
  • аутентификации SASL
  • сертификатов x509
  • сертификатов комбинации и одного из первых двух

одиночных паролей

Если используется один пароль, это может быть либо глобальный пароль, хранящийся в вашем файле /etc/libvirt/qemu.conf , либо вы можете добавить пароль для конкретной виртуальной машины в конфигурацию виртуальной машины: 

<graphics type='vnc' port='-1' autoport='yes' passwd='PASSWORD'/>

Обратите внимание, эти пароли должны храниться в виде обычного текста.

Аутентификация SASL

Это позволяет использовать несколько комбинаций имени пользователя и пароля для каждой виртуальной машины. Пароли также хешируются, в отличие от отдельных паролей, которые хранятся в виде обычного текста. Инструкции см. Здесь .

сертификаты x509

Это фактически та часть, которая , как мне кажется, напрямую отвечает на вопрос (однако я не тестировал ее). Благодаря этому вы можете ограничить, какой пользователь может подключаться к экземпляру VNC, аутентифицируясь с помощью сертификатов, хранящихся на сервере. Чтобы отозвать разрешения для определенного пользователя или группы, просто установите разрешения для общесистемного файла сертификата клиента, чтобы этот пользователь не мог его прочитать. Вы также можете сгенерировать сертификаты для каждого пользователя и отозвать доступ.

К сожалению, это относительно сложно настроить. Он включает в себя сначала создание корневого центра сертификации на сервере , Создание сертификатов клиента / сервера x509 , настройку сервера , настройку клиента и тестирование установки. , а затем ограничение доступа .

1
ответ дан 3 December 2019 в 03:16

Вы пробовали использовать polkit для ограничения доступа пользователей? Я тоже хотел сделать это, поэтому в итоге получил следующий результат:

  1. Назовите виртуальную машину имя пользователя * vmname

  2. теперь в файле правил polkit отредактируйте правило, как показано ниже 

     function myFunction (username, virtualmachine  ) {
  var arr = virtualmachine.split ("*");
  if (arr [0] == имя пользователя) {
  вернуть истину;
  }
  else {
  вернуть ложь;
  }
 }
 // Разрешить беспарольное подключение к системе qemu: ///
polkit.addRule (функция (действие, тема) {
  если (action.id == "org.libvirt.unix.manage")
  {
  вернуть polkit.Result.YES;
  }
 });
 // Предоставляем полный доступ к 'vm'
polkit.addRule (функция (действие, тема) {
  if (action.id.indexOf ("org.libvirt.api.domain.") == 0) {
  if (action.lookup ("connect_driver") == 'QEMU' && myFunction (subject.user, action.lookup ("domain_name"))) {
  polkit.log ("vm =" + action.lookup ("domain_name") + "action =>" + myFunction (subject.user, action.lookup ("domain_name")));
  polkit.log ("subject =" + subject);
  polkit.log («хорошо»);
  вернуть polkit.Result.YES;
  } else {
  вернуть polkit.Result.NO;
  }
  }
 });

  3. теперь только соответствующий пользователь сможет видеть только саму виртуальную машину.

наслаждайтесь

1
ответ дан 3 December 2019 в 03:16

Теги

Похожие вопросы