docs(known-issues): StarRocks in-namespace endpoints and read-side row filters

platform/known-issues.md

@@ -410,6 +410,8 @@ Collected while writing the detailed pages for each area (October 2026), checked
 | 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 '<name>'@'%'`; Egret's next sync (within ten minutes, or at once on any membership change) re-creates the user and the grant. |
+| KI-360 | Engines / StarRocks | Security | S2 | A pod scheduled **inside a StarRocks engine's Kubernetes namespace** can read unauthenticated endpoints on the engine's own ports: the CN brpc built-in pages (`:8060/flags`, `/vars`), the FE metrics (`:8030/metrics`), and the FE thrift metadata port (`:9020`), which trusts the caller-supplied `current_user_ident` — so `getDbNames` returns the database list for whichever user the caller names. These disclose configuration, metrics and database **names**, not masked table rows. *Who is affected:* anyone who can run a pod in the engine namespace (`egret-engines`). *Mitigation:* the per-engine **NetworkPolicy** is the boundary and was measured to hold — from another namespace all five engine ports time out — so do not co-locate untrusted workloads in the engine namespace. Turning on `enable_http_auth` closes the BE-HTTP endpoints (`/varz`, `/greplog`, `/api/update_config`, `/api/_download_load`, `/api/_stop_be`) but not the brpc, FE-metrics or FE-thrift ports, and it currently 401s the CN's own Kubernetes health probes (startup/liveness/readiness all hit an unauthenticated `/api/health`), so it cannot be turned on without a paired probe change. *Measured 2026-11-09 on the egret fork image and on a real kind engine (probe 4).* |
+| KI-361 | Engines / StarRocks | Limitation | S3 | Row filters on a StarRocks table are **read-side only**, as in Trino: a user who holds a row filter that hides a row, and who also has write privilege, may still **overwrite** that row by writing (SQL `INSERT` or stream load), because the filter does not apply to the write path. The two write paths agree with each other; this is Egret's model, not a bypass. *Who is affected:* users granted both a row filter and write on the same table. *Mitigation:* do not rely on a row filter to keep a user from writing a row; deny the write with a grant where rows must stay beyond reach. *Measured 2026-11-09 (probe 3, check S10).* |
 
 ## Not verified