Concepts

Console

The ContentGrid Console is a management interface for the ContentGrid platform. It provides a web-based user interface to manage your ContentGrid Projects, Applications and more.

The Console is available at https://console.contentgrid.com

Organizations

An Organization is a top-level concept. Every operation within ContentGrid, happens in the context of an Organization.

ContentGrid Organizations are used to:

Projects

A Project belongs to an Organization and contains:

Your Users will use the deployed Applications.

Members

Members are project administrators for an Organization. They can create new Projects, collaborate on Blueprints, manage Applications and IAM Realms

Note that members are not Users. A User does not need to be a member of your Organization to access an Application.

At this time, members cannot be assigned different roles or permissions. Every member is effectively an organization and project administrator.

Blueprint

A blueprint is the design area of a Project. It describes the full model of an application, including the Data Model, Permissions and any Automations. This model determines how the data is stored in the database, how the REST API is structured and how automations are integrated.

A Release can be created from a Blueprint.

Creating a new version of an active application means making changes in the Blueprint and creating a new Release before deploying this release to a running Application.

A Project has a Blueprint called main.

A Blueprint does not contain any application- or user-data.

Tip
If you are wondering where application- & user-data is stored, see: [storing-data]

Release

A Release is an immutable snapshot of a Blueprint and is the artifact that can be deployed to an Application.

A Release is created from the current Blueprint. It has a release-label, like v1.2.3 and optionally a short description. A Release follows a chronological previous Release and belongs to a single Project.

Data Model

The data model is a logical abstraction of concepts from the real world. The data model contains Entities with Attributes and Relations between Entities.

Entities

An Entity represents an object or concept in the digital world. It can represent a physical object, like a product or an invoice-document, or a virtual concept, like an online order.

Attributes

An attribute is a single characteristic of an Entity. An attribute has a data type, such as text, number or date. A file is stored as a special attribute type called content. For example, the attributes for an invoice could be number, amount and document.

Relations

A relation is a named link between two Entities in the Data Model.

Entities can have a one-to-one, one-to-many, many-to-many or many-to-one relationship with another entity. For example, an invoice has a many-to-one relationship with the customer entity: many invoices can have a reference to the same customer.

A relation can be optional or required.

Permissions

Permissions govern under what conditions Entities are visible for a principal (a User or Service Account). They are made up of a collection of Policies per Entity.

ContentGrid uses an Attribute Based Access Control (ABAC) system. This means that a set of rules define access, using attributes of the principal issuing a request and attributes of the Entities being acted upon.

Permissions are deny-by-default.

Policies

Policies are a set of rules, that specify a the conditions under which Operations are allowed on an Entity. A policy always applies to a single Entity.

Under normal circustomances, every Entity gets a Policy. In the absence of any Policies for an Entity, all Operations on this Entity are disallowed for everyone.

One Entity can have multiple Policies, that are inclusively disjunctive. In other words, the policies are combined with "OR" logic: a request is allowed if the conditions of Policy A OR Policy B are satisfied.

Operations

Operations are actions that a principal (a User or Service Account) can perform on an Entity.

The available actions are Read, Create, Update, Delete. A policy can cover one or more operations.

Policy Conditions

Policy Conditions specify additional requirements that must be met, before an operation is allowed. They are like extra security checks that ensure that only the right people can access your Entities or perform actions on them. For a policy to allow something, all conditions in that policy must pass.

A policy without conditions allows the selected operations for all logged-in users.

Automations

Webhooks

Webhooks provide a way to configure a ContentGrid Application to send notifications to external systems whenever certain changes occur.

When a mutating operation is performed (for example, a user created a document), an HTTP request is sent to the configured endpoint, with a payload describing the change. Every operation is handled individually and asynchronously. Delivery of webhook events are usually in chronological order, but in-order delivery is not guaranteed.

A webhook receiver needs Service Account credentials, if it wants to call the REST API of the Application.

Applications

Applications are running instances of a Project. An Application is created in a Zone. After creating the Application, a Releases can be Deployed to an Application.

A Project can have multiple active Applications, possibly representing different environments or to try out different Releases.

Each Application is linked to one IAM Realm. The first time an Application is created in a Zone, a default IAM Realm is created for the Organization in this Zone.

Zones

A Zone is the deployment target of an Application and maps to the geographical location of a cloud provider that runs ContentGrid Applications.

An Organization creates an Application in a given Zone.

Currently there is one zone available: Scaleway Paris

Deployments

A Deployment is the rollout of a specific Release to an Application.

Once a Release is deployed, the Application provides a REST API to store, retrieve and manipulate data.

IAM

IAM (Identity and Access Management) is the system that manages User-accounts for ContentGrid Applications.

Realms

A Realm or IAM Realm contains a collection of Users, Groups and their attributes. Applications are linked to an IAM Realm to authenticate Users and Service Accounts.

Multiple Applications, across Projects but within the same Organization, can be connected to the same IAM Realm.

When an Application is created in a Zone for the first time, an IAM Realm gets automatically provisioned.

Users

IAM Users are human principals that interact with Applications.

Users are identified by their email address. Users can be a assigned to one or more Groups. Groups can have attributes and are recommended way to organization Permissions.

Note
an Organization Member is not automatically a User of an Application.

Groups

IAM Groups allow you to organize Users based on shared characteristics.

Groups have a collection of user memberships and a set of Attributes. For the purpose of permission evaluation, users inherit attributes from the groups they are a member of. For example, you might create a group for all users in the accounting department, so you set the group’s department-name attribute to “accounting”, so that you can create a permission policy for invoices that checks what department a user belongs to.

These attributes are defined in the IAM Attribute Model.

Attribute Model

The IAM Attributes describe a set of properties for Groups. The purpose of this model is to describe the information that can be used in permissions. Users inherit properties from the groups they are member of.

It is similar to defining Attributes for an Entity in the Datamodel, but is not part of a Blueprint.

An attribute has a name, a data type and can be single- or multi-valued. For instance, if you want to be able to write permission policies that allow access to admins, you should define an is-admin attribute of type boolean.

Service Accounts

A Service Account is a non-human principal in an IAM Realm. A Service Account can acquire an access token, to interact with the REST API of an Application.

Service Accounts are useful for programmatic integrations with the REST API. For example, a Webhook receiver may call back into the REST API to update a status field, but it needs to be authenticated to do so.

At this moment, it is not possible to create Service Accounts in the ContentGrid Console.