Jump to:
Intro
Scopes are an essential building block to achieving least privilege using Axiom.
Scopes control what the users can request access for, and who can approve these requests.
Scopes are accessed from the left-side navigation, under the Axiom IAM group:
Overview
Every scope consists of:
A unique name.
One or more scoping rules.
A list of users assigned to this scope with the role of requesters (can be empty).
A list of users assigned to this scope with the role of approvers (can be empty).
Each scoping rule is made up of:
A System (e.g. AWS, PostgreSQL, Kubernetes, etc.)
A Target (e.g. AWS account, PostgreSQL database, Kubernetes Cluster, etc.)
One or more permissions (e.g. AWS permission sets, PostgreSQL roles, etc.)
Scopes and requesters
When making requests, users only see Systems, Targets, and Permissions that they have scope for (as assigned to as a requester).
Scopes and approvers
Approvers see - and receive notifications for - for requests which match any of the scoping rules to which they are assigned as approvers (have scope for). If they do not have scope for any one of these they will not see the request at all.
Default scope
Every new user that is enrolled* to Axiom, is assigned to the scope set as Default. When you first start using Axiom, the built-in Global Requesters role is set as the Default. Only one scope can be set as Default.
* enrollment happens when the user first signs into Axiom.
Built-in scopes
Axiom comes preconfigured with two special built-in Scopes:
Global Requesters
This scope initially has “Any” set as the System, and is set as the Default scope. This means that when first starting to use Axiom, every new user can request access to anything (any System/ Target/ Permission). This scope is editable.Global Admin
This non-editable scope provides access to all parts of the Axiom User Console, and allows making and approving any request. The first user added to Axiom during initial onboarding is set as a Global Admin. A Global Admin can promote other users to also be Global Admins.
Scoping by groups
You can assign Scoping In order to scope by IdP groups Currently, users cannot be added to scopes before they sign into Axiom for the first time, and Axiom does not support defining scopes based on groups.
In mid Q3-2024, we will release the IdP Sync feature, allowing you to automatically enroll users into Axiom, and to scope by groups.
[IMAGE OF IdP sync?]
Scopes and templates
Users only see templates for which they have access to all Systems, Targets, and Permissions included in the template.
Examples:
A template includes access to an AWS account (System and Target), and a MySQL database. The user has scope for the AWS account but not for the MySQL database. The user will not see the template at all.
For the same template as above, the Permission for the database is specifically “Read and write”. The user has scope for the AWS account and does have scope for the MySQL database. However, the user only has scope for “Read” Permission on that database. The user will not see the template at all.
Scopes, approvers, and bundles
In the Requests list page (where requests are grouped by bundles), Approvers only see requests for which they have approver scope. This means that when viewing a bundle, approvers may not see (or be able to approve) all the requests in the bundle.
[IMAGE]
Fine grained control using scoping
Scopes allow you to control what users can request or approve at any level of the hierarchies listed below.
For example: for AWS you can control if a user has scope for the organization, specific accounts, or even specific EC2s, or all EC2s in a specific account.
You can also control if the scope includes all sub-resources identified by Axiom, or just the level selected in the scope.
For example: for MongoDB Atlas you can control if the scope is for all clusters in a project, just specific clusters, or just the project itself.
[img of include subresources toggle]
The hierarchies:
AWS: organization ⇨ account ⇨ EC2*
GCP: account ⇨ folder ⇨ project
Azure: account ⇨ mgmt group ⇨ subscription ⇨ resource group
MySQL: endpoint ⇨ database
MongoDB Atlas: project ⇨ cluster
PostgresSQL**: server ⇨ database ⇨ schema ⇨ table/view
Kubernetes: Cluster ⇨ Namespace
All other Systems have a single-level hierarchy.
* For AWS, we identify EC2s as their own special resources and support provisioning SSH access to them. Access to all other AWS resources is managed through AWS permission sets 
.
** For PostgreSQL, while you can select specific schemas/table/view, when you select a higher level, it always includes all subresources (DBs in server, schemas in DBs, tables and view in schema).
Scoping best practices
Over time, we recommend that you limit what the Default scope can permit, until you achieve true least privilege where Default scope does not provide any scope, and all scoping is from explicit assignments through groups.
Keep the number of Global Admins to a minimum, ideally only one (a Global Admin can request anything and can approve his/her own requests).
Step by step guide to building your first scope
Go to Scopes page.
Press on “New scope” button, from the top left.
Give your scope a meaningful name.
Define your first scoping rule by selecting a System (e.g. AWS), a Target (e.g. an AWS account), and whether or not to include all sub-resources (e.g. EC2s in an AWS account).
Press the “+ Add rule” button
Define another scoping rule (e.g. a PostgreSQL database with “Read and write” permission).
Open the Requesters list to select requesters to assign to this scope.
Repeat the same for approvers (or you can manage approvers in their own scope).
Press the “Create scope” button