cleaned up module001-ch007-keystone-arch keystone-arch
added space between user and represents added space between tenant and can Change-Id: I8fc350d66fed9f0ecdcdf0daa456e1e91396d545
This commit is contained in:
Shilla Saebi
Diane Fleming
parent
b362824b7c
commit
23af173c1b
@ -1,14 +1,13 @@
|
||||
<?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"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0"
|
||||
xml:id="module001-ch007-keystone-arch">
|
||||
<title>Keystone Architecture</title>
|
||||
<para>More Content To be Added ...</para>
|
||||
|
||||
<para><guilabel>Identity Service Concepts</guilabel></para>
|
||||
<para>The Identity service performs the following
|
||||
<!--<para>More Content To be Added ...</para>
|
||||
<section xml:id="module001-ch007-keystone-arch-concepts">
|
||||
<title>Identity Service Concepts</title> -->
|
||||
<para>The Identity service performs these
|
||||
functions:</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
@ -20,19 +19,24 @@
|
||||
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>Credentials</guilabel></para>
|
||||
<para>To understand the Identity Service, you must understand these concepts:</para>
|
||||
<variablelist wordsize="10">
|
||||
<varlistentry>
|
||||
<term><emphasis role="bold">User</emphasis></term>
|
||||
<listitem>
|
||||
<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>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><emphasis role="bold">Credentials</emphasis></term>
|
||||
<listitem>
|
||||
<para>Data that is known only by a user that proves who they
|
||||
are. In the Identity Service, examples are:</para>
|
||||
<itemizedlist>
|
||||
@ -47,67 +51,95 @@
|
||||
Service</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para><guilabel>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>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>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><emphasis role="bold">Authentication</emphasis></term>
|
||||
<listitem>
|
||||
<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>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<emphasis role="bold">Token</emphasis></term>
|
||||
<listitem>
|
||||
<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>Tenant</guilabel></para>
|
||||
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>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><emphasis role="bold">Tenant</emphasis></term>
|
||||
<listitem>
|
||||
<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
|
||||
identity objects. Depending on the service operator, a
|
||||
tenant may map to a customer, account, organization, or
|
||||
project.</para>
|
||||
|
||||
<para><guilabel>Service</guilabel></para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<emphasis role="bold">Service</emphasis></term>
|
||||
<listitem>
|
||||
<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>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>Role</guilabel></para>
|
||||
Storage (Swift), or Image Service (Glance). Provides one
|
||||
or more endpoints through which users can access resources
|
||||
and perform operations.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><emphasis role="bold">Endpoint</emphasis></term>
|
||||
<listitem>
|
||||
<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>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><emphasis role="bold">Role</emphasis></term>
|
||||
<listitem>
|
||||
<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>
|
||||
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"/>
|
||||
<imagedata fileref="figures/image19.png" contentwidth="4in" scale="50" width="4in"/>
|
||||
</imageobject>
|
||||
</mediaobject>
|
||||
</figure>
|
||||
|
||||
<para><guilabel>User management</guilabel></para>
|
||||
<para>The main components of Identity user management are:</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<emphasis role="bold">User management</emphasis></term>
|
||||
<listitem>
|
||||
<para>The main components of Identity user management
|
||||
are:</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Users</para>
|
||||
@ -120,49 +152,61 @@
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
<para>A user represents 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
|
||||
information such as username, password and email. This
|
||||
example creates a user named "alice":</para>
|
||||
<screen><prompt>$</prompt> <userinput>keystone user-create --name=alice --pass=mypassword123 --email=alice@example.com</userinput></screen>
|
||||
<para>A tenant can 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 get a list of
|
||||
all running instances for the specified tenant. This
|
||||
example creates a tenant named "acme":</para>
|
||||
<screen><prompt>$</prompt> <userinput>keystone tenant-create --name=acme</userinput></screen>
|
||||
<para>A role captures what operations a user is permitted to
|
||||
perform in a given tenant. This example creates a role
|
||||
named "compute-user":</para>
|
||||
<screen><prompt>$</prompt> <userinput>keystone role-create --name=compute-user</userinput></screen>
|
||||
<para>The 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>
|
||||
<screen><prompt>$</prompt> <userinput>keystone user-list</userinput></screen>
|
||||
<screen><prompt>$</prompt> <userinput>keystone user-role-add --user=892585 --role=9a764e --tenant-id=6b8fd2</userinput></screen>
|
||||
<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
|
||||
<filename>/etc/[SERVICE_CODENAME]/policy.json</filename>
|
||||
file controls what users are allowed to do for a given
|
||||
service. For example,
|
||||
<filename>/etc/nova/policy.json</filename> specifies the
|
||||
access policy for the Compute service,
|
||||
<filename>/etc/glance/policy.json</filename> specifies
|
||||
the access policy for the Image service, and
|
||||
<filename>/etc/keystone/policy.json</filename> 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
|
||||
<filename>/etc/nova/policy.json</filename> so that this
|
||||
role is required for Compute operations.</para>
|
||||
<para>For example, this line in
|
||||
<filename>/etc/nova/policy.json</filename> 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>Service Management</guilabel></para>
|
||||
volumes: if the user has any role in a tenant, they will
|
||||
be able to create volumes in that tenant.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><emphasis role="bold">Service
|
||||
Management</emphasis></term>
|
||||
<listitem>
|
||||
<para>The Identity Service provides the following service
|
||||
management functions:</para>
|
||||
<itemizedlist>
|
||||
@ -173,10 +217,14 @@
|
||||
<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 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>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
<!-- </section>-->
|
||||
</chapter>
|
||||
|
||||
Loading…
Reference in New Issue
Block a user