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.

name	type	semantics
subject	JSON formatted object	Who is being granted access. A set of attributes that matches a subset of users
resource	JSON formatted object	A set of attributes that match entities and/or instances
action	JSON formatted object	The 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.

• Attributes can be the fields common to every Nile entity, for example ID, create date or update date.
• Resource attributes can be every field in the custom entity schema.
• User attributes can be every field in the user entity schema. Those include any key that is included in the user metadata, and any key in the user's organization membership metadata (which can be different for every organization).

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