From 5b4cb119ce7a7ad7a10879d0fbbb6c42911a3349 Mon Sep 17 00:00:00 2001 From: 1Pro-L4R8 Date: Thu, 12 Nov 2026 06:26:04 +0700 Subject: [PATCH 1/3] docs(engines): StarRocks delegation users and engine lifecycle Co-Authored-By: Claude Opus 5.5 --- .../query-engines/engine-detail.md | 4 +++ .../control-plane/query-engines/provision.md | 6 ++++ platform/deploy-operate/engines-and-ranger.md | 33 ++++++++++++++++++- platform/deploy-operate/upgrade.md | 17 ++++++++++ platform/known-issues.md | 5 ++- .../rest-api/control-plane-engines.md | 2 +- platform/workspace-settings/databases.md | 2 +- 7 files changed, 65 insertions(+), 4 deletions(-) diff --git a/platform/control-plane/query-engines/engine-detail.md b/platform/control-plane/query-engines/engine-detail.md index 35ca26a..d4fd4f4 100644 --- a/platform/control-plane/query-engines/engine-detail.md +++ b/platform/control-plane/query-engines/engine-detail.md @@ -203,6 +203,10 @@ A Trino engine that has run before and now has no pod or container at all, for e Type the engine name and press **Delete**. You return to the Engines list. The dialog says *This destroys the engine's Kubernetes cluster. It cannot be undone.*, or on the Docker provisioner *This removes the engine's containers. It cannot be undone.* (measured: 7 seconds). The engine's policy profile is kept and appears under **Profiles without an engine** in Governance. +:::warning Deleting a StarRocks engine destroys its front-end metadata +The delete removes the engine's initpwd Job pods and the front end's metadata volumes (`fe-meta--fe-0` and any further ordinals) along with the cluster. That metadata holds the StarRocks users, catalogs, grants, the root password and the query log, and it cannot be recovered. Table data stays in object storage under the engine's storage path. Creating an engine of the same name afterwards starts with a fresh front end. +::: + ### Kubernetes-only features **Logs** and **Exec** work only with the Kubernetes provisioner, and are not shown for an engine Docker runs: diff --git a/platform/control-plane/query-engines/provision.md b/platform/control-plane/query-engines/provision.md index f52d579..e3bdda2 100644 --- a/platform/control-plane/query-engines/provision.md +++ b/platform/control-plane/query-engines/provision.md @@ -89,6 +89,12 @@ On the demo stack the default mode ran queries as the signed-in person in both c A StarRocks engine has its own configuration screen with sections such as **Replicas & resources**, **JVM**, **Per-node memory**, **Health probes**, **Graceful shutdown**, **Resource groups** and **Session properties**, plus a Security section for authentication and delegation. Attaching or detaching a catalog on StarRocks creates or drops it on the FE in place, without rolling the pods. StarRocks engines need the Kubernetes provisioner. +If an earlier StarRocks engine of the same name left its front-end metadata volume behind, **Create** is refused with *A previous StarRocks engine named "\" left its front-end metadata volume fe-meta-\-fe-0. A new engine would start with the old engine's users, catalogs and root password. Delete it first: kubectl delete pvc fe-meta-\-fe-0 -n egret-engines*. Run the command, then create the engine again. (A live engine of that name gets the usual "already exists" refusal.) + +```bash +kubectl delete pvc fe-meta--fe-0 -n egret-engines +``` + ## What happens next 1. Egret starts the cluster, creates a **policy profile** with the engine's name (for example `docs-trino`, with the tag service `docs-trino_tag`) and binds it. diff --git a/platform/deploy-operate/engines-and-ranger.md b/platform/deploy-operate/engines-and-ranger.md index 3dade84..c99da16 100644 --- a/platform/deploy-operate/engines-and-ranger.md +++ b/platform/deploy-operate/engines-and-ranger.md @@ -154,6 +154,7 @@ Egret writes its own policies into the profile of every engine that delegates qu the engine, by engine username. A disabled platform admin is not in them. - On Trino, three baseline policies: `egret-user-impersonate-self`, `egret-user-execute-query` and `egret-query-timeout`. - On a Trino engine that impersonates with a delegator account, also `egret-delegator-impersonate`. +- On a StarRocks engine in impersonation mode, also `egret-delegator-impersonate`, on the resource `user`. It lets the delegator `egret_delegator` run `EXECUTE AS` for every user except `root`, `egret_delegator` and `egret_query_log`. Egret derives this set from the engines bound to the profile and the active platform admins, and brings the stored policies in line with it. It adds a missing policy, updates one in place (the policy id stays the same), and deletes one @@ -166,7 +167,7 @@ finds nothing to change leaves the policy version where it was. So a policy that is no longer wanted goes away: -- `egret-delegator-impersonate` goes when the engine moves from impersonation to JWT; +- `egret-delegator-impersonate` goes when the engine moves from impersonation to JWT (on StarRocks too); - all of these policies go when the profile's last delegating engine is unbound or deleted; - the `egret-admin` policies go when there is no active platform admin. @@ -185,6 +186,36 @@ A change reaches an engine at the plugin's next download. Engine tokens already valid until they expire (at most 15 minutes), but a disabled admin's tokens no longer carry all access once the new policies are downloaded. +### StarRocks users for impersonation + +In impersonation mode egret runs each query on StarRocks as the person who started it (`EXECUTE AS`), and StarRocks can only do that for a user that exists. So egret creates the users itself; nobody has to configure a service user by hand. + +- **Who gets a user.** On an engine that serves at least one workspace, egret creates `''@'%'` for each member of each workspace the engine serves, and for each live platform admin. The password is random and nobody knows it, so nobody can log in as that user: it exists only for the delegator to become. A platform admin gets a user on every impersonation engine assigned to a workspace. +- **When a user is dropped.** egret drops a user it created when access ends: the person leaves the workspace, is disabled or deleted, loses `platform_admin`, or the engine is unassigned from every workspace or moved to JWT. Under JWT delegation egret does not use `EXECUTE AS` and keeps no users. +- **What it never touches.** egret drops only users it created, and keeps a record of them. A user it did not create is left as it is. The names `root`, `egret_delegator` and `egret_query_log` are never created, granted or dropped, and a person cannot be given the username `root` (they get `root-2`). +- **When it runs.** Database triggers start a sync on membership, role and user changes (a member added or removed, a group membership change, a role or platform-role grant, a user disabled, enabled or deleted). It also runs on every engine apply, once at server start, and every 10 minutes. A change takes effect within seconds; a failed step is logged and the next run tries again. +- **Native access control.** An engine bound to no policy profile has no Ranger row, so the delegator holds `GRANT IMPERSONATE ON USER ''@'%'` for exactly the users egret manages, and never `ON ALL USERS` (which would let it become `root`). egret adds the per-user grants first and revokes `ON ALL USERS` only after every grant landed. Before it drops a user it revokes that user's grant. An engine bound to a profile runs Ranger, which ignores native grants; there the row above is the control. + +#### Handing over a user egret did not create + +If a member's name is already held by a StarRocks user egret did not create (for example a test user made by hand), egret leaves it untouched and logs a warning naming it: `starrocks users: a member's name is held by a StarRocks user egret did not create; it is left as it is`. To hand it over, drop it as `root` on the FE. The next sync creates egret's own user of that name. + +```sql +DROP USER 'member-sso'@'%'; +``` + +:::warning Known issue: orphan IMPERSONATE grants (KI-358) +On an engine bound to no policy profile, StarRocks keeps the delegator's `IMPERSONATE ON USER 'u'@'%'` after `DROP USER 'u'@'%'`, and refuses to revoke it once `u` no longer exists. egret revokes before its own drops, but it cannot revoke a grant on a name whose user is already gone: one dropped before this release, or by someone other than egret. Anyone who later creates a user of that name can then be impersonated by the delegator. To clean up, as `root`, for each name that `SHOW GRANTS FOR 'egret_delegator'@'%'` lists and `SHOW USERS` does not, create the user temporarily with a random password, revoke, then drop: + +```sql +CREATE USER 'u'@'%' IDENTIFIED BY ''; +REVOKE IMPERSONATE ON USER 'u'@'%' FROM USER 'egret_delegator'@'%'; +DROP USER 'u'@'%'; +``` + +Engines bound to a policy profile are not affected: Ranger does not read the native grant. +::: + ### Authentication of the plugin Every request under `/ranger/service/` is authenticated. `ranger.auth_mode` (`EGRET_RANGER__AUTH_MODE`, Helm diff --git a/platform/deploy-operate/upgrade.md b/platform/deploy-operate/upgrade.md index c6fedcb..5b81eab 100644 --- a/platform/deploy-operate/upgrade.md +++ b/platform/deploy-operate/upgrade.md @@ -699,6 +699,23 @@ A provisioned StarRocks engine gets a [Query log](../control-plane/query-engines - **API change:** four routes under `/api/control-plane/engines/{id}/query-log`. See [Engines API](../reference/rest-api/control-plane-engines.md#get-apicontrol-planeenginesidquery-log). - Retention is 30 days, and there is no export and no rotation of the loader password. +### StarRocks impersonation, CN password and engine delete (platform #PR-NUMBER) + +- **StarRocks engines in impersonation mode start working under Ranger.** On upgrade, egret writes `egret-delegator-impersonate` to their profile and creates a StarRocks user for each member of each workspace the engine serves, within seconds of start. Users made by hand for earlier tests (for example a passwordless `member-sso`) are not egret's: they are left as they are and a warning names them. Drop them as `root` to let egret create its own; see [Handing over a user egret did not create](./engines-and-ranger.md#handing-over-a-user-egret-did-not-create). +- **Passworded StarRocks engines roll their FE and CN once** on their next apply, because `MYSQL_PWD` is now set on both. A CN that crash-loops today (KI-335) recovers then. An engine without a persistent front-end metadata volume loses its FE metadata on that roll, as on any roll. +- **Engine delete now removes the FE metadata volume.** The FE metadata of a deleted engine is gone; the table data stays in object storage. +- **Claims left by earlier deletes are not removed by the upgrade.** List them, and delete those whose engine no longer exists before re-creating an engine of the same name: + + ```bash + kubectl get pvc -n egret-engines | grep '^fe-meta-' + ``` + +- **A user named `root` cannot be minted any more** (the new user gets `root-2`). One who already holds it keeps it and is not synced to StarRocks. +- **Platform admins get a StarRocks user** on every impersonation-mode engine assigned to a workspace. +- **Engines bound to no profile lose `GRANT IMPERSONATE ON ALL USERS`.** On their next apply or sweep (at most ten minutes after the upgrade) the delegator gets per-user grants for egret's users instead, and can no longer become `root`. +- **Orphan IMPERSONATE grants** on users dropped before the upgrade stay. See the manual cleanup under [StarRocks users for impersonation](./engines-and-ranger.md#starrocks-users-for-impersonation) (KI-358). +- **Creating a StarRocks engine whose name left a metadata claim** answers 409 `engine_metadata_left_over` with the `kubectl` command that removes it. + ## Further reading - [Backup and restore](./backup-restore) diff --git a/platform/known-issues.md b/platform/known-issues.md index 1467f07..0a83d27 100644 --- a/platform/known-issues.md +++ b/platform/known-issues.md @@ -385,7 +385,7 @@ Collected while writing the detailed pages for each area (October 2026), checked | KI-332 | Engines / Policy profiles | Defect | S3 | Moving an engine to another policy profile with `PUT /api/control-plane/engines/{id}` (an `authzServiceId` other than the bound one) bumps the policy version of the old and the new profile in one `UPDATE`, from the engine-binding trigger of migration 0187, in no fixed order. Two such writes at the same time that lock the same two profiles in opposite orders can deadlock; the database then cancels one of them, which fails and changes nothing. The compile-mint lock is not involved, and the console's **Settings** tab of an external engine uses `PATCH …/external`, which locks both profiles first since platform #813. Not reproduced: found by reading the code. *Workaround:* retry the write. (Found while building platform #813.) | | KI-333 | Engines / Trino | Bug | S2 | A provisioned Trino engine whose **Per-user delegation** is **None (open engine)** gets none of the per-user baseline policies egret writes for a delegating engine (each user may become themself, run queries, and set `query_max_run_time` on their session). The Ranger plugin checks them on every session, so every query fails with *Principal X cannot become user X*. In the source, egret seeds the baseline only for an engine that delegates (JWT or impersonate). *Workaround:* use **Auto**, **JWT** or **Impersonate**. (Found in the live check of platform #818.) | | KI-334 | Governance / Data | Bug | S3 | The engines in the Governance **Data** page's object header can show a running engine as `provisioning`: in the live check of platform #818 the Trino engine `p7jwt` showed `provisioning` there, while the engine API said it was running. The header shows the `status` the governance browse API answers for each engine attached to the catalog, read from the stored engine row; why that row still said `provisioning` is not confirmed (seen with the Docker provisioner). Nothing else depends on the label. (Found in the live check of platform #818.) | -| KI-335 | Engines / StarRocks | Bug | S2 | On Kubernetes, a provisioned StarRocks engine can come up with its compute node (CN) in a crash loop. The CN spec carries no root password, while the `{name}-initpwd` Job sets the FE's root password first: when the CN starts after that, for example on a node that does not have the CN image cached yet and has to pull it, it cannot log in to the FE (`ERROR 1045`), queries fail with `ERROR 5904` *Warehouse default_warehouse is not available*, the engine stays `provisioning`, and the catalog attachment still says *applied*. *Steps:* provision a StarRocks engine on a fresh node without `starrocks/cn-ubuntu:4.1.6` cached. *Workaround:* give the CN the root password from the `{name}-initpwd-secret` Secret as `MYSQL_PWD` (`cnEnvVars` of the StarRocksCluster resource, `valueFrom.secretKeyRef`, key `password`), or pull the CN image onto the node before provisioning. (Found in the Wave 4 re-check on kind, StarRocks 4.1.6.) | +| KI-335 | Engines / StarRocks | Bug | S2 | **Fixed in platform #PR-NUMBER.** On Kubernetes, a provisioned StarRocks engine can come up with its compute node (CN) in a crash loop. The CN spec carries no root password, while the `{name}-initpwd` Job sets the FE's root password first: when the CN starts after that, for example on a node that does not have the CN image cached yet and has to pull it, it cannot log in to the FE (`ERROR 1045`), queries fail with `ERROR 5904` *Warehouse default_warehouse is not available*, the engine stays `provisioning`, and the catalog attachment still says *applied*. *Steps:* provision a StarRocks engine on a fresh node without `starrocks/cn-ubuntu:4.1.6` cached. *Workaround:* give the CN the root password from the `{name}-initpwd-secret` Secret as `MYSQL_PWD` (`cnEnvVars` of the StarRocksCluster resource, `valueFrom.secretKeyRef`, key `password`), or pull the CN image onto the node before provisioning. (Found in the Wave 4 re-check on kind, StarRocks 4.1.6.) The CN now gets `MYSQL_PWD`, as does the FE; an existing engine rolls its FE and CN once on its next apply. | | KI-336 | Engines / StarRocks | Gap | S2 | A StarRocks engine provisioned without a policy profile (no `authzServiceId`) stays without one, even when Ranger is on: egret creates a profile automatically only for a Trino engine, and **Add engine** has no profile picker for StarRocks. Such an engine is not governed by egret's policies, and in the re-check the admin saw no egret catalog on it and nothing said why. *Workaround:* create a StarRocks profile (**Engine & policy → New profile**, type **StarRocks**), then pass its id as `authzServiceId` when you create the engine through `POST /api/control-plane/engines`, or bind it afterwards with `PUT /api/control-plane/engines/{id}`. (Found in the Wave 4 re-check on kind.) *Status:* fixed in platform #847: with Ranger on, **Add engine** for StarRocks has a **Policy profile** select whose default creates a profile named after the engine, and an engine left without a profile shows **Not governed** (badge in the list, warning on its page). With Ranger off nothing is bound. | | KI-337 | Governance / Masks and row filters | Bug | S2 | **Fixed in Egret's patched StarRocks image `4.1.7-egret.3` (platform #827); open upstream.** On StarRocks (4.1.6 and later, an upstream StarRocks bug), when a row filter applies to a user, `SELECT *` on an Iceberg table returns two extra columns: `_file` (the object-store path of the data file) and `_pos` (the row's position). Users without a filter get the table's own columns; Trino is not affected. So the result has a different shape per user: `INSERT … SELECT *`, and datasets or charts built on `SELECT *`, can break for a filtered user, and an Iceberg view whose stored SQL is a literal `SELECT * FROM t` fails for that user with *Index N out of bounds*. With a mask on the table the query is refused instead (KI-304). The path is not a new disclosure: any reader can already get it with `SELECT _file` or from the table's `$files` metadata table (KI-340). *Workaround:* list the columns (`SELECT id, region, email …`); a view created from StarRocks stores the expanded column list and is not affected. Severity S2: wrong result shape with a workaround, no value the user could not read otherwise. (Found in the Wave 4 re-check; the cause is StarRocks' row-policy rewrite, which turns the hidden columns into visible ones.) | | KI-338 | SQL Lab / StarRocks | Bug | S2 | In SQL Lab, the schema explorer of a StarRocks connection lists StarRocks' default catalog (`_statistics_`, `information_schema`, `sys`), not the egret catalog the engine serves, so the tables you can query are not shown there. Queries work. *Workaround:* write fully qualified names (`..`). Severity S2: the explorer shows the wrong catalog, and a workaround exists. (Found in the Wave 4 re-check on kind.) | @@ -406,6 +406,9 @@ Collected while writing the detailed pages for each area (October 2026), checked | KI-353 | Governance / Trino on OPA | Gap | S2 | View lineage is not captured through a Trino engine whose profile is on OPA: OPA refuses the `egret-lineage` principal the unmasked reads the Ranger download gives it on JWT-mode engines, so its lineage `EXPLAIN` fails closed. *Workaround:* keep the profile on Ranger where view lineage matters. (Platform #839.) | | KI-354 | Governance / Trino on OPA | Gap | S1 | An external Trino 483 engine bound to its own compiled profile on OPA cannot run any query: the profile gets no infrastructure rows (query execution, self-impersonation), and no grant can add them, so Trino's per-query checks are denied. *Workaround:* keep such an engine's profile on Ranger. (Measured on the end-to-end stack for platform #839.) | | KI-355 | Engines / Trino | Security | S1 | **Fixed in platform #842 (November 2026).** A provisioned Trino engine could run with no authentication and accepted authentication over plain HTTP, so anyone who reached port 8080 and set `X-Trino-User` (or `--session-user`) ran queries as that user, impersonate-mode engines included. Every provisioned Trino engine now authenticates and refuses plain HTTP without `X-Forwarded-Proto: https` (403 *Authentication over HTTP is not enabled*; with the header and no credential, 401). Measured on Trino 483. `/v1/info` stays open; Egret's monitor and the ingress send the header with a credential (simulated, not measured against a real ingress controller). An engine applied before the fix keeps the old configuration until it is next applied: the engine list shows **Re-apply needed**. A client with no password must use the engine's ingress, or HTTPS 8443 where the engine serves it. External engines are not changed by Egret. | +| KI-356 | Engines / StarRocks | Bug | S1 | **Fixed in platform #PR-NUMBER.** A StarRocks engine in impersonation mode under Ranger could not run a query: the delegator had no right to impersonate (*IMPERSONATE*) and the members had no StarRocks user (*cannot find user*). egret now writes the `egret-delegator-impersonate` row and creates the users; see [StarRocks users for impersonation](deploy-operate/engines-and-ranger.md#starrocks-users-for-impersonation). | +| KI-357 | Engines / StarRocks | Bug | S2 | **Fixed in platform #PR-NUMBER.** Deleting a provisioned StarRocks engine left the `{name}-initpwd` Job pods and the FE metadata volumes. A same-name re-create then kept the old root password, users and catalogs. Delete now removes both, and a create refuses with 409 `engine_metadata_left_over` while an old claim exists. Claims left by earlier deletes stay until you delete them (see the upgrade notes). | +| KI-358 | Engines / StarRocks | Security | S2 | On an engine bound to no policy profile, a per-user `IMPERSONATE` grant of the delegator on a user that no longer exists cannot be revoked (StarRocks answers *cannot find user*), so egret does not clean it up: grants left by users dropped before platform #PR-NUMBER, or dropped outside egret. Whoever later creates a user of that name can be impersonated by the delegator. Not affected: engines bound to a Ranger profile. *Workaround:* as `root`, for each name `SHOW GRANTS FOR 'egret_delegator'@'%'` lists and `SHOW USERS` does not, `CREATE USER` it with a random password, `REVOKE IMPERSONATE ON USER … FROM USER 'egret_delegator'@'%'`, then `DROP USER`. | ## Not verified diff --git a/platform/reference/rest-api/control-plane-engines.md b/platform/reference/rest-api/control-plane-engines.md index a9c5cf7..58ef346 100644 --- a/platform/reference/rest-api/control-plane-engines.md +++ b/platform/reference/rest-api/control-plane-engines.md @@ -208,7 +208,7 @@ Operation id: `create_engine`. Auth: Session cookie and `X-Egret-CSRF` header. F | 400 | Unknown/unprovisioned warehouse, invalid input (including a StarRocks engine name longer than 48 characters: the operator derives 63-character pod volume names from it), or provisioning failed | | 401 | Not authenticated | | 403 | Missing engine:create permission | -| 409 | An engine with this name already exists, or its same-name policy profile is bound to another engine | +| 409 | An engine with this name already exists, or its same-name policy profile is bound to another engine; or (StarRocks, `code` = `engine_metadata_left_over`) a previous engine of this name left its front-end metadata volume. The body also carries `claim`, and the message ends with the command that removes it, `kubectl delete pvc -n `. A live engine of the same name gets the normal "already exists" refusal instead | | 500 | Internal error | ## POST `/api/control-plane/engines/external` diff --git a/platform/workspace-settings/databases.md b/platform/workspace-settings/databases.md index 419b6d7..b661ffd 100644 --- a/platform/workspace-settings/databases.md +++ b/platform/workspace-settings/databases.md @@ -60,7 +60,7 @@ Three switches decide whose identity the engine sees. They interact: read them t | Switch | What it does | Requires | |---|---|---| -| **Run queries as the logged-in user** (impersonation) | The engine runs each query as the person who started it, so the engine's own grants and policies apply to them. | Trino impersonation and Ranger. For StarRocks: *a StarRocks service user configured for EXECUTE AS + Ranger*. Shown for Trino and StarRocks only. | +| **Run queries as the logged-in user** (impersonation) | The engine runs each query as the person who started it, so the engine's own grants and policies apply to them. | Trino impersonation and Ranger. For StarRocks: egret creates the StarRocks users itself (one per workspace member and platform admin, see [StarRocks users for impersonation](../deploy-operate/engines-and-ranger.md#starrocks-users-for-impersonation)); with a policy profile bound, Ranger enforces the policies. Shown for Trino and StarRocks only. | | **Per-user delegation** | *Run queries as the signed-in user (requires SSO).* Egret presents a per-user engine JWT, so the engine knows the person. | An SSO sign-in. | | **Governed data** | Declares that the engine filters rows and masks columns per user. *Row filters and column masks are applied per user at the engine. Data API endpoints on this connection must run queries as the caller.* | | From b582c5915460d4757b1d7d25ef7b39a8ecce85b3 Mon Sep 17 00:00:00 2001 From: 1Pro-L4R8 Date: Thu, 12 Nov 2026 10:53:14 +0700 Subject: [PATCH 2/3] docs(engines): StarRocks lost create reply (KI-359) and the FE StatefulSet cascade Co-Authored-By: Claude Opus 5.5 --- platform/control-plane/query-engines/engine-detail.md | 2 ++ platform/known-issues.md | 1 + 2 files changed, 3 insertions(+) diff --git a/platform/control-plane/query-engines/engine-detail.md b/platform/control-plane/query-engines/engine-detail.md index d4fd4f4..0563071 100644 --- a/platform/control-plane/query-engines/engine-detail.md +++ b/platform/control-plane/query-engines/engine-detail.md @@ -205,6 +205,8 @@ Type the engine name and press **Delete**. You return to the Engines list. The d :::warning Deleting a StarRocks engine destroys its front-end metadata The delete removes the engine's initpwd Job pods and the front end's metadata volumes (`fe-meta--fe-0` and any further ordinals) along with the cluster. That metadata holds the StarRocks users, catalogs, grants, the root password and the query log, and it cannot be recovered. Table data stays in object storage under the engine's storage path. Creating an engine of the same name afterwards starts with a fresh front end. + +The same holds outside Egret: deleting the front end's StatefulSet with `kubectl delete sts` (default cascade) now deletes its metadata volumes too. To have the operator re-create the StatefulSet and keep the metadata, delete it with `--cascade=orphan`. ::: ### Kubernetes-only features diff --git a/platform/known-issues.md b/platform/known-issues.md index 0a83d27..45d5f71 100644 --- a/platform/known-issues.md +++ b/platform/known-issues.md @@ -409,6 +409,7 @@ Collected while writing the detailed pages for each area (October 2026), checked | KI-356 | Engines / StarRocks | Bug | S1 | **Fixed in platform #PR-NUMBER.** A StarRocks engine in impersonation mode under Ranger could not run a query: the delegator had no right to impersonate (*IMPERSONATE*) and the members had no StarRocks user (*cannot find user*). egret now writes the `egret-delegator-impersonate` row and creates the users; see [StarRocks users for impersonation](deploy-operate/engines-and-ranger.md#starrocks-users-for-impersonation). | | KI-357 | Engines / StarRocks | Bug | S2 | **Fixed in platform #PR-NUMBER.** Deleting a provisioned StarRocks engine left the `{name}-initpwd` Job pods and the FE metadata volumes. A same-name re-create then kept the old root password, users and catalogs. Delete now removes both, and a create refuses with 409 `engine_metadata_left_over` while an old claim exists. Claims left by earlier deletes stay until you delete them (see the upgrade notes). | | KI-358 | Engines / StarRocks | Security | S2 | On an engine bound to no policy profile, a per-user `IMPERSONATE` grant of the delegator on a user that no longer exists cannot be revoked (StarRocks answers *cannot find user*), so egret does not clean it up: grants left by users dropped before platform #PR-NUMBER, or dropped outside egret. Whoever later creates a user of that name can be impersonated by the delegator. Not affected: engines bound to a Ranger profile. *Workaround:* as `root`, for each name `SHOW GRANTS FOR 'egret_delegator'@'%'` lists and `SHOW USERS` does not, `CREATE USER` it with a random password, `REVOKE IMPERSONATE ON USER … FROM USER 'egret_delegator'@'%'`, then `DROP USER`. | +| KI-359 | Engines / StarRocks | Bug | S3 | If Egret loses the answer to the `CREATE USER` it sends for a member (a timeout or dropped connection after the front end ran it), the user exists on StarRocks but Egret has no record of creating it, so it treats it as a user it does not manage: it never drops it, and on an engine bound to no policy profile it never grants the delegator `IMPERSONATE` on it, so that member's queries fail with an *IMPERSONATE privilege* error. Engines bound to a Ranger profile are not affected. *Workaround:* as `root`, `DROP USER ''@'%'`; Egret's next sync (within ten minutes, or at once on any membership change) re-creates the user and the grant. | ## Not verified From 12ce1a1030b431239e1f7fb247c00a6ebccdfaa4 Mon Sep 17 00:00:00 2001 From: 1Pro-L4R8 Date: Thu, 12 Nov 2026 11:02:46 +0700 Subject: [PATCH 3/3] docs(engines): link platform #850 Co-Authored-By: Claude Opus 5.5 --- platform/deploy-operate/upgrade.md | 2 +- platform/known-issues.md | 8 ++++---- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/platform/deploy-operate/upgrade.md b/platform/deploy-operate/upgrade.md index 5b81eab..12f79d3 100644 --- a/platform/deploy-operate/upgrade.md +++ b/platform/deploy-operate/upgrade.md @@ -699,7 +699,7 @@ A provisioned StarRocks engine gets a [Query log](../control-plane/query-engines - **API change:** four routes under `/api/control-plane/engines/{id}/query-log`. See [Engines API](../reference/rest-api/control-plane-engines.md#get-apicontrol-planeenginesidquery-log). - Retention is 30 days, and there is no export and no rotation of the loader password. -### StarRocks impersonation, CN password and engine delete (platform #PR-NUMBER) +### StarRocks impersonation, CN password and engine delete (platform #850) - **StarRocks engines in impersonation mode start working under Ranger.** On upgrade, egret writes `egret-delegator-impersonate` to their profile and creates a StarRocks user for each member of each workspace the engine serves, within seconds of start. Users made by hand for earlier tests (for example a passwordless `member-sso`) are not egret's: they are left as they are and a warning names them. Drop them as `root` to let egret create its own; see [Handing over a user egret did not create](./engines-and-ranger.md#handing-over-a-user-egret-did-not-create). - **Passworded StarRocks engines roll their FE and CN once** on their next apply, because `MYSQL_PWD` is now set on both. A CN that crash-loops today (KI-335) recovers then. An engine without a persistent front-end metadata volume loses its FE metadata on that roll, as on any roll. diff --git a/platform/known-issues.md b/platform/known-issues.md index 45d5f71..19d3772 100644 --- a/platform/known-issues.md +++ b/platform/known-issues.md @@ -385,7 +385,7 @@ Collected while writing the detailed pages for each area (October 2026), checked | KI-332 | Engines / Policy profiles | Defect | S3 | Moving an engine to another policy profile with `PUT /api/control-plane/engines/{id}` (an `authzServiceId` other than the bound one) bumps the policy version of the old and the new profile in one `UPDATE`, from the engine-binding trigger of migration 0187, in no fixed order. Two such writes at the same time that lock the same two profiles in opposite orders can deadlock; the database then cancels one of them, which fails and changes nothing. The compile-mint lock is not involved, and the console's **Settings** tab of an external engine uses `PATCH …/external`, which locks both profiles first since platform #813. Not reproduced: found by reading the code. *Workaround:* retry the write. (Found while building platform #813.) | | KI-333 | Engines / Trino | Bug | S2 | A provisioned Trino engine whose **Per-user delegation** is **None (open engine)** gets none of the per-user baseline policies egret writes for a delegating engine (each user may become themself, run queries, and set `query_max_run_time` on their session). The Ranger plugin checks them on every session, so every query fails with *Principal X cannot become user X*. In the source, egret seeds the baseline only for an engine that delegates (JWT or impersonate). *Workaround:* use **Auto**, **JWT** or **Impersonate**. (Found in the live check of platform #818.) | | KI-334 | Governance / Data | Bug | S3 | The engines in the Governance **Data** page's object header can show a running engine as `provisioning`: in the live check of platform #818 the Trino engine `p7jwt` showed `provisioning` there, while the engine API said it was running. The header shows the `status` the governance browse API answers for each engine attached to the catalog, read from the stored engine row; why that row still said `provisioning` is not confirmed (seen with the Docker provisioner). Nothing else depends on the label. (Found in the live check of platform #818.) | -| KI-335 | Engines / StarRocks | Bug | S2 | **Fixed in platform #PR-NUMBER.** On Kubernetes, a provisioned StarRocks engine can come up with its compute node (CN) in a crash loop. The CN spec carries no root password, while the `{name}-initpwd` Job sets the FE's root password first: when the CN starts after that, for example on a node that does not have the CN image cached yet and has to pull it, it cannot log in to the FE (`ERROR 1045`), queries fail with `ERROR 5904` *Warehouse default_warehouse is not available*, the engine stays `provisioning`, and the catalog attachment still says *applied*. *Steps:* provision a StarRocks engine on a fresh node without `starrocks/cn-ubuntu:4.1.6` cached. *Workaround:* give the CN the root password from the `{name}-initpwd-secret` Secret as `MYSQL_PWD` (`cnEnvVars` of the StarRocksCluster resource, `valueFrom.secretKeyRef`, key `password`), or pull the CN image onto the node before provisioning. (Found in the Wave 4 re-check on kind, StarRocks 4.1.6.) The CN now gets `MYSQL_PWD`, as does the FE; an existing engine rolls its FE and CN once on its next apply. | +| KI-335 | Engines / StarRocks | Bug | S2 | **Fixed in platform #850.** On Kubernetes, a provisioned StarRocks engine can come up with its compute node (CN) in a crash loop. The CN spec carries no root password, while the `{name}-initpwd` Job sets the FE's root password first: when the CN starts after that, for example on a node that does not have the CN image cached yet and has to pull it, it cannot log in to the FE (`ERROR 1045`), queries fail with `ERROR 5904` *Warehouse default_warehouse is not available*, the engine stays `provisioning`, and the catalog attachment still says *applied*. *Steps:* provision a StarRocks engine on a fresh node without `starrocks/cn-ubuntu:4.1.6` cached. *Workaround:* give the CN the root password from the `{name}-initpwd-secret` Secret as `MYSQL_PWD` (`cnEnvVars` of the StarRocksCluster resource, `valueFrom.secretKeyRef`, key `password`), or pull the CN image onto the node before provisioning. (Found in the Wave 4 re-check on kind, StarRocks 4.1.6.) The CN now gets `MYSQL_PWD`, as does the FE; an existing engine rolls its FE and CN once on its next apply. | | KI-336 | Engines / StarRocks | Gap | S2 | A StarRocks engine provisioned without a policy profile (no `authzServiceId`) stays without one, even when Ranger is on: egret creates a profile automatically only for a Trino engine, and **Add engine** has no profile picker for StarRocks. Such an engine is not governed by egret's policies, and in the re-check the admin saw no egret catalog on it and nothing said why. *Workaround:* create a StarRocks profile (**Engine & policy → New profile**, type **StarRocks**), then pass its id as `authzServiceId` when you create the engine through `POST /api/control-plane/engines`, or bind it afterwards with `PUT /api/control-plane/engines/{id}`. (Found in the Wave 4 re-check on kind.) *Status:* fixed in platform #847: with Ranger on, **Add engine** for StarRocks has a **Policy profile** select whose default creates a profile named after the engine, and an engine left without a profile shows **Not governed** (badge in the list, warning on its page). With Ranger off nothing is bound. | | KI-337 | Governance / Masks and row filters | Bug | S2 | **Fixed in Egret's patched StarRocks image `4.1.7-egret.3` (platform #827); open upstream.** On StarRocks (4.1.6 and later, an upstream StarRocks bug), when a row filter applies to a user, `SELECT *` on an Iceberg table returns two extra columns: `_file` (the object-store path of the data file) and `_pos` (the row's position). Users without a filter get the table's own columns; Trino is not affected. So the result has a different shape per user: `INSERT … SELECT *`, and datasets or charts built on `SELECT *`, can break for a filtered user, and an Iceberg view whose stored SQL is a literal `SELECT * FROM t` fails for that user with *Index N out of bounds*. With a mask on the table the query is refused instead (KI-304). The path is not a new disclosure: any reader can already get it with `SELECT _file` or from the table's `$files` metadata table (KI-340). *Workaround:* list the columns (`SELECT id, region, email …`); a view created from StarRocks stores the expanded column list and is not affected. Severity S2: wrong result shape with a workaround, no value the user could not read otherwise. (Found in the Wave 4 re-check; the cause is StarRocks' row-policy rewrite, which turns the hidden columns into visible ones.) | | KI-338 | SQL Lab / StarRocks | Bug | S2 | In SQL Lab, the schema explorer of a StarRocks connection lists StarRocks' default catalog (`_statistics_`, `information_schema`, `sys`), not the egret catalog the engine serves, so the tables you can query are not shown there. Queries work. *Workaround:* write fully qualified names (`..
`). Severity S2: the explorer shows the wrong catalog, and a workaround exists. (Found in the Wave 4 re-check on kind.) | @@ -406,9 +406,9 @@ Collected while writing the detailed pages for each area (October 2026), checked | KI-353 | Governance / Trino on OPA | Gap | S2 | View lineage is not captured through a Trino engine whose profile is on OPA: OPA refuses the `egret-lineage` principal the unmasked reads the Ranger download gives it on JWT-mode engines, so its lineage `EXPLAIN` fails closed. *Workaround:* keep the profile on Ranger where view lineage matters. (Platform #839.) | | KI-354 | Governance / Trino on OPA | Gap | S1 | An external Trino 483 engine bound to its own compiled profile on OPA cannot run any query: the profile gets no infrastructure rows (query execution, self-impersonation), and no grant can add them, so Trino's per-query checks are denied. *Workaround:* keep such an engine's profile on Ranger. (Measured on the end-to-end stack for platform #839.) | | KI-355 | Engines / Trino | Security | S1 | **Fixed in platform #842 (November 2026).** A provisioned Trino engine could run with no authentication and accepted authentication over plain HTTP, so anyone who reached port 8080 and set `X-Trino-User` (or `--session-user`) ran queries as that user, impersonate-mode engines included. Every provisioned Trino engine now authenticates and refuses plain HTTP without `X-Forwarded-Proto: https` (403 *Authentication over HTTP is not enabled*; with the header and no credential, 401). Measured on Trino 483. `/v1/info` stays open; Egret's monitor and the ingress send the header with a credential (simulated, not measured against a real ingress controller). An engine applied before the fix keeps the old configuration until it is next applied: the engine list shows **Re-apply needed**. A client with no password must use the engine's ingress, or HTTPS 8443 where the engine serves it. External engines are not changed by Egret. | -| KI-356 | Engines / StarRocks | Bug | S1 | **Fixed in platform #PR-NUMBER.** A StarRocks engine in impersonation mode under Ranger could not run a query: the delegator had no right to impersonate (*IMPERSONATE*) and the members had no StarRocks user (*cannot find user*). egret now writes the `egret-delegator-impersonate` row and creates the users; see [StarRocks users for impersonation](deploy-operate/engines-and-ranger.md#starrocks-users-for-impersonation). | -| KI-357 | Engines / StarRocks | Bug | S2 | **Fixed in platform #PR-NUMBER.** Deleting a provisioned StarRocks engine left the `{name}-initpwd` Job pods and the FE metadata volumes. A same-name re-create then kept the old root password, users and catalogs. Delete now removes both, and a create refuses with 409 `engine_metadata_left_over` while an old claim exists. Claims left by earlier deletes stay until you delete them (see the upgrade notes). | -| KI-358 | Engines / StarRocks | Security | S2 | On an engine bound to no policy profile, a per-user `IMPERSONATE` grant of the delegator on a user that no longer exists cannot be revoked (StarRocks answers *cannot find user*), so egret does not clean it up: grants left by users dropped before platform #PR-NUMBER, or dropped outside egret. Whoever later creates a user of that name can be impersonated by the delegator. Not affected: engines bound to a Ranger profile. *Workaround:* as `root`, for each name `SHOW GRANTS FOR 'egret_delegator'@'%'` lists and `SHOW USERS` does not, `CREATE USER` it with a random password, `REVOKE IMPERSONATE ON USER … FROM USER 'egret_delegator'@'%'`, then `DROP USER`. | +| KI-356 | Engines / StarRocks | Bug | S1 | **Fixed in platform #850.** A StarRocks engine in impersonation mode under Ranger could not run a query: the delegator had no right to impersonate (*IMPERSONATE*) and the members had no StarRocks user (*cannot find user*). egret now writes the `egret-delegator-impersonate` row and creates the users; see [StarRocks users for impersonation](deploy-operate/engines-and-ranger.md#starrocks-users-for-impersonation). | +| KI-357 | Engines / StarRocks | Bug | S2 | **Fixed in platform #850.** Deleting a provisioned StarRocks engine left the `{name}-initpwd` Job pods and the FE metadata volumes. A same-name re-create then kept the old root password, users and catalogs. Delete now removes both, and a create refuses with 409 `engine_metadata_left_over` while an old claim exists. Claims left by earlier deletes stay until you delete them (see the upgrade notes). | +| KI-358 | Engines / StarRocks | Security | S2 | On an engine bound to no policy profile, a per-user `IMPERSONATE` grant of the delegator on a user that no longer exists cannot be revoked (StarRocks answers *cannot find user*), so egret does not clean it up: grants left by users dropped before platform #850, or dropped outside egret. Whoever later creates a user of that name can be impersonated by the delegator. Not affected: engines bound to a Ranger profile. *Workaround:* as `root`, for each name `SHOW GRANTS FOR 'egret_delegator'@'%'` lists and `SHOW USERS` does not, `CREATE USER` it with a random password, `REVOKE IMPERSONATE ON USER … FROM USER 'egret_delegator'@'%'`, then `DROP USER`. | | KI-359 | Engines / StarRocks | Bug | S3 | If Egret loses the answer to the `CREATE USER` it sends for a member (a timeout or dropped connection after the front end ran it), the user exists on StarRocks but Egret has no record of creating it, so it treats it as a user it does not manage: it never drops it, and on an engine bound to no policy profile it never grants the delegator `IMPERSONATE` on it, so that member's queries fail with an *IMPERSONATE privilege* error. Engines bound to a Ranger profile are not affected. *Workaround:* as `root`, `DROP USER ''@'%'`; Egret's next sync (within ten minutes, or at once on any membership change) re-creates the user and the grant. | ## Not verified