Cleanup code that references users, projects or domains without
necessary scoping or filtering throughout the charm. Add logging
of domain name in contexts where this is relevant.
Tighten rule:service_role to require role:service and token scoped
to project config('service-tenant') created in SERVICE_DOMAIN. This
ensures that if you have a deployment with end-user access to assign
roles within their own domains they will not gain privileged access
simply by assigning the service role to one of their own users.
Allow users authorized by rule:service_role to perform
identity:list_projects. This is required to allow Ceilometer
to operate without Admin privileges.
Services are given a user in project config('service-tenant') in
SERVICE_DOMAIN for v3 authentication / authorization. As of Mitaka
Keystone v3 policy the 'service' role is sufficient for services to
validate tokens.
Services are also given a user in project config('service-tenant') in
DEFAULT_DOMAIN to support services still configured with v2.0
authentication / authorization.
This will allow us to transition from v2.0 based authentication /
authorization and existing services and charms will continue to
operate as before. This will also allow the end-user to roll their
deployment up to api_version 3 and back to api_version 2 as needed.
Services and charms that has made the transition to fully use the
v3 API for authentication and authorization will gain full access to
domains and projects across the deployment. The first charm to make
use of this is charm-ceilometer.
Closes-Bug: 1636098
Change-Id: If1518029c43476a5e14bf94596197eabe663499c
The default_domain_id is used to specify a domain when the client
hasn't explicitly set one. It defaults to 'default' which is fine
for liberty and previous because the id of the default domain is,
oddly, 'default' rather than a uuid. On Mitaka and higher it is
a uuid so when keystone assumes the default domains id is 'default'
it fails.
Change-Id: Iaa5e6a07a229815cf2281858cb68a4e120aa2af3
Closes-Bug: 1626889
Juju 2.0 provides support for display of the version of
an application deployed by a charm in juju status.
Insert the os_application_version_set function into the
existing assess_status function - this gets called after
all hook executions, and periodically after that, so any
changes in package versions due to normal system updates
will also be reflected in the status output.
This review also includes a resync of charm-helpers to
pickup hookenv and contrib.openstack support for this
feature.
Change-Id: I5734e87d39e62c1fb791b0b79ff216e30a784d1f
The keystone charm runs the keystone API under apache2 for liberty
and above. This patch enables the keystone API to run under apache2
when deployed from source for liberty and above.
Change-Id: I5eccf38aad9668248f4f94523d61f7bd40ed5c30
All contributors to this charm have agreed to the switch
from GPL v3 to Apache 2.0; switch to Apache-2.0 license
as agreed so we can move forward with official project status.
Change-Id: Iaee75f59fe51f01da18aa2703a46c3885ade73c0
Add the admin domain id (not name) to the data passed to clients
down the identity-service relation. Some clients (eg Horizon) require
the admin domain id for local configuration.
Change-Id: Idfbd09fa62e628958139f77b9d06f602783e3619
Partial-Bug: 1595685
This change fixes the obvious race for a status_set() between
check_optional_interfaces() and assess_status() as the later calls the former
which calls status_set(), returns the status, which is then potentially set
again by the assess_status() function. This cleans up the code so that only a
single status_set() is performed when calling assess_status().
Change-Id: I928f60967e4a7588df2b25136525391c283cda14
Related-Bug:#1588462
The newton packages for keystone ship an apache2 site named
keystone, with conflicts with the charm provided wsgi-keystone
site.
Ensure that the packaging provided configuration is disabled,
both on initial install and on upgrade from Mitaka->Newton.
Change-Id: I5f6c67057a32d46529510ba6e4c0f5514f1a2d9e
In the change from tenant to project the call to
create_user_credentials was incorrectly changed to project.
This is a trivial fix of that call.
Change-Id: I3f478412034d6305f13805ed53ce3d52896a0677
Charms use this relation to obtain keystone credentials without
creating a service catalog entry. Set 'username' only on the relation
and keystone will set defaults and return authentication details.
Possible relation settings:
username: Username to be created.
project: Project (tenant) name to be created. Defaults to services
project.
requested_roles: Comma delimited list of roles to be created
requested_grants: Comma delimited list of roles to be granted.
Defaults to Admin role.
domain: Keystone v3 domain the user will be created in.
Defaults to the Default domain.
Change-Id: I465d2273560d86752d1bfc7497a9139a9604f814
The restart_on_change function uses the underlying init systems service
control programs to stop/start/restart services. However, sometimes
these misbehave like apache2 with mod_wsgi which can leave process
running after stop has completed which then block start from running.
These change ensures that apache really has stopped before starting it.
Change-Id: I8255d8f5371f7bb0783878253afafcf27275b6b8
Closes-Bug: 1567741
The Kilo release of openstack deprecated the eventlet wsgi server in favor of
using apache with mod_wsgi. This changes disables the keystone service and
adds a vhost to the existing apache server to run keystone using mod_wsgi.
Change-Id: I8125d8081c14550e86cd77b25185f27f500e368b
Closes-Bug: 1515628
When checking for existing roles/users/tenants the charm was case
sensitive such that admin != Admin. However, when keystone tries to
create a role/user/tenant that exists but with different case mysql will
error out. OpenNFV requires that the admin user be named 'admin' with
lower case but the default is 'Admin' leading to failed deploys of
OpenStack.
This change makes the check for existence case insensitive. It does
*not* change the creation of roles/users/tenants. Therefore,
roles/users/tenants will be created unchanged but checks for existence
will still match even when case does not.
Change-Id: I49c4f5e8d0e79f64fbc8bf412341a93f4a970778
Closes-Bug: #1512984
This contains a fix against the original change id:
Ie0c5e0249bde0839345ad66f7400522754aa91ca which broke
keystone. Otherwise, the fix is the same:
The existing pause/resume functionality is enhanced with
changed charm-helpers support to chech that the services
really are stopped and that paused units really stay
paused. The restart_on_change decorator is gated
such that if the unit is 'paused' then the service
is not accidentally started.
Change-Id: I6a828676be11338266845e822be087d734944da0
The existing pause/resume functionality is enhanced with
changed charm-helpers support to chech that the services
really are stopped and that paused units really stay
paused. The restart_on_change decorator is gated
such that if the unit is 'paused' then the service
is not accidentally started.
Change-Id: Ie0c5e0249bde0839345ad66f7400522754aa91ca
This changes enables the Keystone v3 api. It can be toggled on and off via the
preferred-api-version option.
When services join the identity-service relation they will be presented with a
new parameter api_version which is the maximum api version the keystone charm
supports and matches what was set via preferred-api-version.
If preferred-api-version is set to 3 then the charm will render a new
policy.json which adds support for domains etc when keystone is checking
authorisation. The new policy.json requires an admin domain to be created and
specifies that a user is classed as an admin of the whole cloud if they have
the admin role against that admin domain.
The admin domain, called admin_domain, is created by the charm. The name of
this domain is currently not user configurable. The role that enables a user to
be classed as an admin is specified by the old charm option admin-role. The
charm grants admin-role to the admin-user against the admin_domain.
Switching a deployed cloud from preferred-api-version 2 to
preferred-api-version 3 is supported. Switching from preferred-api-version 3 to
preferred-api-version 2 should work from the charm point of view but may cause
problems if there are duplicate users between domains or may have unintended
consequences like escalating the privilege of some users so is not recommended.
Change-Id: I8eec2a90e0acbf56ee72cb5036a0a21f4a77a2c3
Implemented new is_paused() and assess_status() functions, and changed
the pause and resume actions to use them. Changed existing and added new
tests to verify functionality.
Adds in the config option for overriding public endpoint addresses
and introduces a unit tests to ensure that the override for the
public address is functioning correctly.
Closes-Bug: #1398182
A previous commit had removed auth_host and service_host from
the peer relation due to races with resolve_address(). If
we do not place this data on the peer relation we actually
break endpoints that use openstack.context.IdentityServiceContext
which expects *any* keystone relation unit to be able to provide
a complete set of valid settings...which are propagated by the
peer relation and re-propagated to the keystone relations.