cloudstack/docs/en-US/accounts-users-domains.xml

<?xml version='1.0' encoding='utf-8' ?>
<!DOCTYPE section PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
<!ENTITY % BOOK_ENTITIES SYSTEM "cloudstack.ent">
%BOOK_ENTITIES;
]>

<!-- Licensed to the Apache Software Foundation (ASF) under one
    or more contributor license agreements.  See the NOTICE file
    distributed with this work for additional information
    regarding copyright ownership.  The ASF licenses this file
    to you under the Apache License, Version 2.0 (the
    "License"); you may not use this file except in compliance
    with the License.  You may obtain a copy of the License at
    
    http://www.apache.org/licenses/LICENSE-2.0
    
    Unless required by applicable law or agreed to in writing,
    software distributed under the License is distributed on an
    "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
    KIND, either express or implied.  See the License for the
    specific language governing permissions and limitations
    under the License.
-->
<section id="accounts-users-domains">
    <title>Accounts, Users, and Domains</title>
    <formalpara>
        <title>Accounts</title>
        <para>An account typically represents a customer of the service provider or a department in a large organization. Multiple users can exist in an account.</para>
    </formalpara>
    <formalpara>
        <title>Domains</title>
        <para>Accounts are grouped by domains. Domains usually contain multiple accounts that have some logical relationship to each other and a set of delegated administrators with some authority over the domain and its subdomains. For example, a service provider with several resellers could create a domain for each reseller.</para>
    </formalpara>      
    <para>For each account created, the Cloud installation creates three different types of user accounts: root administrator, domain administrator, and user.</para>
    <formalpara>
        <title>Users</title>
        <para>Users are like aliases in the account. Users in the same account are not isolated from each other, but they are isolated from users in other accounts. Most installations need not surface the notion of users; they just have one user per account. The same user cannot belong to multiple accounts.</para>
    </formalpara>
    <para>Username is unique in a domain across accounts in that domain. The same username can exist in other domains, including sub-domains. Domain name can repeat only if the full pathname from root is unique. For example, you can create  root/d1, as well as root/foo/d1, and root/sales/d1.</para>
    <para>Administrators are accounts with special privileges in the system. There may be multiple administrators in the system. Administrators can create or delete other administrators, and change the password for any user in the system.</para>   
    <formalpara>
        <title>Domain Administrators</title>
        <para>Domain administrators can perform administrative operations for users who belong to that domain. Domain administrators do not have visibility into physical servers or other domains.</para>
    </formalpara>
    <formalpara>
        <title>Root Administrator</title>
        <para>Root administrators have complete access to the system, including managing templates, service offerings, customer care administrators, and domains</para>
    </formalpara>
    <formalpara>
        <title>Resource Ownership</title>
        <para>Resources belong to the account, not individual users in that account. For example,
            billing, resource limits, and so on are maintained by the account, not the users. A user can
            operate on any resource in the account provided the user has privileges for that operation.
            The privileges are determined by the role.</para>
    </formalpara>
    <section id="account-dedicated-resources">
        <title>Dedicating Resources to Accounts and Domains</title>
        <para>You can dedicate infrastructure resources including zones, pods, clusters, or hosts to an account or domain.
        </para>
        <para>The root administrator can dedicate resources to a specific domain or account
            that needs private infrastructure for additional security or performance guarantees.
            A zone, pod, cluster, or host can be reserved by the root administrator for a specific domain or account.
            Only users in that domain or its subdomain may use the infrastructure.
            For example, only users in a given domain can create guests in a zone dedicated to that domain.</para>
        <para>There are several types of dedication available:</para>
        <itemizedlist>
            <listitem>
                <para>To explicitly dedicate a resource, use the explicit-dedicated type of Affinity Group.
                    For example, when creating a new VM, an end user can choose to place it on dedicated infrastructure.
                    See <xref linkend="affinity-groups"/>.</para></listitem>
            <listitem><para>You can also use strict implicit dedication.
                Strict Implicit dedication, when requested, means, a host will not be shared across multiple accounts – as an example, here is a reason:
                for deployment of certain types of applications, such as desktops, due to licensing reasons, no host can be shared between different accounts.</para></listitem>
            <listitem><para>You can also implicitly dedicate a resource with "preferred" implicit dedication. This means that the resource will be deployed
                in dedicated infrastructure if possible. Otherwise, the resource can be deployed in shared infrastructure.</para></listitem>
        </itemizedlist>
    </section>
</section>