Guardian 5.1: Boosting Big Data Cluster Security with Trust Relations & Auditing

Guardian is a big‑data cluster security platform that offers a complete solution covering user authentication, service authorization, quota management, and security auditing for the Transwarp Data Hub (TDH) platform.

In version 5.1, Guardian adds several key features:

Comprehensive service audit logs.

Trust mechanisms between multiple Guardian services.

Automatic periodic data backup.

Permission plug‑in and management page for Slipstream.

Generic Kerberos SASL framework.

Generic SPNEGO authentication framework.

Trust Management

Guardian authenticates users via Kerberos. After Kerberos protection is enabled, only users from the same realm can be authenticated, isolating cross‑realm access. To allow cross‑realm access, Kerberos supports Cross‑Realm Authentication, which Guardian 5.1 implements as "Trust Relation".

Three trust relationship types exist between realms A and B:

A INCOMING B : B trusts A, allowing A’s users to access B’s services.

A OUTGOING B : A trusts B, allowing B’s users to access A’s services.

TWO_WAY : Mutual trust; users from both realms can access each other’s services.

The relationship is symmetric: A INCOMING B implies B OUTGOING A.

Example: with TDH and HDT realms, an INCOMING trust lets HDT authenticate TDH users, while an OUTGOING trust lets TDH authenticate HDT users. A TWO_WAY trust enables mutual authentication.

Only clusters with different realm names can configure trust relationships, so distinct naming is recommended.

Audit Function

Guardian 5.1 adds an audit feature for the Guardian Server that records every user operation, enabling later analysis and troubleshooting.

All audit logs are stored in a dedicated directory. Every user can view the logs, but only administrators can modify them. The audit logs help administrators monitor system health, detect faults, and identify abnormal behavior, thanks to a unified log structure.

The audit level is controlled by the parameter guardian.server.audit.level, allowing selection of operation types such as read, update, add, delete, permission check, and login.

Example audit log entry:

2017-11-07 12:12:07,007 field=PERMISSION,requestClass=GrantPermRequest,user=hive,serverIp=172.16.1.194,clientIp=172.16.1.194,level=UPDATE,operation=grant permission [PermissionVo{action='SELECT',dataSource=[TABLE_OR_VIEW,default,user_info],component='slipstream1'}] to [USER: admin],statusCode=200,errorCode=0

Field explanations:

field : operation category (e.g., PERMISSION).

requestClass : sub‑category of the operation (e.g., GrantPermRequest).

user : user who performed the operation.

serverIp : Guardian Server IP.

clientIp : client IP.

level : operation type (e.g., UPDATE).

operation : detailed action (e.g., granting SELECT permission).

statusCode : REST API response code (200 = success).

errorCode : 0 for success, non‑zero for errors.

This log shows that user hive successfully granted SELECT permission on a table in slipstream1 to user admin.

Conclusion

With the 5.1 upgrade, Guardian now delivers unified data security services, fine‑grained access control, cross‑realm authentication, log‑based security auditing, and broader security management, improving both usability and the overall security posture of big‑data clusters.