/ /

Permissions & security - Kontainer

Updated 25 days ago

For data security, encryption, and credential storage information that applies across all connectors, see Data & Security - Enterprise Search Connectors.

Our approach to permissions

  • The connector requests the minimum set of permissions the Kontainer APIs allow for its functionality, and only read-oriented access wherever the source APIs permit it.

  • The connector never writes to or modifies data in Kontainer.

  • Credentials are stored encrypted and are never exposed in logs, search results, or the Simpplr UI after initial entry.

Credential scope

Auth type: API token (Bearer token)

The integration user you create in Kontainer must be granted the following access:

Permission / Access

Why it's needed

Download access on DAM folders to the user generating the token

Allows the connector to read DAM file content, metadata, and folder structure for indexing. Grant Download permission on all DAM folders you want to index.

Who can generate an API token must be a Kontainer administrator or a user with access to Settings → Configuration → API. If you are not an administrator, coordinate with one before proceeding to setup.

Versions and editions supported

  • Supported: Cloud (SaaS) — dedicated tenant hosts (e.g., customer.kontainer.com)

  • Not supported: On-premises / self-hosted deployments

Permission design

How permissions work

Permissions from Kontainer are read and enforced in Simpplr Enterprise Search. For DAM content, users only see files they already have access to in Kontainer.

  • DAM — folder-based permissions: The connector reads user and group permissions per DAM folder. At query time, only users with the appropriate folder-level access see those DAM files in search results. Access is determined by the union-of-grants rule: a user is granted access if any user or group permission row grants them access on that folder.

  • User and group sync: Kontainer user identities and group memberships are synced to Simpplr by the permission sync. When a user is added to or removed from a group in Kontainer, the change is reflected in Simpplr after the next permission sync.

  • Item permission changes (DAM): When a DAM file's folder permissions change and the file itself is also modified, the updated permissions are picked up by the next incremental sync. If only permissions changed (no file modification), the change is not detected until the next full sync.

  • Public or shared links: Content shared via anonymous or public links is not indexed. Only content accessible through standard user and group permissions is included.

  • Access removal: When a user loses access to a DAM file in Kontainer, the file stops appearing in their Simpplr search results after the next relevant sync completes (see latency below).

  • Integration token ceiling: The connector only indexes DAM files the API token user can read. Document-level security further restricts results to users granted access via the folder permission model, within that visible set.

Permission propagation latency

Change in Kontainer

Reflected in Simpplr

User added to / removed from a group

After the next permission sync (within 1 hour)

DAM file permission change (where file is also modified)

After the next incremental sync (within 1 hour)

DAM permission-only change (no file modification)

After the next full sync (within 1 day). This is because Kontainer does not expose an API timestamp for folder permission changes alone. To apply sooner, trigger a manual full sync from the connector Status page.

Alternative permission models

Kontainer does not offer a narrower API-level permission model. The API token inherits the folder-level permissions of the user it was generated for. To limit what the connector indexes and who sees which results, restrict the integration user's DAM folder access in Kontainer before generating the token.

Was this article helpful?
Subscribe to receive updates on this article