Skip to main content

Understanding Access in DynamoAI

This document provides an extensive guide on how access management is defined and implemented in our product using role-based access control (RBAC). It outlines various access levels, patterns, permissions, roles, and examples for better understanding.

Access Levels​

Organizational Level Access​

Organizational (Org) level actions are those which are not tied to any specific resource. Examples include:

  • model:create
  • policy:create

Resource Level Access​

Resource level actions are associated with specific resources. Examples include:

  • model:edit on the model A
  • policy:delete on the policy B

These access levels are similar to sharing an individual google doc with users. In the same way, you can share a model or policy with a specific user at different resource level roles.

Access Patterns​

On the Platform​

Even if a user has a permission like createModel, this does not mean that they have access to all models in the platform by default. Resources are still shared seperately.

Resource-Specific Permission​

On a resource, there can be two levels of access sharing similar to Google Docs:

  1. Public: Visible to all members of the organization.
  2. Private: Access is controlled at an individual user level.

While sharing a resource, you must specify:

  • The user with whom you want to share the resource
  • The resource level role at which you want to share it with them

Differences Between Org Level and Resource Level Roles​

Organizational Level Roles​

These roles encompass permissions that apply across the entire platform and are not specific to any individual resource.

  • Example: DynamoGuard Admin has access to create, read, edit, and delete models and policies at an organizational level.

Resource Level Roles​

These roles and permissions are tied to specific resources.

  • Example: DynamoGuard Owner has permissions like model:get, model:edit on specific models within the context of DynamoGuard.

Access Control Examples​

Example 1: Creating a Model​

An Org Level role such as DynamoGuard Developer would have the model:create permission, allowing them to create a new model in the organization.

Example 2: Viewing Policy Details​

A Resource Level role such as DynamoGuard Viewer would have policy:get permission to view details of a policy.

Example 3: Editing a Dataset​

A Resource Level role like DynamoEval Editor would have permissions such as dataset:edit to modify a specific dataset.

Example 4: Granting User Roles​

An Org Level role like IAM Admin will have permissions like user:setRole to assign roles to other users within the organization.

Last updated on