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
An Organization is a top-level concept. Every operation within ContentGrid, happens in the context of an Organization.
ContentGrid Organizations are used to:
Create and manage Projects, Applications and IAM Realms
Invite Members to collaborate on those Projects or Applications.
A Project belongs to an Organization and contains:
the conceptual model of an application, presented as a Blueprint and Releases.
possibly one or more deployed Applications.
Your Users will use the deployed Applications.
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.
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] |
A Release is an immutable snapshot of a Blueprint and is the artifact that can be deployed to an Application.
The data model is a logical abstraction of concepts from the real world. The data model contains Entities with Attributes and Relations between 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.
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
.
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 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 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 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 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.
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 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.
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
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 (Identity and Access Management) is the system that manages User-accounts for ContentGrid Applications.
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.
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. |
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.
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
.
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.