Как создать среду, в которой виртуальная машина каждого пользователя изолирована

Я считаю, что благодаря поддержке PolicyKit в libvirt, это можно сделать в зависимости от того, сколько функций вам нужно.

Правила могут быть созданы вами, и ACL-списки PolicyKit могут к ним обращаться как к базе данных (файл, сервер и т. Д.) Для получения информации о владельцах. Кроме того, если правило PolicyKit имеет доступ для записи в базу данных, вы можете назначить виртуальные машины их соответствующим владельцам, когда они будут созданы, тем самым создав эту базу данных автоматически. Это может быть ненадежным (например, когда определение виртуальной машины терпит неудачу, база данных уже будет иметь эту запись), поэтому могут потребоваться некоторые дополнительные перехватчики, в зависимости от того, сколько функций вы ищете. Вот почему существуют проекты, основанные на libvirt (или просто сценарии, развернутые администраторами), которые могут иметь больше функций.

Если вам достаточно более простого, то вы можете сказать, что пользователи могут вызывать API только на виртуальных машинах, которые начинаются с их имени пользователя. Просто убедитесь, что угловые случаи закрыты (например, пользователь "bla" не может получить доступ к машинам пользователя "blabla").

Как уже говорилось, в зависимости от того, сколько функций вам нужно, это можно сделать легко или с помощью нескольких строк сценария, или вам может потребоваться полноценная система виртуализации, расположенная поверх libvirt.

Еще кое-что что никто не упомянул (и это мощь будь тем, что хочешь / ищешь). Если вы (как пользователь без полномочий root) подключаетесь к сеансу qemu: /// (вместо system, см. Подключения к драйверу QEMU) вы подключитесь к своему собственному экземпляру демона libvirt, и вы увидите только свои собственные машины (другими словами, он будет изолирован от демонов сеанса других пользователей).

Что ж, так же, как рекламируется в статье, на которую вы ссылаетесь, libvirt поддерживает PolicyKit на основе API (мы называем это ACL). Так что, если вы установите какие-то правила polkit, вы сможете получить то, что хотите. Например, домен X будет виден только пользователю Y. К сожалению, я не думаю, что можно сделать эти правила динамическими (я имею в виду, что если пользователь создает домен, он будет виден только им).

Если вы не хотите писать свою собственную оболочку / систему управления, вам просто нужно нечто большее, чем просто libvirt, для управления доступом и отношениями между виртуальными машинами и пользователями. oVirt / RHV имеет это из коробки, даже со специальным пользовательским порталом, где зарегистрированный пользователь может видеть только принадлежащие ему виртуальные машины. Я почти уверен, что другие системы управления виртуализацией также имеют такую ​​возможность.

Этот файл как правило полкита

function myFunction(username, virtualmachine) {
var arr = virtualmachine.split("*");
if(arr[0]==username){
    return true;
    }
else{
    return false;
   }
}
// Allow passwordless connection to qemu:///system
polkit.addRule(function(action, subject) {
  if (action.id == "org.libvirt.unix.manage")
   {
        return polkit.Result.YES;
        }
    });
// Give full access to 'vm'
polkit.addRule(function(action, subject) {
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("ok");
        return polkit.Result.YES;
      } else {
        return polkit.Result.NO;
      }
      }
});

здесь vm в формате

имя пользователя * vmname

эта виртуальная машина доступна только соответствующему пользователю

PS это всего лишь примитивное правило, то есть вы не можете создать новый пул, изменить его и т. Д., Поэтому требуется дальнейшая разработка правила.