Users and permissions
How sign-in, roles, and per-project permissions work in Akasha, and where to view your own access.
You sign in to Akasha through your organization's single sign-on (SSO), and administrators grant access per project. The console shows you your own permissions but does not let you change them.
Signing in
The console login page has a single Continue with SSO button. Clicking it redirects you to your organization's identity provider; after you sign in there, you return to the console. See First login.
Every account must have an email address. If your account has none, Akasha rejects your requests — ask your administrator to fix the account.
Roles
Akasha has two roles:
| Role | What it grants |
|---|---|
| Standard user | Access to the specific projects you have been granted |
| Superuser | Platform administrator: access to every project plus the administrative areas of the console |
Administrative features — creating projects, setting limits, managing users, configuring pricing, and platform operations — are reserved for superusers. Tenant documentation refers to superusers as administrators.
Project permissions
Access is granted per project. A project grant gives you full access to everything in that project: its instances, Kubernetes clusters, storage, networks, profiles, and images. There is no finer-grained permission level — you either have full access to a project or none.
Permission strings take these forms:
| Permission | Meaning |
|---|---|
akasha:project:<project>:* | Full access to one project |
akasha:superuser | Platform administrator |
Attempting to reach a project you have no grant for is denied by the API, and projects you cannot access do not appear in your project selector.
View your permissions
Open the Access page at /ui/permissions/me in the console. The page shows:
- An identity card with your name, email, and role (Superuser or Standard user).
- A table of your permission strings, each with its kind (Superuser or Project access) and scope (the project name).
This page is read-only. Permissions are managed by your administrator through group membership in your organization's SSO — to request a change, ask your administrator to add you to the appropriate group.
If you have no access
If you sign in successfully but see the message "No Akasha permissions are assigned to your account", your account exists but has not been granted any project. Contact your administrator and ask for access to the projects you need.
API access
The Akasha API uses the same identity and permissions as the console: requests carry a bearer token issued by your organization's SSO, and per-project grants apply to API calls exactly as they do in the console. You can check your own identity and grants with GET /1.0/akasha/rbac/me. See API authentication.