Identity & Access (IAM)

The platform has a full identity and access-management model: who a principal is (authentication), what they’re allowed to do (authorization), and which data they can see (row- and field-level access control). It runs as a backend service (iam.svc, installed via kvm install iam.svc) and is configured declaratively as kis spec YAML definitions, so you author, validate, and lint your IAM config the same way you do entities.

Authentication: how a principal proves who they are

Interactively, you authenticate the CLI with kis login (classic or magic-link), stored under a named context. The platform itself models authentication with these kinds:

Kind	What it represents
Provider / Providers	An authentication provider configuration
ProviderType	The provider types available
ProviderAuthType	Whether a provider is delegate or managed
Realm / Realms	A user group with its own auth methods, realms separate employees, customers, partners
RealmProvider	An auth provider bound to a realm
MFAMethod	Available multi-factor methods

Realms are the key idea: they partition kinds of users (employees vs. customers vs. partners), each with their own providers and methods, so one platform can authenticate very different audiences without mixing them.

Identity: users and principals

Kind	What it represents
User	A user / principal in the system
UserType	The types of principals in the IAM system
UserTypePrefix	Maps user types to their ID prefixes
ServiceAccount	A service principal (non-human / machine identity)

Authorization: what a principal may do

This is the policy layer, roles, permissions, and the rules that evaluate them.

Kind	What it represents
Authorization	Top-level container for authorization config
AuthzType	The authorization model type in use
Role	A role in RBAC (role-based access control)
Permission	A permission grant
Policy / PolicyLanguage	An authorization policy and its language
Action	Common authorization actions
Condition	A condition within a policy
OPAConfig	Open Policy Agent delegation configuration
CheckConfig	A condition check

Note

OPAConfig means authorization can be delegated to Open Policy Agent (Rego policies) rather than evaluated only by the built-in model, useful when you already standardize on OPA.

Data access control: row & field level

Beyond “can you call this action,” the platform controls which rows and fields a principal sees, enforced down at the data layer.

Kind	What it represents
Access	Entity-level access-control configuration
AccessActions	The actions a user can perform: create, read, update, delete, purge, unmask
AccessRule / AccessRuleLanguage	An access-control rule and its language
FieldAccessRule	Field-level access control
RowLevelSecurity	Row-level access control
QueryHash / QueryHashes	A named SQL query that itself carries access control
Compliance / ComplianceType	Per-field compliance settings (e.g. masking sensitive fields)

Tip

Note the unmask action in AccessActions and the Compliance kinds: sensitive fields can be masked by default and only revealed to principals explicitly granted unmask. That’s how PII/compliance is enforced field-by-field rather than all-or-nothing.

The CPET identity (customer:product:environment:tenant)

Several commands scope work to a four-part identity the platform calls CPET, customer, product, environment, tenant. It’s stated explicitly in kis script run’s --cpet flag (“CPET identity, comma-separated: customer,product,environment,tenant”).

The same four-segment shape appears as the default --schema on the entity commands (write-entity / read-entity): system:system:system:system. Read it as customer:product:environment:tenant, each defaulting to system. This is how a record write is scoped to the right customer/product/environment/tenant, and it ties back to a datastore’s tenancy mode.

# A script carrying an explicit CPET identity
kis script run rules.js --cpet acme,billing,prod,tenant-42

# An entity write scoped to a CPET (colon-separated --schema)
kis write-entity -d entities/faq.yaml -p dbpool.yaml -f rec.json \
  --schema acme:billing:prod:tenant-42

Authoring & inspecting IAM config

IAM definitions are kis spec kinds, the same author → validate → lint loop as any platform definition:

kis spec list | grep -iE 'access|auth|role|policy|user|realm|provider'   # the IAM kinds
kis spec new policy my-policy           # scaffold a definition
kis spec validate authz/                # validate your IAM YAML
kis spec generate jsonschema --kind Policy --output ./schemas   # full JSON Schema