<html>
  <head>
    <meta content="text/html; charset=GB2312" http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">Yu Xin,<br>
      <br>
      Thanks for your detail comments.<br>
      <br>
      ÓÚ 2014/1/20 18:20, Yu Xin Huo Ð´µÀ:<br>
    </div>
    <blockquote cite="mid:52DCF87B.4010804@linux.vnet.ibm.com"
      type="cite">
      <meta content="text/html; charset=GB2312"
        http-equiv="Content-Type">
      <div class="moz-cite-prefix"><br>
        I have read the oVirt security model, I think basically, for
        virtualization management, it can be applied to Kimchi.<br>
        I think Kimchi's security model can be created with some
        customization of oVirt's security model.<br>
        <br>
        I recommend 3 levels of administration below:<br>
        <br>
        <a moz-do-not-send="true" class="moz-txt-link-freetext"
href="https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.0/html/Administration_Guide/Administration_Guide-Managing_User_Access.html">https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.0/html/Administration_Guide/Administration_Guide-Managing_User_Access.html</a><br>
        1. console admin -- handle kimchi administration, host level
        physical resources management.<br>
      </div>
    </blockquote>
    <br>
    That is like the system administrator in my proposal who are also
    responsible to assign roles to users..<br>
    <br>
    <blockquote cite="mid:52DCF87B.4010804@linux.vnet.ibm.com"
      type="cite">
      <div class="moz-cite-prefix"> 2. resource admin -- OOTB roles with
        permission combined with resource type, like VMAdmin,
        StorageAdmin, NetworkAdmin...<br>
        &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; this type of users are responsible to construct
        environment for a certain task.<br>
        &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; their authorizations can be easily constructed with
        combination with OOTB roles, then they can start to create
        resources needed.<br>
        &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; I think it will be needed if we can set some limit on
        resource usages like max cpu, memory, bandwidth.\<br>
      </div>
    </blockquote>
    <br>
    I agree that the user with this role can access the resources based
    on resource type instead of on resource object.&nbsp; For example, if the
    uer get a "Storage Admin" role, he can access all the storage pools
    in Kimchi not bound to one specific storage pool.<br>
    &nbsp;<br>
    In the pother hand, in the initial effort, I don't want to define so
    many roles to manage resources.&nbsp; In my proposal, I use one role
    "infrastructure" to be a role accessing both the host level physical
    resource&nbsp; and virtualization resources.&nbsp; Host level physical
    resources management means disks, physical networks in the hosts.&nbsp;
    Virtualization resources means storage pools, network pools.&nbsp; We can
    keep this in mind and try to define more administration roles to
    replace the "infrastructure role" in the next step.&nbsp; <br>
    &nbsp; <br>
    <blockquote cite="mid:52DCF87B.4010804@linux.vnet.ibm.com"
      type="cite">
      <div class="moz-cite-prefix"> <br>
        <a moz-do-not-send="true" class="moz-txt-link-freetext"
href="https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.0/html/Administration_Guide/Virtual_Roles.html">https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.0/html/Administration_Guide/Virtual_Roles.html</a><br>
        3. resource user&nbsp;&nbsp;&nbsp; -- at this level, I tend to think that no
        OOTB roles are needed as fine granularity of authorization will
        be needed.<br>
        &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; the authorization at this level are at a resource basis,
        need to assign permissions for each user on each resource.<br>
        &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; one thing to emphasize is that, resource user does not
        mean the user can only use(start/stop/vnc) the resource, <br>
        &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; it depends on concrete case, they can be assigned with
        permission to update/delete resources.<br>
      </div>
    </blockquote>
    <br>
    <br>
    As you can see in Ovirt, authorization is applied based on the
    combination of the three components in any action
    <div xmlns:d="http://docbook.org/ns/docbook" class="itemizedlist">
      <ul>
        <li class="listitem">
          <div class="para"> The user performing the action </div>
        </li>
        <li class="listitem">
          <div class="para"> The type of action being performed </div>
        </li>
        <li class="listitem">
          <div class="para"> The object on which the action is being
            performed </div>
        </li>
      </ul>
    </div>
    Please be noted that the object is not bound to a role in oVirt. On
    the other hand, you need assign a resource to a user.&nbsp; Here is one
    example to assign a virtual machine to a user With a "UserRole"
    role.
<a class="moz-txt-link-freetext" href="https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.0/html/Administration_Guide/Virtual_Roles.html">https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.0/html/Administration_Guide/Virtual_Roles.html</a><br>
    <br>
    <blockquote cite="mid:52DCF87B.4010804@linux.vnet.ibm.com"
      type="cite">
      <div class="moz-cite-prefix"> <br>
        I think this is a flexible and efficient authority delegation
        model with responsibilities balanced.<br>
        <br>
        <br>
        On 1/15/2014 3:03 PM, Shu Ming wrote:<br>
      </div>
      <blockquote cite="mid:52D632AF.7000209@linux.vnet.ibm.com"
        type="cite">
        <meta http-equiv="content-type" content="text/html;
          charset=GB2312">
        <h1>Background</h1>
        <br>
        In Kimchi, now we have a basic authentication model based on
        PAM.&nbsp; In this model, all the authenticated user get all of the
        privileges to access the resources in Kimchi. However, it is too
        simple to cause some security holes and classifying the user
        with different roles is a way to address the holes. Roles with
        very fine grained privileges need huge effort and time, so here
        we are trying to split the effort with several steps.&nbsp; And we
        will discuss the first step of the effort in the below which can
        be achieved in a certain time bound and reserve the forward
        compatibility for future extensions.<br>
        <br>
        <br>
        <h1>First step of the effort</h1>
        <br>
        In this step, the goal is to authorize the user's action on a
        resource by roles. The user action here is applied by the REST
        API exposed by Kimchi.&nbsp; Every action on Kimchi resources should
        be checked based on the user's role.&nbsp; In this step, we will not
        try to have roles in a very fine granularity. Naturally, three
        permanent roles will be created by default, the system
        administrator role, the infrastructure role and the user role.<br>
        <br>
        &nbsp;&nbsp; * The system administrator get the privileges to manage the
        roles for the other users including assigning a role to a user,
        removing the role from a user &amp;etc.&nbsp; A default user "admink"
        will be created by default with a system administrator role
        assigned to it. And the role of the user "admink" can not be
        modified. <br>
        <br>
        &nbsp;&nbsp; * The infrastructure role get the privileges to&nbsp; manage the
        physical resources and virtual resources including network's
        creation and deletion, create or delete storage storage pools or
        storage volumes' creation and deletion, adding a user to the
        user list of storage storage pool &amp;etc. <br>
        <br>
        &nbsp;&nbsp; * The user role get the privileges to apply action on VMs
        including VMs' starting and stopping, viewing the VM console by
        VNC &amp;etc.<br>
        <br>
        &nbsp;&nbsp; * Some of the change can be enhanced on the existing REST API
        like "DELETE /storagepools/poo1/vo1".&nbsp; But we need create new
        REST APIs for actions like adding a role for a user like " PUT
        /users/user1 {role: "user role"}"<br>
        <br>
        &nbsp;&nbsp; * Database is needed to store the user information including
        roles and resource user list<br>
        <br>
        Beside the privileges inherited from the user's role, Kimchi
        will check if a user get the permission to access a resource
        based on a tuple.&nbsp; The tuple is composed from both the
        privileges of the user and the user list of the resource. An
        example is, if a user try ti delete a storage volume from the
        stroage pool,&nbsp; Kimchi will check if it is assigned a
        infrastructure role and if it is in the user list of the storage
        pool.<br>
        <br>
        <h1>Next step of the effort</h1>
        <br>
        *&nbsp; The roles are defined in a very fine granularity containing
        the privileges precisely matching what the system administrator
        expects.&nbsp; <br>
        <br>
        *&nbsp; Existing roles can by customized by the system administrator
        from a set of previleges.&nbsp;&nbsp; The set of privileges should be
        pre-defined and hierarchy. <br>
        <br>
        * The system administrator can create new roles with customized
        privileges <br>
        <fieldset class="mimeAttachmentHeader"></fieldset>
        <br>
        <pre wrap="">_______________________________________________
Kimchi-devel mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Kimchi-devel@ovirt.org">Kimchi-devel@ovirt.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://lists.ovirt.org/mailman/listinfo/kimchi-devel">http://lists.ovirt.org/mailman/listinfo/kimchi-devel</a>
</pre>
      </blockquote>
      <br>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
Kimchi-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Kimchi-devel@ovirt.org">Kimchi-devel@ovirt.org</a>
<a class="moz-txt-link-freetext" href="http://lists.ovirt.org/mailman/listinfo/kimchi-devel">http://lists.ovirt.org/mailman/listinfo/kimchi-devel</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>