This adds the parameter manage_resources to the
keystone::bootstrap class so that one can skip
the actual bootstrap command but still let the
class handle the resources.
Change-Id: I15b70c6d86182d38a8d464ca6c4dc5a9e9afee43
Keystone v3 API does not require that all the three endpoint types are
given and allows using only specific endpoint types(eg. only public, or
public and internal). This allows users to omit specific endpoint types
by setting endpoint url options to ''.
Change-Id: Ifef2070ad25cadf961466ca9f384965d03c08f81
Keystone supports implied roles, and some of the default roles imply
different roles. (eg. admin implies manager)
This introduces a resource type to manage implied roles, and also
ensures the implied roles are created in bootstrap.
Depends-on: https://review.opendev.org/900138
Change-Id: I36ef3ddfcb2f60bdca8674ea8055b6f57a149512
When SRBAC is enforced, Keystone allows only system admin to create
resources like user, role, role assignment and etc. With this change
now each provider uses system scope credential to create resources
like user, endpoint and etc.
This change also replaces /etc/keystone/puppet.conf by the yaml file
for openstackclient(/etc/openstack/puppet/admin-clouds.yaml)
This allows us to switch a system scope credential and a project
scope credential, and helps us implement a new provider which requires
project scope, in the future.
Depends-on: https://review.opendev.org/828025
Change-Id: I27eb6b11df593581c94ef0affaf5abb8e333833b
This change is the initial work to support enforcing secure RBAC(SRBAC)
feature. The following two changes are made by this change.
- The keystone_user_role resource type now supports creating system
roles in addition to project roles and domain roles. The following
example shows how to assign the "admin" role to the "nova" user for
the system scope "all".
keystone_user_role{'nova@::::all':
ensure => 'present',
roles => ['admin'],
}
- Some defined resource types were updated so that the other puppet
modules can define keystone credentials for system scope access
instead of project scope access.
Note that this change does not update the usage of project scope
credentials in each providers, and that should be fixed later to
enforce SRBAC completely.
Change-Id: Id43eeb31424f04d6969a993704e5a5c175eb1cb0
This change introduces a new parameter to enable/disable bootstrap
command by the keystone::bootstrap command. This parameter is useful
expecially in the deployment with multiple controller nodes, and we
can run bootstrap command on only one of the controller nodes while
we generate puppet.conf on all controller nodes, so that we can use
openstack providers in all controller nodes.
Change-Id: If049e33fefc2681d2f4340f5910402b07e6e286f
This class combines the keystone-manage bootstrap command
from init, the keystone::endpoint functionality that manages
the keystone endpoints and the keystone::roles::admin class
that manages users and projects.
This is one of the steps to make sure we only have a single
point of entry for bootstrapping (keystone-manage bootstrap)
and then only managing resources after that.
This is especially required since we are getting rid of the
admin token and cannot manage resources before keystone-manage
bootstrap has created the user, project, service and endpoints
for us.
These resources should always be in the default domain and
deployments should manage domain specific configuration themselves
using the provider resources.
This class uses the default values from the keystone-manage
bootstrap command.
In the past puppet-keystone has always created a openstack project
that is assumed as a admin project even though the bootstrap command
creates the admin project. Since this uses the default values from
the bootstrap command we should move away from having an openstack
project, if we need that in testing it should be created there and
not in the default deployment.
Depends-On: https://review.opendev.org/#/c/698528/
Change-Id: I683fcdd743bddf6d4e989dd7e7c553db745934db
