Skip to content

Commit e4a99ec

Browse files
committed
Documentation for labels.
1 parent a6fb104 commit e4a99ec

File tree

1 file changed

+65
-0
lines changed

1 file changed

+65
-0
lines changed

docs/labels.md

Lines changed: 65 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,65 @@
1+
# Labels
2+
3+
Labels are a top-level concept that provide an additional layer of classification and metadata within the system. While "atoms" represent minimal policy units and "roles" group these atoms into larger policy sets, "labels" serve as tags or categories that can be attached to roles (and potentially other objects) for organizational or access-control purposes.
4+
5+
## What is a Label?
6+
7+
A Label is a named entity with a human-readable description. The Label model enforces a few key constraints:
8+
9+
- **Uniqueness and Format:** Each label has a unique lowercase name. This helps ensure there's a consistent taxonomy of labels that can be easily referenced.
10+
- **Description:** A textual field describes the label's purpose or meaning.
11+
12+
Labels can thus represent concepts like functional areas, environments, departments, or security domains. For example, labels might include finance, production, staging, or webserver, depending on how your organization categorizes hosts and roles.
13+
14+
## How Labels Are Used in mreg
15+
16+
### Applying Labels to Roles
17+
18+
In the hostpolicy code, specifically HostPolicyRole has a Many-to-Many relationship to Label. This means that a single role can have zero, one, or multiple labels.
19+
20+
These labels describe characteristics or intended domains of that role. For example, a role named db_admin_role might be labeled database or internal to indicate it's related to internal database administration policies.
21+
22+
### Filtering and Searching by Labels
23+
24+
In the `api/v1/` endpoints (like LabelList and LabelDetail), as well as filters (like LabelFilterSet), you can filter or retrieve labels by their names. For host policies, filters such as `labels__name__exact` or `labels__name__regex` are used when querying roles. This allows the API consumer to do queries like:
25+
26+
- Find all roles that have a label matching production.
27+
- Retrieve all roles that have labels with names containing db.
28+
29+
This functionality makes it easy to organize and discover roles based on the contexts their labels provide.
30+
31+
### Permission Checks Involving Labels
32+
33+
The permissions.py code for Hostpolicy demonstrates that labels are not just organizational tools; they also tie into the authorization logic. When a non-superuser attempts to modify a host or role, the code checks:
34+
35+
- Which labels are assigned to that role?
36+
- Does the requesting user have any NetGroupRegexPermission that matches those labels?
37+
38+
In other words, labels can act as a key to unlock modification privileges. If a user doesn't have permission to manipulate roles bearing a certain label, their requests to add/remove hosts or atoms to that role will be denied.
39+
40+
This is a powerful concept: by attaching labels to roles and by setting up permissions that reference these labels, the system can enforce complex, label-based security policies. For example:
41+
42+
- Roles labeled sensitive might be restricted to a particular group of administrators.
43+
- Roles labeled dev might be open to a broader set of users with matching permissions.
44+
45+
### Technical Details Linking Labels to Permissions
46+
47+
The permission code (IsSuperOrHostPolicyAdminOrReadOnly) checks whether a user is a superuser or hostpolicy admin. If not, and the user tries to modify (not just read) a role:
48+
49+
- It pulls the labels on that role via `role_labels = HostPolicyRole.objects.filter(name=name).values_list('labels__name', flat=True)`.
50+
- It then looks up NetGroupRegexPermission objects associated with the user to see if these permissions cover any of the role’s labels.
51+
52+
Only if there’s a match does the user gain write access.
53+
54+
## In Summary
55+
56+
- Labels are independent, top-level objects with unique names.
57+
- Roles can be assigned multiple labels.
58+
- Labels serve both as organizational tools (for searching and grouping roles) and as hooks in the permission system (to grant or restrict modifications).
59+
60+
### In practical terms
61+
62+
- From an API perspective, you can create and manage labels separately and you can assign these labels to roles.
63+
- When users try to change roles (like adding atoms or hosts), the label assignments to that role determine if the user’s existing permissions allow that change.
64+
65+
Thus, labels are a key component in organizing and controlling the complexity of host policies. They allow fine-grained access control and filtering, building on top of the more fundamental concepts of roles and atoms.

0 commit comments

Comments
 (0)