Open stack how project, service, service user work

 

The service you create in Keystone is just metadata:

• It's basically: “Hey Keystone, here's a service called nova, its type is compute, and here's where to find its API endpoints.”

The actual ability to use a service depends on roles in a project:

• For example, the admin user might have the admin role in the admin project.

• When admin authenticates, it gets a token scoped to the admin project and can use it to access any service endpoint (like nova) as long as that service respects those roles.

The nova service checks Keystone tokens:

• When you send a request to the Nova API (like nova list), the token is included.

• Nova sends the token to Keystone for validation.

• Keystone responds with: "Yes, this user is admin in project admin with admin role."

• Based on that, Nova allows or denies the request.

dmin user does not need a separate token for every service. Here's the full picture:

---

🔐 OpenStack Tokens Are Project-Scoped, Not Service-Scoped

When a user (like admin) authenticates via Keystone:

bash

openstack token issue

They receive a Keystone token that's:

• Scoped to a specific project (e.g., admin project)

• Valid for any service the user has access to under that project

---

✅ That One Token Works Across All Services

As long as the token is valid and the user has the right roles in that project, it can be used for:

• Nova (compute)

• Glance (images)

• Neutron (network)

• Cinder (block storage)

• Any custom service you register

Example: after sourcing admin-openrc.sh, the admin user can run:

bash

openstack server list         # talks to Nova
openstack image list          # talks to Glance
openstack network list        # talks to Neutron

All using one token under the hood.