Permissions, Roles & Attributes¶
New in version v0.9.0.
This page summarizes the different ways that Krill supports for restricting access to named users that login to Krill. For backward compatibility, users that authenticate with the secret token are given unrestricted access to Krill.
Permissions¶
Internally within Krill each REST API endpoint requires the logged in user to have a specific Krill permission in order to execute the request.
User Attributes¶
User attributes are assigned by the identity provider, either in the
krill.conf
file for locally defined users, or in the management interface of
the OpenID Connect provider that manages your users.
Warning
By default, user attributes and their values are shown in the Krill
web user interface and the web user interface stores these
attributes in browser local storage. To prevent sensitive attributes
being revealed in the browser you can mark them as private. One
possible use for this is to restrict access using the exc_cas
attribute but not reveal the name of the restricted CA by doing
so. See auth_private_attributes
in krill.conf
file for more
information.
Role Based Access Control¶
At the highest level Krill can restrict access based on user roles. A role is a named collection of internal Krill permissions.
By default Krill supports three roles which can be assigned to users. A user can
only have one role at a time. A role is assigned to a user via the role
user attribute (see below for more on attributes).
The default roles are:
admin
: Grants users unrestricted access.readwrite
: Grants users the right to list, view and modify existing CAs.readonly
: Grants users the right to list and view CAs only.
Attribute Based Access Control¶
Krill supports inc_cas
and exc_cas
user attributes which can be used
to permit or deny access to one or more Certificate Authorities in Krill. User
attributes can also be used to make decisions in custom authorization policies.