Domain identity for managers
One Keystone domain per customer, administered by its managers
Learn moreOpenKeel: the sovereign French Cloud solution of the inherent group, with a European reach Discover inherent
Architecture
The Skyline console of OpenKeel is upstream skyline-console plus five patches and one server extension: delegated identity per customer domain, single sign-on per domain, EC2 credentials, cost and carbon footprint at build time, a FinOps / GreenOps dashboard and the metrics of the VMs.
One Keystone domain per customer, administered by its managers
Learn moreEach domain brings its own OpenID Connect identity provider
Learn moreUsers coming from the IdP wait for a role; managers grant it or pre-authorize them
Learn moreAccess and secret keys for the EC2 API, for users and administrators
Learn moreFinOps and GreenOps figures in the creation forms and the quota popup
Learn moreA dashboard of the project's costs and footprint, and the metrics of its VMs
Learn moreKeystone delegates user management per domain: a user with the manager role on a domain creates its users, groups and projects and gives them manager, member or reader, never admin and never outside the domain. OpenKeel gives each customer a domain of its own.
| What | How | Status |
|---|---|---|
| One domain per customer | The OpenKeelCustomer resource (Kubernetes, cluster-scoped) declares the domain, its managers and its first projects; the keystone-customers controller keeps them in Keystone and repairs manual changes every 10 minutes | Done |
| Managers | manager role on the domain, inherited by its projects so that Skyline accepts their login; initial password in a Secret, never reset by the controller | Done |
| Login | <user>@<domain> in the console's user field (alice@acme) | Done |
| Keystone rules in Skyline | The 204 keystone:* rules of Keystone 2026.2, checked with a domain-scoped manager persona (1,866 rules × 8 personas identical) | Done |
| Domain menu in the project console | Domain > Single Sign-On for users holding manager or admin on the domain | Done |
| Users, groups and projects of the domain from Skyline | The console's Identity pages stay reserved to system administrators: a manager uses ok or the API with a domain-scoped token | To do |
Deleting a customer: deletionPolicy: Retain disables the domain and keeps it; Delete removes it with its users, groups and projects. Details: openkeel-keystone/docs/CUSTOMERS.md.
Domain > Single Sign-On, Identity Provider tab: the manager connects the domain to the company's IdP (Keycloak, Entra ID, Okta…). The settings go to the domain's OpenKeelCustomer; the controller writes the identity provider, a mapping generated by OpenKeel (never written by the customer) and the openid protocol into Keystone.
| Setting | Role |
|---|---|
| Enabled | Turns the domain's single sign-on on or off |
| Issuer URL | The IdP's OpenID Connect issuer; its discovery document must be reachable |
| Client ID, Client Secret | The console's client at the IdP; the secret is write-only (kept when left empty) and stored in a Kubernetes Secret |
| User Name Claim | The claim that names the user in the domain (default preferred_username) |
| Groups Claim, Group Mapping | IdP groups turned into memberships of the domain's groups (cloud-admins = admins), groups created when missing |
| Button label | Text of the login button |
| Redirect URI | Shown by the page, to register in the IdP's client |
Users created through the IdP are shadow users of the customer's domain only. Not done yet: one console host per customer, so the login page still offers the IdPs of Skyline's configuration.
Domain > Single Sign-On, Users tab: nobody gets into the domain's projects without a manager's decision.
A user authenticated by the IdP is created in the domain with no role: shown Pending
The manager chooses a role: member, manager (on the domain, inherited by its projects) or none
none removes the roles and disables the user: Keystone revokes its tokens
Add User: identifier at the IdP, role and e-mail before the first login, which then finds the user and its role
The access and secret keys of OpenKeel's EC2 API (AWS CLI, boto3, Terraform), managed from the console under Keystone's ec2_* policies.
Identity > EC2 Credentials: the credentials of every user with user and project names; created for a chosen user and project, or deleted.
User menu, next to Application Credentials: the user creates credentials for one of their projects.
The creation forms quote what is being built through openkeel-pricing (POST /v1/quotes), with the unit rates of the project's OpenKeelTenant: cost per month (€) and carbon footprint per year (kg CO₂e).
| Where | What is shown |
|---|---|
| Instance form | Flavor, count, root and data volumes (the flavor's root disk is left out when the instance boots from a volume) |
| Volume form | Size and count |
| DNS zone, IPsec site connection | The yearly cost and footprint of the zone or the VPN |
| Quota popup of the forms | Two cards under the gauges: the project's estimated cost per month and carbon footprint per year, over its usage plus what the form adds (vCPUs, memory, volume capacity) |
Nothing is shown when the catalog has no pricing entry or no OpenKeelTenant sets the rates.
kubevirt_vmi_* series read from Prometheus by skyline-apiserver (GET /extension/server_metrics)skyline-console stays upstream: the openkeel-skyline image fetches a pinned console commit and applies the patches of openkeel-skyline/console-patches in order before building it. The build fails when a patch no longer applies, so a new console version is never shipped without them. Every string is in every locale (German and Chinese translated).
The server side is openkeel-skyline, the Go rewrite of skyline-apiserver: it proxies the new catalog types (pricing, rating, customer) like the OpenStack APIs and adds GET /extension/server_metrics.