How Kwirth protects access: authentication, authorization, API keys, and Single Sign-On with external identity providers.
Kwirth security works at three levels: administrator, user, and API. Every request is authorized against an access key that encodes exactly which cluster resources (namespaces, workloads, pods, containers) and which actions the holder is allowed to reach.
The built-in admin account manages users, API keys and identity providers. Only administrators (admin scope) can perform security-related actions.
Users are created with a fine-grained set of resources and scopes. Scopes are declared dynamically by each plugin and served by the core, so installing a channel can add new permissions. Users sign in with a password, a login extension, or an external identity provider.
Access keys let external apps and other Kwirth instances reach resources across clusters. Three types: permanent (persisted), volatile (in-memory) and bearer (signed at login).
Kwirth supports built-in user/password login, pluggable login extensions (alternative sign-in methods — e.g. anonymous access — each declaring its own config schema), and optionally Single Sign-On through external identity providers. These can be enabled together — the built-in login is always available for the bootstrap admin account.
Kwirth can delegate authentication to an external Identity Provider. The IdP only verifies who the person is; Kwirth still decides whether they can enter and what they can access. A user must already exist in Kwirth and be bound to the IdP they use — there is no auto-provisioning.
Connectors implement OIDC or OAuth2, and the sign-in flow is hardened with PKCE + state, a back-channel token exchange (the browser never sees provider tokens), a single-use login hand-off and anti open-redirect checks.
Supported connectors:
Connectors are installable extensions, so more providers (and third-party ones) can be added over time. Read the IdP integration guide →
Authorization is based on access keys that describe scopes and target resources. API keys let you share access between Kwirth instances and external tools; they come in permanent (persisted in the cluster), volatile (in-memory only) and bearer (signed and handed to clients at login) types, and can carry a lease/expiry.
Inbound webhook endpoints — where external systems call into Kwirth to push events — are protected by the same access-key model, so only authorized callers get through.
Read the API management guide →