Skip to main content

Access Policies - Built-in Entity

Nile includes built-in policy-based access control system. It allows both developers and organization administrators to configure which users are allowed to read/write specific entity instances. This section will explain the functionality that exists out of the box.

In Nile, users can belong to multiple organizations in the same workspace. Access policies are defined and scoped to each organization separately. By default, when an organization is created, every user have access to all the entity instances in the organization. When the first access policy is created for the organization, the organization becomes "deny by default" and users no longer have access unless it is explicitly granted to them.

Access policies can be created by developers manually (in Nile's Admin Dashboard), programmatically (for example, in the part of the backend that creates organizations) or by the users themselves as part of a self-serve experience.

When a user creates an organization, they can create access policies for this organization. They can also grant this ability to other users in the organization.

Admin Dashboard

Developers can create and edit access policies through the admin dashboard as well as through REST API and JS SDK.

Schema

Each access policy in Nile has 3 fields.

nametypesemantics
subjectJSON formatted objectWho is being granted access. A set of attributes that matches a subset of users
resourceJSON formatted objectA set of attributes that match entities and/or instances
actionJSON formatted objectThe type of access that is granted

Those fields are in addition to the default fields that exist for all Nile entities.

Attributes

Nile's access policies are similar to attribute-based access policies. This means that when developers define policies, they typically refer to attributes of users and entities in the policies.

The examples below will refer to resources that have "location" property, and to users that have "location" attribute in their metadata and "role" attribute in their organization membership metadata. As a developer, you are responsible to make sure your policies refer to resource, user and membership attributes that exist in your workspace.

Example policies

Nile access policies are very flexible, and examples help understand how they can be used to implement different access requirements.

In addition to the example policies below, you can find more examples in the REST API documentation and in the examples github repository. The API Reference documents how to create and update the policies using REST APIs or JS SDK.

Individual user access

User with specific email can read and write all clusters in an organization:

{
"subject": {
"email": "nora@demo.io"
},
"resource": {
"type": "clusters",
},
"actions": ["read", "write"]
}

Similar, but using user ID instead of email:

{
"subject": {
"id": "usr_02r7HPC9oZp0FkTow132eR"
},
"resource": {
"type": "clusters",
},
"actions": ["read", "write"]
}

Role-based access

Grant every user with "cluster_admin" role in the organization the ability to read/write clusters. The role can be assigned when the user is added to the organization and modified later.

{
"subject": {
"org_membership": {
"metadata": {
"role": "cluster_admin"
}
}
},
"resource": {
"type": "clusters",
},
"actions": ["read", "write"]
}

Access based on resource attribute

Grant all users access to view pre-production clusters.

{
"subject": {},
"resource": {
"type": "clusters",
"properties": {
"environment": "pre-production"
}
},
"actions": ["read"]
}

Access to access policies

Specific user can modify access policies:

{
"subject": {
"email": "it@demo.io"
},
"resource": {
"type": "policy",
},
"actions": ["read", "write"]
}

Users with "org_admin" role can modify access policies:

{
"subject": {
"org_membership": {
"metadata": {
"role": "org_admin"
}
}
},
"resource": {
"type": "policy",
},
"actions": ["read", "write"]
}

Location-based access

For regulatory purposes, it is sometimes important that users will only access resources that belong to the same geographical area as the user.

Note that in this example, the location is part of the user metadata and not the organization membership metadata. Which means that the user will have the same location in every organization that they belong to.

{
"subject": {
"metadata" {
"location": ${resource.metadata.location}
}
},
"resource": {},
"actions": ["read", "write"]
}

or

{
"subject": {},
"resource": {
"properties":
},
"actions": ["read", "write"]
}

Events

TBD

Metrics

TBD