Repository navigation
G5. RBAC / access diagnostics (whoami / can-i) #163
Description
Why
Data-plane RBAC + Managed Identity is one of the most-cited Cosmos DB frustrations: there is no Portal/Terraform surface for data-plane roles, role definition IDs are opaque, and — the core complaint — there is no way to verify your access short of running real application code. (See community discussion: https://old.reddit.com/r/AZURE/comments/1muu33b/cosmosdb_data_plane_rbac_is_absolutely_nightmare/)
Because the Shell already connects with the user's Entra/Managed-Identity credential and is RBAC-aware, it is the ideal place to answer "who am I and what can I actually do here?" This turns a top ecosystem pain point into a differentiated Shell capability, and it is especially valuable for agents/CI, which need to confirm permissions before attempting work.
Proposed behavior
whoami— show the authenticated identity, credential type, tenant, and (when available) the assigned Cosmos DB data-plane and control-plane role definitions/scopes.can-i <action> [--db --con]— probe whether the current identity can perform a given action (e.g.read,query,write,manage) against a scope, reporting allow/deny and the governing role assignment where determinable. Prefer a safe, non-mutating probe.
Acceptance criteria
whoamireports identity + resolvable role assignments.can-ireturns a clear allow/deny for read/query/write/manage without performing a destructive operation.- Works for Entra/Managed-Identity connections and degrades gracefully for key/emulator.
- Structured output.
- Docs + tests.
Filed from the Agentic & Automation Roadmap (docs/agentic-roadmap.md), item G5, Wave 2. Priority P2.
Activity
mkrueger commentedon Jul 8, 2026
I really like the idea - in fact I had problems with that as well.
Issue is that it is atm planed to remove ARM when entraid is fixed so there are some limits what's doable.
IMHO this is all a mess - but it's another discussion.
whoami is only useful with roles & scopes - this limits a bit the usefulness.
mkrueger commentedon Jul 8, 2026
PR #170 implements
whoamiandcan-ias data-plane-only commands, so it partially addresses this issue rather than fully closing it (leaving the issue open on purpose).Shipped
whoami— credential type + Entra identity decoded from the Cosmos access token (principal, tenant, application id, UPN, display name, identity type, token expiry). Signature is not validated; claims are for local display only.can-i <read|query|write|manage>— safe, non-mutating data-plane probes (point read /COUNTquery / delete of a random id) returningallow/deny/indeterminate.can-i→allow).--format(table/json/csv), plus docs and tests.Deferred (blocked on the ARM decision)
As noted above, role definitions/assignments are control-plane (ARM)-only, and ARM is planned for removal once Entra ID is fixed. So these acceptance-criteria items are intentionally not covered:
whoamiresolvable role assignments / scopescan-igoverning role assignmentmanageresult (currently alwaysindeterminate, since it can't be probed on the data plane)Once the ARM-vs-data-plane direction is settled, we can revisit the role/scope enumeration and either wire it to whichever surface survives or formally drop it from the acceptance criteria.
Add whoami and can-i data-plane access diagnostics