Glossary
This glossary defines the key terms used throughout the Kessel documentation. Terms are organized by domain. Each definition links to the relevant concept or reference page where you can learn more.
Resources and Data
Section titled “Resources and Data”Resource
Section titled “Resource”Any addressable entity that can be modeled, queried, and governed in Kessel. In Kessel, everything is a resource: users, groups, workspaces, roles, hosts, clusters, and documents are all modeled uniformly with types, identifiers, and relationships. Application-specific resources are reported to Kessel through the Inventory API.
See Resources and representations.
Resource Type
Section titled “Resource Type”A classification of resources in Kessel, analogous to a table in a relational database. Resource types are part of Kessel’s meta-model approach: they are defined declaratively via schema, not hard-coded. Adding a new resource type is a configuration change, not a code change. Each resource type defines valid representations, reporters, and relationships.
See Resources and representations and Schema and extensibility.
Representation
Section titled “Representation”The state of a resource as seen by a particular service. Kessel supports two kinds: common representations (attributes shared across all reporters, such as workspace_id) and reporter-specific representations (attributes unique to a single reporter’s perspective). Each representation has its own attribute schema defined in JSON schema.
See Resources and representations.
Reporter
Section titled “Reporter”A service that reports resource representations to Kessel. When a reporter sends data to Kessel via ReportResource, it creates or updates the representation of a resource from that reporter’s perspective.
See Resources and representations.
Correlation
Section titled “Correlation”(Planned, not yet implemented.) The mechanism that will link multiple representations from different reporters into a single resource identity using shared attributes as keys. Currently, each reporter’s representation creates a separate resource in Kessel.
See Resources and representations.
Meta-Model
Section titled “Meta-Model”Kessel’s approach to extensibility. Instead of hard-coding specific resource types into its implementation, Kessel knows about the structure that all resource types share (type name, representations, reporters, relationships) and operates generically over any configured type. This means new resource types can be added through schema configuration without modifying Kessel’s code.
Access Control
Section titled “Access Control”Permission
Section titled “Permission”An action that can be performed on a specific type of resource, using the format application:resource_type:operation (for example, inventory:hosts:read). Wildcards are supported. Permissions are either data-level (scoped to workspaces) or org-level (applied organization-wide).
See Role-based access control.
A named collection of permissions that can be granted to subjects via role bindings. Kessel has three role types: Custom (created by admins, modifiable), Seeded (system-provided, not modifiable), and Platform (internal aggregate roles).
See Role-based access control.
Role Binding
Section titled “Role Binding”The link that grants a role’s permissions to a subject on a specific workspace or tenant. The core RBAC formula is: Subject (who) + Role (what permissions) + Resource (where) = Role Binding.
See Role-based access control.
Subject
Section titled “Subject”The entity that has a relation or is performing an action. In the context of role bindings, a subject is the “who” that receives a role’s permissions. Role bindings currently target groups; binding to individual principals is planned for a future release.
See Role-based access control and Relationships and permissions.
Subject Set
Section titled “Subject Set”The set of all resources that share a particular relation on another resource (for example, “all members of the Engineering group”). A single relationship to a subject set covers all members, and effective permissions update automatically as membership changes.
See Relationships and permissions.
Principal
Section titled “Principal”An individual identity in Kessel, either a user (human authenticated via SSO/OIDC) or a service-account (machine identity for service-to-service calls).
See Identity and multi-tenancy.
A collection of principals. Role bindings typically target groups rather than individual users. Kessel provides two special groups: the Platform Default Group (all users) and the Admin Default Group (organization admins).
See Role-based access control.
Workspaces and Tenancy
Section titled “Workspaces and Tenancy”Workspace
Section titled “Workspace”A container for resources that serves as a scope for permissions. When you grant a role to a user on a workspace, that user gets those permissions on all resources within that workspace and its children. Workspaces form a hierarchy (tree) rooted at the Root Workspace.
See Identity and multi-tenancy.
Root Workspace
Section titled “Root Workspace”The top-level workspace in a tenant’s hierarchy. Every organization gets exactly one Root Workspace when the tenant is created. Permissions granted at the Root Workspace cascade to all workspaces below it. It must have no parent.
See Identity and multi-tenancy.
Default Workspace
Section titled “Default Workspace”The primary workspace where most resources live. Every organization gets exactly one Default Workspace when the tenant is created. Its parent is always the Root Workspace. Use it for organization-wide resources.
See Identity and multi-tenancy.
Tenant
Section titled “Tenant”An organization in Kessel, identified by a unique org ID. Each tenant has its own isolated workspace tree, roles, groups, and principals. Database constraints prevent cross-tenant access.
See Identity and multi-tenancy.
Schema and Authorization
Section titled “Schema and Authorization”Schema
Section titled “Schema”The declarative configuration that defines a resource type’s valid representations, reporters, and relationships. Resource attributes are validated using JSON Schema. Relationships and permissions are defined in KSL. Schema drives validation at write time: if reported data does not match the schema, the request is rejected.
See Schema and extensibility and Getting started.
Kessel Schema Language. The language for describing resources and their relationships, including what permissions apply to each resource type. KSL files are compiled to SpiceDB schema using the ksl compiler.
See Getting started.
Relation
Section titled “Relation”A named string that defines a type of connection between two resources, such as member, viewer, parent, or workspace. Relations are directional: “group:engineering has member user:alice” is different from the reverse. Relations are defined in KSL schema and realized as relationships stored in SpiceDB.
See Relationships and permissions.
Relationship
Section titled “Relationship”A specific instance of a relation between two resources, stored as a tuple in the authorization graph. Relationships can be stored (explicitly created by reporting resources, creating role bindings, etc.) or computed (derived from rules that combine stored relationships, such as permission inheritance through the workspace hierarchy).
See Relationships and permissions.
A unit of relationship data stored in SpiceDB. Each tuple represents a single relation between two entities (for example, “user Alice is a member of the Engineering group” or “host-123 belongs to the Engineering workspace”). Permission checks are evaluated by traversing tuples in the authorization graph.
Authorization Graph
Section titled “Authorization Graph”The graph of tuples stored in SpiceDB that represents all relationships between resources, users, groups, roles, and workspaces. Check operations traverse this graph to evaluate permissions.
API Operations
Section titled “API Operations”A permission check that asks: “Does this subject have this permission on this resource?” Kessel provides several variants (including bulk and strongly consistent options) that support different consistency modes.
See Consistency model and Relationships and permissions.
StreamedListObjects
Section titled “StreamedListObjects”An API operation that returns the set of resources a given subject can access with a specified permission. Useful for building filtered list views (“show me all the hosts I can read”). Results are streamed as they are found.
See Relationships and permissions.
StreamedListSubjects
Section titled “StreamedListSubjects”An API operation that returns the set of subjects who have a specified relation on a given resource. Useful for answering “who has access to this resource?” Results are streamed as they are found.
See Relationships and permissions.
ReportResource
Section titled “ReportResource”The API operation used by reporters to create, update, or delete resource representations in Kessel. When called, the Inventory API writes to its database and replicates permission-relevant relationships to SpiceDB, either asynchronously (default) or synchronously if immediate consistency is requested.
See Report resources.
Consistency
Section titled “Consistency”Consistency Mode
Section titled “Consistency Mode”The level of freshness guaranteed when performing a Check. Kessel provides several modes that let services choose whether to prioritize speed or data freshness when evaluating permissions.
See Consistency model.
Consistency Token
Section titled “Consistency Token”An opaque value representing a specific point in the authorization graph’s transaction log. Used with certain consistency modes to guarantee that a Check reflects at least a known replication state.
See Consistency model.
Write Visibility (IMMEDIATE Mode)
Section titled “Write Visibility (IMMEDIATE Mode)”A mode for ReportResource that waits for replication to the authorization graph to complete before returning success, trading higher latency for guaranteed write visibility.
See Consistency model.
Data Replication
Section titled “Data Replication”Change Data Capture (CDC)
Section titled “Change Data Capture (CDC)”A technique that captures row-level changes to database tables and publishes them to a message broker. Kessel uses CDC internally to replicate resource data from the inventory database to the authorization graph. Service providers can also use CDC with the outbox pattern to report resources without direct API calls.
See Report resources and Monitoring data replication.
Outbox Pattern
Section titled “Outbox Pattern”A strategy that solves the dual-write problem by writing both business data and a messaging event in the same database transaction. A CDC connector (typically Debezium) then captures the outbox rows and publishes them to a message broker.
See Report resources.
Debezium
Section titled “Debezium”An open-source CDC platform that captures row-level changes from databases and streams them to Apache Kafka. Kessel uses Debezium to capture changes from the inventory database’s outbox table and publish them to Kafka topics for downstream processing.
See Monitoring data replication.
Architecture
Section titled “Architecture”Kessel Inventory API
Section titled “Kessel Inventory API”The central API for reporting resources, checking permissions, and listing accessible resources. This is the primary integration point for services building with Kessel. It uses gRPC as the primary protocol.
RBAC Service
Section titled “RBAC Service”The service that manages roles, role bindings, workspaces, and group-to-principal mappings. The RBAC service writes relationship changes to the authorization graph via its own replication pipeline.
SpiceDB
Section titled “SpiceDB”The graph database that serves as Kessel’s authorization backend. SpiceDB stores tuples and evaluates permission checks by traversing the authorization graph. It is an open-source implementation inspired by Google’s Zanzibar paper.
See Architecture for more.