How Guardian 5.0 Reinvents Big Data Security with an Enhanced ARBAC Model

Guardian 5.0 Security Architecture Overview

Guardian 5.0 provides a complete security solution for the TDH big‑data platform, implementing user authentication, authorization, quota management and resource control through three major modules. LDAP and Kerberos protocols ensure only verified users can access the system; the authorization module restricts resource access to privileged users; quota management controls the amount of resources each user can consume.

Guardian 5.0 enhances the overall framework, ARBAC model, multi‑granular permission management, resource control and operation simplification. This article introduces the framework and ARBAC model improvements; later features will be covered in a subsequent article.

Overall Structure

Guardian 5.0 architecture consists of four layers:

Bottom layer: ApacheDS

Guardian 5.0 replaces the previous OpenLDAP+Kerberos solution with an improved ApacheDS, using a unified LDAP/Kerberos authentication method, accelerating LDAP authentication efficiency. The ApacheDS backend database has been optimized, achieving more than tenfold read/write performance improvement, and provides a Master‑Slave HA solution to ensure data safety and reliability.

Second layer: Guardian Server

The second layer is an independent Guardian Server that implements a full ARBAC model, offers REST APIs, a user‑friendly Web UI, password policies, and adopts JWT token mechanism for future SSO support. It unifies authentication and authorization across services (e.g., Workflow, Rubik, Hadoop) and exposes LDAP, REST, and LoginService interfaces for third‑party integration. Cross‑domain trust enables Microsoft AD and MIT Kerberos users to access TDH clusters seamlessly.

Third layer: Plugins

The plugin layer provides authentication, authorization, group mapping and quota management for various TDH components, allowing them to use a unified user, group and permission model.

Top layer: Service Applications

The top layer consists of TDH services that integrate with Guardian and are protected by its security mechanisms.

Enhanced ARBAC Model

In version 4.x, different TDH components used disparate permission models (POSIX‑like ACL for HDFS, role‑based RBAC for Inceptor and HBase), requiring separate logins and authorizations. Guardian 5.0 introduces an enhanced Administrative Role‑Based Access Control (ARBAC) model that unifies permission management across components, allowing administrators to grant permissions via a single Web UI or REST API while remaining compatible with existing SQL and HBase shell authorizations.

The enhanced ARBAC model has two layers:

First layer: Organizational Management

The upper layer handles personnel and IT resource management, allowing users to be grouped according to organizational hierarchy. Each group functions as an independent tenant with its own administrator responsible for managing users, sub‑groups and roles.

Second layer: Security Management

The lower layer defines fine‑grained permissions for resources (e.g., read, write, execute on HDFS paths). Permissions can be assigned directly to users/groups or encapsulated in roles. Assigning a role to a user or group grants all associated permissions. Administrative Permissions and Administrative Roles enable granular control over actions such as creating users, groups, roles, or managing quotas.

Guardian 5.0 predefines ten system‑management permissions, but any operation can be mapped to a specific permission for detailed control.

Conclusion and Preview

This article presented the architectural improvements of Guardian 5.0 and its enhanced ARBAC model, which provide standardized LDAP/Kerberos/JWT authentication and a unified, fine‑grained permission system across TDH components. The next article will discuss multi‑granular permission control, resource management capabilities, and how operational steps are simplified.