<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Label this issue](https://contributors.gitlab.com/manage-issue?action=label&projectId=278964&issueIid=630305) </details> <!--IssueSummary end--> ### Problem to solve A user of a GitLab Self-Managed instance cannot find out which plan that instance is licensed for. `GET /api/v4/license` requires an administrator, and it is the only endpoint that answers the question. Every client, tool and integration that needs to know what the instance supports therefore has to be told by hand, ask an administrator, or guess. Guessing is what happens, and that is the part worth stating plainly: the plan is **already inferable** by any authenticated user, by observing which licensed endpoints answer and which refuse. Epics, iterations and vulnerabilities either respond or they do not. What today's restriction protects is not the information, only the convenience of reading it, and the cost of that is paid by every integration in the ecosystem, each one reimplementing the same inference slightly differently. ### What a non-administrator can see today Measured rather than assumed. A licensed GitLab EE 19.3.1 was brought up in Docker with an administrator and an ordinary user (`is_admin: false`) on it, and the same endpoints were asked with both credentials. GitLab.com was asked the same questions with an ordinary account. **Self-Managed EE 19.3.1, licensed Ultimate** | Endpoint | Administrator | Ordinary user | | --- | --- | --- | | `GET /license` | `200`, `plan: ultimate` | `403 Forbidden` | | `GET /version` | `200`, `enterprise: true` | `200`, `enterprise: true` | | `GET /namespaces` | `200`, `plan: default` | `200`, `plan: default` | | `GET /features` | not asked | `403 Forbidden` | **GitLab.com, ordinary account** | Endpoint | Result | | --- | --- | | `GET /license` | `403 Forbidden` | | `GET /version` | `200`, `enterprise: true` | | `GET /namespaces` | `200`, `plan` present with real values | Three things follow, and the second one surprised me: 1. `enterprise` is the only licensing signal every authenticated caller already gets. It separates EE from CE and cannot separate Premium from Ultimate. 2. `/namespaces` carries no instance information on Self-Managed: `plan` reads `default` for administrator and ordinary user alike, because `gitlab_subscription` is a GitLab.com concept. It is not a workaround for Self-Managed. 3. On GitLab.com the plan is a property of the **namespace** rather than of the instance, and it is already exposed there to a caller who administers the namespace, under the `can_admin_namespace || has_gitlab_subscription` condition in `ee/lib/ee/api/entities/namespace.rb`. So the plan of a paid namespace is already readable by a non-administrator on GitLab.com. Only the Self-Managed instance plan is not. ### Prior proposals, and why this one is different Two open issues ask for this, both from 2020, both with their owning group now archived: - #247915, "Expose the GitLab tier to all users for self-hosted instances". Proposes a visual indicator on the help or instance configuration page. Carries ~"[deprecated] Accepting merge requests". - #219732, "Get license information via API using a non-admin user". Proposes opening `/api/v4/license` to all users, and is linked to two customer support tickets. Neither thread records a design objection. There is no comment in either saying the information should stay restricted, no counter-proposal and no decision. They have simply had no owner. What has most likely kept #219732 from moving is the shape of what it asks for, and I think that objection is correct: `/api/v4/license` returns the licensee name and email, the subscription identifier, the seat count, the expiry date and the historical seat usage. That is commercial and contractual data about the customer, and a non-admin user has no business reading it. Asking for that whole endpoint to be opened is a much larger request than the question anyone actually has. **The question is only "what plan is this instance on".** One string. That is what this issue proposes to expose, and nothing else. ### Proposal Add a `plan` field to the instance metadata already served to every authenticated user, in both the REST and GraphQL forms of it: - `GET /api/v4/metadata` and its `GET /api/v4/version` alias, next to `enterprise` - the `Metadata` GraphQL type, which is the same data and which the REST endpoint is already implemented on top of ```json { "version": "19.5.0-ee", "revision": "ceb07b24cb0", "kas": { "enabled": true, "externalUrl": "grpc://gitlab.example.com:8150", "externalK8sProxyUrl": "https://gitlab.example.com:8150/k8s-proxy", "version": "19.5.0" }, "enterprise": true, "plan": "ultimate" } ``` The value is: - the plan of the current license on a licensed instance: `starter`, `premium` or `ultimate` - `free` on an instance with no license, and on CE, where there is no license to read - `null` where subscriptions are held per namespace rather than per instance, which is GitLab.com. The instance license there says nothing about what any given caller may do, so reporting it would be worse than reporting nothing: a caller would read it as their own entitlement. Callers on GitLab.com already have the per-namespace `plan` described above, which is the right answer for them. ### Why this is safe to expose - **It is not a secret.** Any authenticated user can already determine it by probing licensed endpoints. This replaces an inference every client writes for itself with one authoritative string. - **It carries nothing commercial.** No licensee, no seats, no expiry, no subscription identifier, no customer name. Those stay where they are, behind the administrator check on `/license`, which this does not touch. - **It sits behind authentication.** `/api/v4/metadata` already requires a credential (`before { authenticate! }`), and the GraphQL type already requires `:read_instance_metadata`. Anonymous callers learn nothing new. - **It is the field next door.** `enterprise` is already served to the same callers by the same endpoint, and already discloses EE versus CE. Naming the plan is the same kind of statement about the same subject. ### Who wants this Any client that adapts its behaviour to the instance, which is most of them: - CLI tools and IDE integrations deciding which commands to offer - MCP servers and agent tooling deciding which capabilities to publish to a model. This is where I ran into it: the server I maintain resolves a tier per credential, and for every non-administrator it silently resolves Free and serves a Free catalogue on an Ultimate instance, with nothing in the tool listing explaining what was withheld. - CI jobs and scripts branching on whether a licensed feature exists, instead of calling it and handling the failure - Dashboards reporting on a fleet of instances without an administrator credential for each ### Permissions and security No new permission. The field is served to exactly the callers who can already read `/api/v4/metadata` and the `Metadata` GraphQL type today, which is any authenticated user. Nothing is exposed anonymously and no existing endpoint changes its authorization. ### Implementation A merge request implementing this accompanies the issue. It is small: the CE model answers `free`, an EE override reads `License.current&.plan` and returns nothing where subscriptions are per namespace, and the field is added to the GraphQL type, the REST query and the Grape entity. It follows the existing `Gitlab::Tracking::StandardContext` pattern for exactly this CE/EE split, including its `'free' # GitLab CE edition is always free` base case. ### Links and references - #247915, the Self-Managed tier visibility request - #219732, the non-admin license API request - #247920, the GitLab.com counterpart named in #247915 - `ee/lib/ee/api/entities/namespace.rb`, the existing per-namespace `plan` exposure - `lib/gitlab/tracking/standard_context.rb` and `ee/lib/ee/gitlab/tracking/standard_context.rb`, the CE/EE plan resolution pattern the implementation follows