mainsequence-access-control-and-sharing

Define and verify RBAC resource boundaries and access levels across Main Sequence projects.

6|1|Updated Nov 14, 2024

Search Tags:#rbac #sharing #access-control #data-security #secret #resource-boundaries #constant

One-click install

npx skills add https://github.com/mainsequence-sdk/mainsequence-sdk --skill mainsequence-access-control-and-sharing

Or copy as Structured Prompt for Agent▼

Please help me install this Agent Skill.
Skill: mainsequence-access-control-and-sharing
Source: https://github.com/mainsequence-sdk/mainsequence-sdk/tree/main/docs/astro/platform_operations/access_control_and_sharing
Command: npx skills add https://github.com/mainsequence-sdk/mainsequence-sdk --skill mainsequence-access-control-and-sharing

SYSTEM DOCUMENTATION & REQUIREMENTS

Use this skill when the task is about RBAC, resource sharing, or access verification in a Main Sequence project. This skill owns organization and team access concepts, view and edit semantics, choosing the correct shareable resource boundary, and access checks across projects, DataNodeStorage, constants, secrets, buckets, artifacts, and releases. It does not own job scheduling, DataNode producer logic, or API route design.

What problem does it solve?

Determine who can view or edit a resource, ensure the correct sharing boundary, and verify access across a project to prevent misconfigurations.

Core Features & Use Cases

explain the Main Sequence access model in operational terms
decide whether a resource should be shared directly to a user or to a team
decide whether a user needs view or edit
identify the correct shareable object boundary: Project, DataNodeStorage, Constant, Secret, Bucket, Artifact, ResourceRelease
explain that sharing a DataNode usually means sharing its DataNodeStorage
choose whether configuration belongs in a Constant or Secret
review CLI sharing flows for existing resources
verify access assumptions before claiming a workflow is shareable

Read First

We expect you to start with foundational docs: docs/tutorial/role_based_access_control.md, docs/knowledge/infrastructure/users_and_access.md, and docs/knowledge/infrastructure/constants_and_secrets.md.

Inputs This Skill Needs

Before changing access or advising on sharing, collect or infer:

the exact resource type being shared
whether the actor is:
- a user
- a team
whether the access should be:
- view
- edit
whether the goal is:
- consumption
- maintenance
- administration
whether the resource contains sensitive configuration
whether the task is about the resource itself or about the workflow that uses it

If the resource boundary or intended access level is unclear, stop before changing permissions.

Required Decisions

For every non-trivial access task, decide:

What is the real shareable object?
Is this direct user access or team-based access?
Does the user need view or edit?
Is this configuration non-sensitive or sensitive?
Is the task really an access problem, or is it actually an orchestration or implementation problem?

Build Rules

1. Share the real resource boundary

Do not speak loosely about sharing "the code" when the operational boundary is a platform object.

2. `view` is for consumers, `edit` is for maintainers

Use the simplest rule unless the task requires something more specific:

view for people who need to read, inspect, or consume
edit for people who need to maintain, update, or administer

Do not grant edit when view is enough.

3. Team sharing is for repeated access patterns

Prefer team sharing when the same access needs to be reused across several people or resources.

Prefer direct sharing when:

the access is one-off
the access is personal
creating or reusing a team would add unnecessary complexity

4. Team membership is not team administration

Do not claim that a user can manage a team just because they inherit access through that team.

Keep these separate:

inherited access to shared resources
administration of the team itself

5. `Constant` vs `Secret` is a security boundary

Use Constant for non-sensitive runtime values. Use Secret for:

API keys
passwords
bearer tokens
credentials
anything that would create an incident if exposed

Do not downgrade a secret into a constant for convenience.

6. Access assumptions must be verified

If the task claims a resource is shareable, readable, or maintainable by another actor, verify that path explicitly with the relevant CLI or client workflow.

Do not claim access based only on naming, role titles, or intuition.

Review Rules

When reviewing an access-control task, look for:

sharing the wrong resource boundary
granting edit when view is sufficient
using direct user grants where a team should be used
using a team when the access is clearly one-off
treating team membership as team administration
storing sensitive data in a Constant
weak or unverified claims about who can access a resource
confusion between access policy and deployment workflow

Validation Checklist

Do not claim success until you have checked:

the resource boundary is correct
the grant target is intentional:
- user
- team
the access level is intentional:
- view
- edit
the task is using Constant vs Secret correctly
the access claim was verified against the actual resource path
the task did not confuse sharing policy with orchestration or producer logic

This Skill Must Stop And Escalate When

the real shareable resource is unclear
the actor should probably be a team, but team structure is unknown
the task mixes access policy with job scheduling or release mechanics
the task asks for sensitive data to be stored in a Constant
the task assumes cross-organization sharing without explicit documentation
the request requires a policy decision the user has not made

End of description.

Frequently Asked Questions about mainsequence-access-control-and-sharing

High-intent search queries and answers about installing and using this skill.

FAQPage Schema

How do I set up RBAC and resource sharing boundaries in Main Sequence?▼

To set up RBAC and resource sharing in Main Sequence, identify the exact shareable object boundary like Project, DataNodeStorage, or Bucket, then assign view or edit access to either a direct user or a team based on the consumption goal.

When should I use a Constant vs a Secret for configuration in Main Sequence?▼

Use a Constant for non-sensitive runtime values and a Secret for sensitive data like API keys, passwords, or bearer tokens. Never downgrade a Secret into a Constant for convenience, as this crosses a critical security boundary.

What is the difference between view and edit access levels for shared resources?▼

View access is for consumers who need to read, inspect, or consume a resource, while edit access is for maintainers who need to update or administer it. Grant the simplest permission level necessary and never provide edit when view is sufficient.

How do I verify if a DataNode or resource is actually shareable via the CLI?▼

Verify resource shareability by explicitly checking the access path with the relevant CLI workflow, ensuring the correct boundary like DataNodeStorage is shared rather than the producer logic, and confirming the actor has the intended view or edit permissions.

When should I share a resource directly to a user instead of a team?▼

Share a resource directly to a user for one-off or personal access needs. Prefer team sharing when the same access pattern needs to be reused across multiple people or resources to avoid unnecessary complexity.

Why does sharing a DataNode usually mean sharing its DataNodeStorage?▼

Sharing a DataNode in Main Sequence typically requires sharing its DataNodeStorage because DataNodeStorage is the actual operational resource boundary, whereas the DataNode itself involves producer logic and orchestration that fall outside access policy scope.