docs: access design + verification guides for multi-org (MSSP) deployments#192
Merged
docs: access design + verification guides for multi-org (MSSP) deployments#192
Conversation
Covers reviewing direct users, organization groups, effective permissions, and audit logs — so administrators can confirm that only intended members have access to a production tenant. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…oyments Explains how to structure organizations, Organization Groups, and predefined roles when operating many tenants — covering internal staff access via job-function groups, direct-only access for end-customer users, prod/non-prod separation, hardening (strict SSO, org API keys, group owner vs. member), a new-customer onboarding checklist, and common anti-patterns. Linked from the administration index, the admin nav, and from the top of user-access.md for multi-org operators. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
maximelb
changed the title
- limacharlie auth use → limacharlie auth use-org (the actual subcommand; `use` does not exist). - Drop "tamper-evident" from the audit trail description (LC's stream-structures doc explicitly recommends forwarding audit to tamper-proof storage, implying the built-in log isn't itself tamper-proof); add a pointer to the audit-stream Output option. - Group workflow: the group CLI takes a raw permission list; there is no role-preset flag for groups as there is for direct users. Updated the staff-groups table and workflow step 3 to reflect this, and documented the correct `group permissions-set --gid … --permissions …` form. - Group create example now includes --name (required flag). - Onboarding step "transfer ownership" clarified: adding a second Owner is self-serve via set-role; billing/legal ownership transfer is a separate support request. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
GitHub's Mermaid renderer rejected the quoted subgraph-label form (subgraph Id["..."]), the cylinder-shaped nodes ([(...)]), and the labeled dotted arrow (-.label.->) with: "Cannot read properties of undefined (reading 'render')" Switch to the older, more widely-supported syntax: - subgraph Id [Plain Label] - plain rectangular nodes - unlabeled dotted arrows Also drop parentheses from subgraph labels as belt-and-braces against stricter Mermaid parsers. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Mermaid's classic parser tokenizes '@' as LINK_ID inside unquoted bracket labels, which triggers: Expecting '...', got 'LINK_ID' Use plain person names in the end-user nodes instead — the subgraph label already conveys that these are end-customer users added directly to their own org. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
maximelb
added
the
to-code-review
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Adds two documentation pieces, both aimed at administrators standing up new organizations (especially MSSPs / MDRs with their own end customers):
New page
7-administration/access/designing-access.md— Designing Access for Multi-Org Deployments. Architectural guidance for structuring orgs, Organization Groups, and predefined roles when you have internal staff that spans many tenants and end customers that must stay confined to their own tenant. Covers the recommended architecture (with a diagram), staff-access pattern, end-customer access pattern, prod/non-prod separation, hardening (strict SSO, org API keys, group owner vs. member), a new-customer onboarding checklist, and common anti-patterns.New section inside
7-administration/access/user-access.md— Verifying and Reviewing Access. Mechanics for confirming exactly who can reach an organization and with which permissions — direct users, Organization Groups, effective per-user permissions, and the audit trail — with both web-UI andlimacharlieCLI steps, plus a validation checklist for a production tenant.The administration index, mkdocs nav, and the top of
user-access.mdare updated to surface the new design page.Context
A customer asked two related questions: how to ensure only selected members have access to a newly-created production org (answered by the verification section), and — especially as an MSSP — how to best architect access across their own staff plus their own customers (answered by the new design page).
Existing docs explained the mechanics of granting access and touched on MSSP RBAC conceptually, but did not provide either a verification playbook or an architectural design guide. These additions fill both gaps.
Test plan
mkdocs serverenders both pages; Mermaid diagram on the new page displays correctlyuser-access.md,api-keys.md,sso.md,permissions.md,infrastructure.md,account-management.md,mssp-msp-mdr.md)limacharlie user …,group …,audit list) match current CLI behaviour!!! tip,!!! warning,!!! note) render in the chosen theme🤖 Generated with Claude Code