After keystone is deployed and configured, it must be pre-populated with some initial data before it can be used. This process is known as bootstrapping and it typically involves creating the system’s first user, project, domain, service, and endpoint, among other things. The goal of bootstrapping is to put enough information into the system such that it can function solely through the API using normal authentication flows. After the first user is created, which must be an administrator, you can use that account to interact with keystone via the API.
Keystone provides two separate ways to bootstrap a deployment. The first is
keystone-manage bootstrap command. This is the preferred and
recommended way to bootstrap new installations. The second, and original way of
bootstrapping involves configuring a secret and deploying special middleware in
front of the identity service. The secret is known as the
requests made to the identity API with the
ADMIN_TOKEN will completely
bypass authentication allowing access to the entire API.
Using the CLI¶
The process requires access to an environment with keystone binaries installed, typically on the service host.
keystone-manage bootstrap command will create a user, project and role,
and will assign the newly created role to the newly created user on the newly
created project. By default, the names of these new resources will be called
The defaults may be overridden by calling
--bootstrap-role-name. Each of these have
an environment variable equivalent:
A user password must also be supplied. This can be passed in as either
--bootstrap-password, or set as an environment variable using
Optionally, if specified by
--bootstrap-internal-url or the equivalent
environment variables, the command will create an identity service with the
specified endpoint information. You may also configure the
--bootstrap-service-name for the endpoints to
your deployment’s requirements.
We strongly recommend that you configure the identity service and its endpoints while bootstrapping keystone.
Minimally, keystone can be bootstrapped with:
$ keystone-manage bootstrap --bootstrap-password s3cr3t
Verbosely, keystone can be bootstrapped with:
$ keystone-manage bootstrap \ --bootstrap-password s3cr3t \ --bootstrap-username admin \ --bootstrap-project-name admin \ --bootstrap-role-name admin \ --bootstrap-service-name keystone \ --bootstrap-region-id RegionOne \ --bootstrap-admin-url http://localhost:5000 \ --bootstrap-public-url http://localhost:5000 \ --bootstrap-internal-url http://localhost:5000
This will create an
admin user with the
admin role on the
project. The user will have the password specified in the command. Note that
both the user and the project will be created in the
default domain. By not
creating an endpoint in the catalog users will need to provide endpoint
overrides to perform additional identity operations.
This command will also create
reader roles. The
role implies the
member role and
member role implies the
role. By default, these three roles are immutable, meaning they are created with
immutable resource option and cannot be modified or deleted unless the
option is removed. To disable this behavior, add the
By creating an
admin user and an identity endpoint you may
authenticate to keystone and perform identity operations like creating
additional services and endpoints using the
admin user. This will preclude
the need to ever use or configure the
admin_token (described below). It is
also, by design, more secure.
To test a proper configuration, a user can use OpenStackClient CLI:
$ openstack project list --os-username admin --os-project-name admin \ --os-user-domain-id default --os-project-domain-id default \ --os-identity-api-version 3 --os-auth-url http://localhost:5000 \ --os-password s3cr3t