How access control works

Codinamo uses scoped role-based access control. A decision combines who is acting, what role was granted, where it was granted, and which operation is requested.

Core model

Principal: A user or team that receives access.
Role: A reusable bundle of explicit permissions and allowed scope types.
Grant: An assignment connecting one principal, one role, one resource scope, and an optional expiration time.
Resource: A canonical object such as a workspace, project, pipeline, repository, or deployment target.
Scope: The resource where a grant originates.

An effective permission exists when an active grant supplies a role containing the requested permission, directly or by implication, and the grant scope contains the target resource.

Resource containment

Codinamo evaluates access against this containment graph:

Organization
|-- Team
`-- Workspace
    |-- Project
    |   |-- Pipeline
    |   |   `-- Run
    |   |-- Repository
    |   `-- Registry
    |-- Variable group
    |-- Secret group
    |-- DinaSync agent
    `-- Deployment target

A grant on a resource can contribute permissions to descendants. A grant on a child never grants access to its siblings.

Creation and enablement operations are evaluated on the parent that will own the new resource. Examples include project:create on a workspace, pipeline:create on a project, and repository:enable on a project.

Structural visibility

Codinamo does not present a child without enough context to identify it. Access to a pipeline supplies the minimum structural visibility required for its project and workspace ancestry.

This base visibility is not permission to inspect unrelated content. For example, seeing a project name as the parent of an authorized pipeline does not imply permission to edit the project or browse every repository in it.

Permission implications

Stronger operations imply the visibility required to perform them. Examples:

pipeline:execute implies pipeline:view;
run:logs-view implies run:view;
repository:write implies repository:read, which implies repository:view;
registry:push implies registry:pull;
grant:manage implies grant:view.

The grant review page separates explicit permissions declared by the role from permissions derived by these rules.

Direct and team-derived access

A user acts through two principal sources:

grants assigned directly to the user;
grants assigned to any team containing the user.

Removing one source does not suppress another. Effective access is the union of all active, non-expired grants that reach the requested resource.

Direct and inherited assignments

Direct assignment: The grant scope is the resource being inspected.
Inherited assignment: The grant scope is an ancestor of the resource being inspected.

Inherited access must be changed at its origin. This keeps one workspace-level grant from being silently modified while inspecting a descendant pipeline.

Administrative boundaries

Access administration is itself permission-controlled. A principal with grant:manage on a workspace can assign compatible roles throughout that workspace subtree. Organization-level role management remains separate through role:* permissions.

See Manage access for UI workflows and Access catalog for the current resource and role vocabulary.