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. They log in with a password or through an external identity provider.
Access keys let external apps and other Kwirth instances reach resources across clusters, with expiration built in.
Kwirth supports built-in user/password login and, optionally, Single Sign-On through external identity providers. Both can be enabled at the same time — 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.
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, always with an expiration.
Read the API management guide →