particle-os/debian-koji
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

doc updates

Browse source
This commit is contained in:
Mike McLean 2020-08-25 16:09:25 -04:00 • committed by Tomas Kopecek
parent febdb1cb8b
commit 9236b9bb4c
1 changed files with 30 additions and 22 deletions
Download patch file Download diff file Expand all files Collapse all files

52
docs/source/access_controls.rst
View file

@ -2,7 +2,7 @@
Access Controls
===============
Koji is complex system, so there are many places where some kind of access
Koji is a complex system, so there are many places where some kind of access
control is used. Here is the documentation hub for all the mechanisms in place.
User/Builder Authentication
@ -13,40 +13,48 @@ preferred is GSSAPI/Kerberos authentication. Second best is authentication via
SSL certificates. Mostly for testing environments we also support authenticating via
username/password but it has its limitations which you should be aware of.
Details can be find at :ref:`auth-config`
Details can be found at :ref:`auth-config`
SCM Permissions
===============
Allowed SCMs
============
Most important data for koji are its inputs which equals to Source Control
Management systems (supported are CVS, SVN and GIT). Every production
environment should have limited set of trusted external sources. We're covering
this by ``alowed_scms`` option in builder's config. Admin can set there which
e.g. GIT repositories are allowed as inputs and can also instruct koji how to
create SRPM from such checkout.
The ``allowed_scms`` option in builder's config controls which SCMs (Source Control Management
systems) are allowed for building.
We recommend that every production environment choose a limited set of trusted sources.
Details of ``alowed_scms`` option is covered under :ref:`scm-config`
Details of the ``allowed_scms`` option are covered under :ref:`scm-config`
Hub Policies
============
Hub policies are core system of access controls. They can define specialized
policies for many things ranging from permissions to tag specific builds to
specific tag to e.g. assigning builds to specific builders (channels) or storing
results on different disk volumes. Policies allow user permissions (see below)
to be used in their rulesets.
Hub policies are a powerful way for administrators to control Koji's behavior.
Koji's hub allows several different policies to be configured, some of which are
access control policies.
Only some policies are for access control (allow/deny permissions checks) while
others like channel policy governs different areas of koji.
An access control policy is consulted by the hub to determine if an action should be allowed.
Such policies return results of ``deny`` or ``allow``.
There is whole document :doc:`defining_hub_policies` covering this.
Examples of access control polices are:
* tag: control which tag operations are allowed
* package_list: control which package list updates are allowed
* cg_import: control which content generator imports are allowed
* vm: control which windows build tasks are allowed
* dist_repo: control which distRepo tasks are allowed
* build_from_srpm: control whether builds from srpm are allowed
* build_from_repo_id: control whether builds from user-specified repos ids are allowed
Note that not all policies are access control policies.
The ``channel`` and ``volume`` policies are used to control which channels tasks go to
and which volumes build are stored on.
For more details see :doc:`defining_hub_policies`.
User Permissions
================
Specific chapter are user permissions. Every user can have set of permissions
which allow him to do some actions directly (typically ``admin`` permission) or
these permissions can be referenced in hub policies.
Every user can have a set of permissions which allow them to perform some actions directly.
These permissions may be checked directly by the hub, or they may be referenced in policies.
See :doc:`permissions` for details.