mart-w/kanidm
1
0
Fork 0
mirror of https://github.com/kanidm/kanidm.git synced 2025-02-23 12:37:00 +01:00
Code Issues Actions 16 Packages Projects Releases Wiki Activity

Improve access control doc to describe privilege access mode (#2721)

Browse source 
* Improve access control doc to describe privilege access mode

* Update book/src/access_control/intro.md

---------

Co-authored-by: James Hodgkinson <james@terminaloutcomes.com>
This commit is contained in:
Firstyear 2024-04-24 14:29:58 +10:00 committed by GitHub
parent afc130ab89
commit 3707124218
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
2 changed files with 17 additions and 4 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

5
book/src/SUMMARY.md
View file

@ -33,6 +33,8 @@
- [Account Policy](accounts/account_policy.md)
- [POSIX Accounts and Groups](accounts/posix_accounts_and_groups.md)
- [Access Control](access_control/intro.md)
- [Service Integrations](integrations/readme.md)
- [PAM and nsswitch](integrations/pam_and_nsswitch.md)
- [SUSE / OpenSUSE](integrations/pam_and_nsswitch/suse.md)
@ -57,8 +59,6 @@
- [FreeIPA](sync/freeipa.md)
- [LDAP](sync/ldap.md)
- [Access Control](access_control/intro.md)
# Support
- [Troubleshooting](troubleshooting.md)
@ -90,4 +90,3 @@
- [Debian/Ubuntu Packaging](packaging/debian_ubuntu_packaging.md)
- [PPA Packages](packaging/ppa_packages.md)
- [Community Packages](packaging/community_packages.md)

16
book/src/access_control/intro.md
View file

@ -10,11 +10,25 @@ actions.
The project ships default access controls which are designed to limit and isolate the privileges of
accounts whenever possible.
This separation is the reason why `admin` and `idm_admin` exist as separate accounts. There are two
This separation is the reason why `admins` and `idm_admins` exist as separate groups. There are two
distinct access silos within Kanidm. Access to manage Kanidm as a service (such as application
integrations and domain naming) and access to manage people and groups. This is to limit the
possible harm that an attacker may make if they gain access to these roles.
## Assigning Permissions to Persons
Kanidm supports [privilege access mode](../accounts/authentication_and_credentials.md) so that
high-level permissions can be assigned to users who must reauthenticate before using those
privileges. The privileges then are only accessible for a short period of time. This can allow you
to assign high level permissions to regular persions accounts rather than requiring separete
privilege access accounts (PAA) or privileged access workstations (PAW).
## Assigning Permissions to Service Accounts
Service account tokens can be issued with read-only or read-write flags, where read-only tokens are
unable to modify content of Kanidm. This can allow the service account to have higher level
permissions assigned but only usable with a short lived or isolated read-write token.
## Permission Delegation
A number of types in Kanidm allow permission delegation such as groups and service accounts. This