fix: Permission docs #433
Merged
fix: Permission docs #433
+431
−0
Conversation
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
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
✅ Deploy Preview for canarychecker canceled.
|
❌ Deploy Preview for flanksource-docs failed. Why did it fail? →
|
adityathebe
force-pushed
the
fix-permission-docs
branch
from
dec2461 to
beddf82
Compare
adityathebe
force-pushed
the
fix-permission-docs
branch
from
beddf82 to
8240db4
Compare
WalkthroughAdds comprehensive documentation for Mission Control's permission Scopes: a core concept guide and an Examples section with multiple pages illustrating selector logic, global and per-resource targeting, wildcard usage, agent/tag/canary/playbook targeting, multiple-resource targets, and multi-tenancy isolation patterns. Changes
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 inconclusive)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches🧪 Generate unit tests (beta)
No actionable comments were generated in the recent review. 🎉 🧹 Recent nitpick comments
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 15
🤖 Fix all issues with AI agents
In `@mission-control/docs/guide/permissions/concepts/scope.md`:
- Line 48: Replace the passive sentence "Scopes are designed to work seamlessly
with Attribute-Based Access Control (ABAC)" with an active-voice construction;
update the line that references Scopes and ABAC (the sentence containing "Scopes
are designed to work seamlessly") to an active form such as "We designed Scopes
to work seamlessly with Attribute‑Based Access Control (ABAC)" or "Scopes work
seamlessly with Attribute‑Based Access Control (ABAC)" so the document uses
active voice consistently.
- Line 73: Line reads "If the resource matches any target in any of the user's
Scopes, access is granted" and uses passive voice; change it to active voice by
replacing "access is granted" with an active subject, e.g., "the system grants
access" (resulting sentence: "If the resource matches any target in any of the
user's Scopes, the system grants access (subject to action restrictions)").
Update that sentence in scope.md accordingly.
- Line 14: Rewrite the passive sentence describing how multiple targets combine
into an active-voice sentence: replace "Multiple targets within a Scope are
combined with OR logic" with an active construction such as "When a Scope
contains multiple targets, the system combines them with OR logic, so a resource
matches the Scope if it matches any target"; update the line describing
Scope/targets to use this active phrasing and keep the rest of the sentence
about a resource matching any target intact.
- Around line 50-64: Replace the inline YAML example in scope.md (the Permission
example for dev-team-access) with a code block using the file= directive
pointing to a fixture and create that fixture; specifically remove the inline
Permission YAML and add a ```yaml title="dev-team-access.yaml" file=...```
block, then add a fixture named dev-team-access.yaml in the mission-control
submodule fixtures/permissions containing the original YAML (kind: Permission,
metadata.name: dev-team-access, subjects: Group dev-team, scopes:
[prod-agent-configs], actions: [read, update]) so the docs import the example
instead of embedding it inline.
In `@mission-control/docs/guide/permissions/examples/combining-selectors.md`:
- Around line 7-20: Replace the inline YAML with a code block that uses the
file= import directive pointing to a fixture named prod-west-configs.yaml and
create that fixture in the mission-control module fixtures (scopes) containing
the same Scope resource (kind: Scope, metadata.name: prod-west-configs,
namespace: default, spec.description: "Production configs in us-west region from
specific agent", spec.targets: - config: agent: agent-west-1, namespace:
production, tagSelector: "region=us-west"); update the doc code block to use
```yaml title="prod-west-configs.yaml" file=<point to that mission-control
fixture>``` so the example is imported rather than inlined.
In
`@mission-control/docs/guide/permissions/examples/global-resource-selectors.md`:
- Around line 7-18: Replace the inline YAML in global-resource-selectors.md with
a file-import code block that references the fixture file named
namespace-restricted.yaml (e.g. ```yaml title="namespace-restricted.yaml"
file=...```) and create that fixture in the mission-control module's
fixtures/scopes directory; the new fixture must contain the original Scope
manifest (kind: Scope, metadata.name: namespace-restricted, metadata.namespace:
default, spec.description: "All resources in specific namespace", spec.targets
-> global.namespace: restricted-zone) so the documentation imports the example
instead of inlining it.
- Around line 40-59: Replace the two inline YAML examples with imported
fixtures: create fixture files named global-example.yaml and
individual-targets-example.yaml inside the mission-control fixtures scopes, then
replace the inline code blocks in global-resource-selectors.md with fenced code
blocks using the file= directive to reference those two fixture filenames (keep
the title attributes as shown). Locate the existing inline blocks in
global-resource-selectors.md (the "global" example and the "Using individual
targets" example) and swap them for the file-import style code fences that point
to the new mission-control fixture files.
In `@mission-control/docs/guide/permissions/examples/multi-tenancy-patterns.md`:
- Line 68: The sentence "Each customer's resources are tagged appropriately, and
Scopes ensure customer data isolation." uses passive voice; replace it with an
active-voice construction such as "We tag each customer's resources and use
Scopes to ensure customer data isolation." Locate the sentence (the line
containing "Each customer's resources are tagged appropriately") and update it
to the active phrasing so the subject performs the actions ("We tag..." / "The
system tags...") and retain the mention of Scopes for isolation.
- Around line 34-47: Replace the inline YAML example for the Scope named
"platform-team-resources" with a code block that uses the file= directive (and
title "platform-team-resources.yaml") and create a fixture file in the
mission-control module's fixtures/scopes named platform-team-resources.yaml
containing the original YAML (apiVersion: mission-control.flanksource.com/v1,
kind: Scope, metadata.name: platform-team-resources, metadata.namespace:
default, spec.description, spec.targets with config/component namespace:
platform-team). Update the code block in multi-tenancy-patterns.md to reference
that fixture file instead of embedding the YAML.
- Around line 11-26: Replace the inline YAML block in multi-tenancy-patterns.md
with a code block using the file= directive that references a fixture (title
"production-resources.yaml"); then add a fixture file named
production-resources.yaml under the mission-control module's fixtures/scopes
directory containing the original Scope manifest (kind: Scope, metadata.name:
production-resources, metadata.namespace: default, spec.description: All
production resources, spec.targets with config/component/playbook tagSelector
"env=production") so the document imports the example instead of embedding it
inline.
- Around line 74-86: Replace the inline YAML in multi-tenancy-patterns.md (the
Scope example named team-a-prod-west) with a YAML code block using the file=
directive (title "team-a-prod-west.yaml" and file pointing to the fixture), and
create the corresponding fixture file team-a-prod-west.yaml under the
mission-control fixtures scopes directory containing the original Scope YAML
(apiVersion: mission-control.flanksource.com/v1, kind: Scope, metadata
name/team-a-prod-west namespace/default, spec description and targets with
config namespace/tagSelector) so the docs import the example instead of
embedding it inline.
- Around line 55-66: Replace the inline YAML block in
mission-control/docs/guide/permissions/examples/multi-tenancy-patterns.md with a
code block that uses the file= directive pointing to a fixture named
customer-acme-resources.yaml, and add that fixture to the mission-control
fixtures (scopes) submodule; the fixture should contain the original Scope
resource with metadata.name customer-acme-resources, metadata.namespace default
and the spec (description: "All resources for ACME Corp" and targets -> config
-> tagSelector: "customer=acme"). Ensure the code block uses
title="customer-acme-resources.yaml" and the file= directive referencing the new
fixture.
In `@mission-control/docs/guide/permissions/examples/multiple-resource-types.md`:
- Around line 7-22: Replace the inline YAML example for the Scope resource named
"monitoring-stack" with a code block using the file= directive (e.g., ```yaml
title="monitoring-stack.yaml" file=...```), and create the referenced fixture
file containing the original YAML content (Scope, metadata.name
monitoring-stack, namespace default, spec.description and targets for
config/component/canary with tagSelector "app=prometheus") in the
mission-control module's fixtures for scopes so the documentation imports the
example instead of embedding it inline.
In `@mission-control/docs/guide/permissions/examples/targeting-by-tags.md`:
- Line 5: Rewrite the passive sentence "Tag-based scoping is the most flexible
approach as it allows resources to be added or removed from the scope by simply
updating their tags." to active voice; for example, change it to "Tag-based
scoping is the most flexible approach because you can add or remove resources
from the scope by simply updating their tags." Update that sentence in the
document so the paragraph uses active voice throughout.
In `@mission-control/docs/guide/permissions/examples/targeting-with-wildcards.md`:
- Line 14: Rewrite the passive sentence to active voice: change "Prefix and
suffix wildcards (e.g., `nginx-*` or `*-prod`) are **NOT** supported." to an
active construction referencing the product (e.g., "Mission Control does **NOT**
support prefix and suffix wildcards (e.g., `nginx-*` or `*-prod`)."), leaving
the earlier clause about the `name` field and the special wildcard directive `*`
unchanged.
🧹 Nitpick comments (1)
mission-control/docs/guide/permissions/examples/multi-tenancy-patterns.md (1)
5-5: Consider rewording for stronger active voice.While not strictly passive, "Scopes are fundamental" could be rewritten more actively to align with Google Style Guide recommendations.
✍️ Suggested rewrite
-Scopes are fundamental to implementing multi-tenancy in Mission Control. Here are common patterns for partitioning resources across different tenants, teams, or organizational units. +Scopes provide the foundation for implementing multi-tenancy in Mission Control. The following sections describe common patterns for partitioning resources across different tenants, teams, or organizational units.
Comment on lines
50
to
64
| ```yaml | ||
| apiVersion: mission-control.flanksource.com/v1 | ||
| kind: Permission | ||
| metadata: | ||
| name: dev-team-access | ||
| spec: | ||
| subjects: | ||
| - kind: Group | ||
| name: dev-team | ||
| scopes: | ||
| - prod-agent-configs # Reference to Scope | ||
| actions: | ||
| - read | ||
| - update | ||
| ``` |
There was a problem hiding this comment.
Replace inline YAML with file= directive import.
The YAML example is written directly in the documentation, which violates the coding guidelines. As per coding guidelines: "Never write YAML examples directly; import examples from submodules (mission-control, duty, config-db, canary-checker) using code blocks with file= directive."
📝 Required change
-```yaml
-apiVersion: mission-control.flanksource.com/v1
-kind: Permission
-metadata:
- name: dev-team-access
-spec:
- subjects:
- - kind: Group
- name: dev-team
- scopes:
- - prod-agent-configs # Reference to Scope
- actions:
- - read
- - update
-```
+```yaml title="dev-team-access.yaml" file=<rootDir>/modules/mission-control/fixtures/permissions/dev-team-access.yaml
+
+```Create the corresponding fixture file in the mission-control submodule.
🤖 Prompt for AI Agents
In `@mission-control/docs/guide/permissions/concepts/scope.md` around lines 50 -
64, Replace the inline YAML example in scope.md (the Permission example for
dev-team-access) with a code block using the file= directive pointing to a
fixture and create that fixture; specifically remove the inline Permission YAML
and add a ```yaml title="dev-team-access.yaml" file=...``` block, then add a
fixture named dev-team-access.yaml in the mission-control submodule
fixtures/permissions containing the original YAML (kind: Permission,
metadata.name: dev-team-access, subjects: Group dev-team, scopes:
[prod-agent-configs], actions: [read, update]) so the docs import the example
instead of embedding it inline.
Comment on lines
7
to
20
| ```yaml | ||
| apiVersion: mission-control.flanksource.com/v1 | ||
| kind: Scope | ||
| metadata: | ||
| name: prod-west-configs | ||
| namespace: default | ||
| spec: | ||
| description: Production configs in us-west region from specific agent | ||
| targets: | ||
| - config: | ||
| agent: agent-west-1 | ||
| namespace: production | ||
| tagSelector: "region=us-west" | ||
| ``` |
There was a problem hiding this comment.
Replace inline YAML with file= directive import.
The YAML example is written directly in the documentation, which violates the coding guidelines. All YAML examples must be imported from submodules using the file= directive. As per coding guidelines: "Never write YAML examples directly; import examples from submodules (mission-control, duty, config-db, canary-checker) using code blocks with file= directive."
📝 Required change
-```yaml
-apiVersion: mission-control.flanksource.com/v1
-kind: Scope
-metadata:
- name: prod-west-configs
- namespace: default
-spec:
- description: Production configs in us-west region from specific agent
- targets:
- - config:
- agent: agent-west-1
- namespace: production
- tagSelector: "region=us-west"
-```
+```yaml title="prod-west-configs.yaml" file=<rootDir>/modules/mission-control/fixtures/scopes/prod-west-configs.yaml
+
+```You'll need to create the corresponding fixture file in the mission-control submodule.
🤖 Prompt for AI Agents
In `@mission-control/docs/guide/permissions/examples/combining-selectors.md`
around lines 7 - 20, Replace the inline YAML with a code block that uses the
file= import directive pointing to a fixture named prod-west-configs.yaml and
create that fixture in the mission-control module fixtures (scopes) containing
the same Scope resource (kind: Scope, metadata.name: prod-west-configs,
namespace: default, spec.description: "Production configs in us-west region from
specific agent", spec.targets: - config: agent: agent-west-1, namespace:
production, tagSelector: "region=us-west"); update the doc code block to use
```yaml title="prod-west-configs.yaml" file=<point to that mission-control
fixture>``` so the example is imported rather than inlined.
mission-control/docs/guide/permissions/examples/multi-tenancy-patterns.md
Outdated
Show resolved
Hide resolved
Comment on lines
74
to
86
| ```yaml | ||
| apiVersion: mission-control.flanksource.com/v1 | ||
| kind: Scope | ||
| metadata: | ||
| name: team-a-prod-west | ||
| namespace: default | ||
| spec: | ||
| description: Team A production resources in west region | ||
| targets: | ||
| - config: | ||
| namespace: team-a | ||
| tagSelector: "env=production,region=west" | ||
| ``` |
There was a problem hiding this comment.
Replace inline YAML with file= directive import.
The YAML example is written directly in the documentation, which violates the coding guidelines. As per coding guidelines: "Never write YAML examples directly; import examples from submodules (mission-control, duty, config-db, canary-checker) using code blocks with file= directive."
📝 Required change
-```yaml
-apiVersion: mission-control.flanksource.com/v1
-kind: Scope
-metadata:
- name: team-a-prod-west
- namespace: default
-spec:
- description: Team A production resources in west region
- targets:
- - config:
- namespace: team-a
- tagSelector: "env=production,region=west"
-```
+```yaml title="team-a-prod-west.yaml" file=<rootDir>/modules/mission-control/fixtures/scopes/team-a-prod-west.yaml
+
+```Create the corresponding fixture file in the mission-control submodule.
🤖 Prompt for AI Agents
In `@mission-control/docs/guide/permissions/examples/multi-tenancy-patterns.md`
around lines 74 - 86, Replace the inline YAML in multi-tenancy-patterns.md (the
Scope example named team-a-prod-west) with a YAML code block using the file=
directive (title "team-a-prod-west.yaml" and file pointing to the fixture), and
create the corresponding fixture file team-a-prod-west.yaml under the
mission-control fixtures scopes directory containing the original Scope YAML
(apiVersion: mission-control.flanksource.com/v1, kind: Scope, metadata
name/team-a-prod-west namespace/default, spec description and targets with
config namespace/tagSelector) so the docs import the example instead of
embedding it inline.
Comment on lines
7
to
22
| ```yaml | ||
| apiVersion: mission-control.flanksource.com/v1 | ||
| kind: Scope | ||
| metadata: | ||
| name: monitoring-stack | ||
| namespace: default | ||
| spec: | ||
| description: Complete monitoring stack resources | ||
| targets: | ||
| - config: | ||
| tagSelector: "app=prometheus" | ||
| - component: | ||
| tagSelector: "app=prometheus" | ||
| - canary: | ||
| tagSelector: "app=prometheus" | ||
| ``` |
There was a problem hiding this comment.
Replace inline YAML with file= directive import.
The YAML example is written directly in the documentation, which violates the coding guidelines. As per coding guidelines: "Never write YAML examples directly; import examples from submodules (mission-control, duty, config-db, canary-checker) using code blocks with file= directive."
📝 Required change
-```yaml
-apiVersion: mission-control.flanksource.com/v1
-kind: Scope
-metadata:
- name: monitoring-stack
- namespace: default
-spec:
- description: Complete monitoring stack resources
- targets:
- - config:
- tagSelector: "app=prometheus"
- - component:
- tagSelector: "app=prometheus"
- - canary:
- tagSelector: "app=prometheus"
-```
+```yaml title="monitoring-stack.yaml" file=<rootDir>/modules/mission-control/fixtures/scopes/monitoring-stack.yaml
+
+```Create the corresponding fixture file in the mission-control submodule.
🤖 Prompt for AI Agents
In `@mission-control/docs/guide/permissions/examples/multiple-resource-types.md`
around lines 7 - 22, Replace the inline YAML example for the Scope resource
named "monitoring-stack" with a code block using the file= directive (e.g.,
```yaml title="monitoring-stack.yaml" file=...```), and create the referenced
fixture file containing the original YAML content (Scope, metadata.name
monitoring-stack, namespace default, spec.description and targets for
config/component/canary with tagSelector "app=prometheus") in the
mission-control module's fixtures for scopes so the documentation imports the
example instead of embedding it inline.
mission-control/docs/guide/permissions/examples/targeting-by-tags.md
Outdated
Show resolved
Hide resolved
mission-control/docs/guide/permissions/examples/targeting-with-wildcards.md
Outdated
Show resolved
Hide resolved
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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 by CodeRabbit