RBAC as It Was Meant to Be – A Comprehensive Guide to Access‑Control Models

RBAC as It Was Meant to Be

This translation of a 2021 English blog explains why many systems (Kubernetes, AWS, etc.) use RBAC for permission control and walks through the historical evolution of access‑control models: DAC → MAC → RBAC → ABAC.

1. From DAC to MAC

1.1 DAC (Discretionary Access Control) – The file owner decides who can read/write/execute. Example in Unix: chmod changes the mode, granting read/write/execute permissions.

Design : The owner directly sets permissions on the object.

Use‑case : Ordinary user file sharing; not suitable for strict compliance because owners can freely reshare.

1.2 MAC (Mandatory Access Control)

MAC adds an administrator‑defined rule set that overrides owners. The admin (or an administrative rule) defines which permissions are allowed, preventing owners from changing them.

Example : TCP/UDP port numbers – once a process binds a port, no other process (even privileged) can use it, illustrating a mandatory restriction.

Use‑case : Document or system‑level access control where compliance is critical.

1.3 MAC as Two‑Factor Login

Combining a password (DAC) with a hardware token (MAC) creates a mandatory factor that cannot be shared, similar to MFA/2FA.

1.4 DAC vs. MAC for Image Sharing

With a secret URL (DAC) anyone can reshare; with MAC, only authenticated users can view, and reshare is blocked.

1.5 Limitations of Classic MAC

Real‑world MAC implementations (e.g., SELinux) are complex and hard to manage.

2. First Attempt: RBAC / ABAC

2.1 RBAC – A subset of MAC where roles (groups) are assigned to users and permissions are granted to roles.

2.2 ABAC – Extends RBAC by adding attributes (location, device, cookies, etc.) to the decision process.

2.3 Real‑world example : Windows file security uses an ACL per file, where each ACL lists users/groups and their allowed actions.

3. Second Attempt: One ACL per User Group

Move most ACL information into centralized user groups (e.g., report-readers , report-writers ) to reduce duplication and simplify audits.

4. Third Attempt: Object Tags

Introduce tags that describe objects (e.g., database , sourcefile ) and let role‑tag combinations generate entitlements.

4.1 Create groups by user type, not file type – HR defines human‑relevant roles (Accounting, DevOps, Engineering, Executive).

4.2 Flatten roles into policy rules – ACLs become a set of policy rules linking roles to tags.

4.3 Policy‑rule example – Changing the readers of a database object to [DevOps, Prod] instantly restricts access.

4.4 Additional features – Objects can have multiple tags; only the tag owner may add or remove that tag on an object.

4.5 MAC Returns – No global admin needed; tag owners enforce policies within the constraints defined by roles.

4.6 API Access Control Example – In a Tailscale‑like system, nodes and ports are tagged; policies dictate which roles may start which nodes and which connections are allowed.

5. Separation of Duties

5.1 Automatic permission generation – Policy rules and group membership are used to compute effective entitlements.

5.2 Roles vs. Tags – Roles describe identity (managed by HR), tags describe object classification (managed by owners), and policies bind them together.

5.3 Summary – Properly separating these concerns avoids friction in large organizations.

6. Conclusion

The concepts of users, roles, tags, and policies date back to the original 1992 RBAC paper; modern implementations can adopt them without excessive complexity.

In Tailscale, devices and ports are the objects, tags are applied by owners, security teams define which roles may use which tags, and HR assigns users to roles.

Appendix: Tailscale ACL JSON Example

{
  "action": "accept",
  "users": [ /* list of sources */ ],
  "ports": [ /* list of destinations */ ]
}

Both users and ports are broader than their literal names and map to subjects and objects in the RBAC model.