openstack-manuals/doc/training-guide/module001-ch007-keystone-arch.xml
Andreas Jaeger fac23cb047 Fix whitespace problems
Since we have now a niceness gate, let's remove the known failures.

Change-Id: I01684aee61e18e76f6523a466e28b8252e577f6f
2013-10-08 15:18:31 +02:00

188 lines
8.6 KiB
XML

<?xml version="1.0" encoding="utf-8"?>
<chapter xmlns="http://docbook.org/ns/docbook"
xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink"
version="5.0"
xml:id="module001-ch007-keystone-arch">
<title>Ketstone Architecture</title>
<para>More Content To be Added ...</para>
<para><guilabel>Identity Service Concepts</guilabel></para>
<para>The Identity service performs the following
functions:</para>
<itemizedlist>
<listitem>
<para>User management. Tracks users and their
permissions.</para>
</listitem>
<listitem>
<para>Service catalog. Provides a catalog of available
services with their API endpoints.</para>
</listitem>
</itemizedlist>
<para>To understand the Identity Service, you must understand the
following concepts:</para>
<para><guilabel>User</guilabel></para>
<para>Digital representation of a person, system, or service who
uses OpenStack cloud services. Identity authentication
services will validate that incoming request are being made by
the user who claims to be making the call. Users have a login
and may be assigned tokens to access resources. Users may be
directly assigned to a particular tenant and behave as if they
are contained in that tenant.</para>
<para><guilabel><anchor xml:id="h.i1npk4aiu35h"/>Credentials</guilabel></para>
<para>Data that is known only by a user that proves who they
are. In the Identity Service, examples are:</para>
<itemizedlist>
<listitem>
<para>Username and password</para>
</listitem>
<listitem>
<para>Username and API key</para>
</listitem>
<listitem>
<para>An authentication token provided by the Identity
Service</para>
</listitem>
</itemizedlist>
<para><guilabel><anchor xml:id="h.aa29gdlbf7qa"/>Authentication</guilabel></para>
<para>The act of confirming the identity of a user. The Identity
Service confirms an incoming request by validating a set of
credentials supplied by the user. These credentials are
initially a username and password or a username and API key.
In response to these credentials, the Identity Service issues
the user an authentication token, which the user provides in
subsequent requests.</para>
<para><guilabel><anchor xml:id="h.grqljkbnx8fs"/>Token</guilabel></para>
<para>An arbitrary bit of text that is used to access resources.
Each token has a scope which describes which resources are
accessible with it. A token may be revoked at anytime and is
valid for a finite duration.</para>
<para>While the Identity Service supports token-based
authentication in this release, the intention is for it to
support additional protocols in the future. The intent is for
it to be an integration service foremost, and not aspire to be
a full-fledged identity store and management solution.</para>
<para><guilabel><anchor xml:id="h.qz798xvt751f"/>Tenant</guilabel></para>
<para>A container used to group or isolate resources and/or
identity objects. Depending on the service operator, a tenant
may map to a customer, account, organization, or
project.</para>
<para><guilabel><anchor xml:id="h.ayp97sn984my"/>Service</guilabel></para>
<para>An OpenStack service, such as Compute (Nova), Object
Storage (Swift), or Image Service (Glance). Provides one or
more endpoints through which users can access resources and
perform operations.</para>
<para><guilabel><anchor xml:id="h.74y77xwdnwlm"/>Endpoint</guilabel></para>
<para>An network-accessible address, usually described by URL,
from where you access a service. If using an extension for
templates, you can create an endpoint template, which
represents the templates of all the consumable services that
are available across the regions.</para>
<para><guilabel><anchor xml:id="h.r7samiog05in"/>Role</guilabel></para>
<para>A personality that a user assumes that enables them to
perform a specific set of operations. A role includes a set of
rights and privileges. A user assuming that role inherits
those rights and privileges.</para>
<para>In the Identity Service, a token that is issued to a user
includes the list of roles that user can assume. Services that
are being called by that user determine how they interpret the
set of roles a user has and which operations or resources each
role grants access to.</para>
<figure>
<title>Keystone Authentication</title>
<mediaobject>
<imageobject>
<imagedata fileref="figures/image19.png"/>
</imageobject>
</mediaobject>
</figure>
<para><guilabel><anchor xml:id="h.rdpcpnbvn06w"/>User management</guilabel></para>
<para>The main components of Identity user management are:</para>
<itemizedlist>
<listitem>
<para>Users</para>
</listitem>
<listitem>
<para>Tenants</para>
</listitem>
<listitem>
<para>Roles</para>
</listitem>
</itemizedlist>
<para>A userrepresents a human user, and has associated
information such as username, password and email. This example
creates a user named "alice":</para>
<para>$ keystone user-create --name=alice --pass=mypassword123
--email=alice@example.com</para>
<para>A tenantcan be a project, group, or organization. Whenever
you make requests to OpenStack services, you must specify a
tenant. For example, if you query the Compute service for a list
of running instances, you will receive a list of all of the
running instances in the tenant you specified in your query.
This example creates a tenant named "acme":</para>
<para>$ keystone tenant-create --name=acmeA rolecaptures what
operations a user is permitted to perform in a given tenant.
This example creates a role named "compute-user":</para>
<para>$ keystone role-create --name=compute-userThe Identity
service associates a user with a tenant and a role. To continue
with our previous examples, we may wish to assign the "alice"
user the "compute-user" role in the "acme" tenant:</para>
<para>$ keystone user-list</para>
<para>$ keystone user-role-add --user=892585 --role=9a764e
--tenant-id=6b8fd2</para>
<para>A user can be assigned different roles in different tenants:
for example, Alice may also have the "admin" role in the
"Cyberdyne" tenant. A user can also be assigned multiple roles
in the same tenant.</para>
<para>The /etc/[SERVICE_CODENAME]/policy.json controls what users
are allowed to do for a given service. For example,
/etc/nova/policy.json specifies the access policy for the
Compute service, /etc/glance/policy.json specifies the access
policy for the Image service, and /etc/keystone/policy.json
specifies the access policy for the Identity service.</para>
<para>The default policy.json files in the Compute, Identity, and
Image service recognize only the admin role: all operations that
do not require the admin role will be accessible by any user
that has any role in a tenant.</para>
<para>If you wish to restrict users from performing operations in,
say, the Compute service, you need to create a role in the
Identity service and then modify /etc/nova/policy.json so that
this role is required for Compute operations.</para>
<para>For example, this line in /etc/nova/policy.json specifies
that there are no restrictions on which users can create
volumes: if the user has any role in a tenant, they will be able
to create volumes in that tenant.</para>
<para><guilabel><anchor xml:id="h.f5989v85c3fd"/></guilabel></para>
<para><guilabel><anchor xml:id="h.1rrjgvz0nkwh"/>Service
management</guilabel></para>
<para>The Identity Service provides the following service
management functions:</para>
<itemizedlist>
<listitem>
<para>Services</para>
</listitem>
<listitem>
<para>Endpoints</para>
</listitem>
</itemizedlist>
<para>The Identity Service also maintains a user that corresponds
to each service (such as, a user named nova, for the Compute
service) and a special service tenant, which is called
service.</para>
<para>The commands for creating services and endpoints are
described in a later section.</para>
</chapter>