|
| 1 | + |
| 2 | +# Pangolin Authentication Guide |
| 3 | + |
| 4 | +This guide details how authentication works in Pangolin when the system is running in standard production mode (Auth Mode). |
| 5 | + |
| 6 | +## 1. The Root User |
| 7 | + |
| 8 | +The **Root User** is the super-administrator of the entire Pangolin system. This user exists outside of any specific tenant. |
| 9 | + |
| 10 | +- **Scope**: System-wide. No specific `tenant_id`. |
| 11 | +- **Capabilities**: |
| 12 | + - Create and delete Tenants. |
| 13 | + - Create the initial Tenant Admin for a Tenant. |
| 14 | + - View global system statistics (e.g., total tenants, total tables). |
| 15 | +- **Limitations**: |
| 16 | + - Cannot query data within a Tenant's catalogs unless explicitly granted permission (conceptually separate). |
| 17 | + - Cannot be assigned to a specific Tenant. |
| 18 | + |
| 19 | +**Configuration**: |
| 20 | +You can define the initial credentials for the Root User using environment variables. This is critical for securing your production deployment. |
| 21 | + |
| 22 | +```bash |
| 23 | +# Default values if not specified: admin / password |
| 24 | +export PANGOLIN_ROOT_USER="super_admin" |
| 25 | +export PANGOLIN_ROOT_PASSWORD="complex_secure_password" |
| 26 | +``` |
| 27 | + |
| 28 | +**Login Behavior**: |
| 29 | +- **API**: Login with `username` and `password`, leaving `tenant_id` null. |
| 30 | +- **UI**: Use the dedicated Root Login toggle or route (e.g., `/login` with "Root" checked). |
| 31 | + |
| 32 | +## 2. Authentication Flows |
| 33 | + |
| 34 | +### Generating Tokens (API/CLI) |
| 35 | + |
| 36 | +Authentication tokens (JWTs) act as your digital keys. |
| 37 | + |
| 38 | +**For Tenant Admins & Users**: |
| 39 | +You must provide the `tenant_id` along with credentials. |
| 40 | + |
| 41 | +```bash |
| 42 | +# Example Request |
| 43 | +POST /api/v1/users/login |
| 44 | +{ |
| 45 | + "username": "data_analyst", |
| 46 | + "password": "secure_password", |
| 47 | + "tenant_id": "123e4567-e89b-12d3..." |
| 48 | +} |
| 49 | + |
| 50 | +# Response |
| 51 | +{ |
| 52 | + "token": "eyJhbGciOiJIUz...", |
| 53 | + "expires_in": 86400 |
| 54 | +} |
| 55 | +``` |
| 56 | + |
| 57 | +**For Root**: |
| 58 | +Omit the `tenant_id`. |
| 59 | + |
| 60 | +### Logging into the UI |
| 61 | + |
| 62 | +The UI login page adapts based on the user type: |
| 63 | + |
| 64 | +1. **Tenant Login**: |
| 65 | + - **Username**: Your username. |
| 66 | + - **Password**: Your password. |
| 67 | + - **Tenant ID**: The UUID of your organization/tenant. |
| 68 | +2. **Root Login**: |
| 69 | + - Click "Login as System Root". |
| 70 | + - Enter only Username and Password. |
| 71 | + |
| 72 | +## 3. Testing with PyIceberg |
| 73 | + |
| 74 | +When running in Auth Mode, PyIceberg requires a valid token and the tenant context. |
| 75 | + |
| 76 | +```python |
| 77 | +from pyiceberg.catalog import load_catalog |
| 78 | + |
| 79 | +# 1. Obtain a token (e.g., via script or manually from UI) |
| 80 | +token = "YOUR_GENERATED_JWT_TOKEN" |
| 81 | +tenant_id = "YOUR_TENANT_UUID" |
| 82 | + |
| 83 | +# 2. Configure PyIceberg |
| 84 | +catalog = load_catalog( |
| 85 | + "production", |
| 86 | + **{ |
| 87 | + "type": "rest", |
| 88 | + "uri": "http://localhost:8080/api/v1/catalogs/sales/iceberg", |
| 89 | + "token": token, |
| 90 | + # Required for Multi-tenancy routing |
| 91 | + "header.X-Pangolin-Tenant": tenant_id |
| 92 | + } |
| 93 | +) |
| 94 | +``` |
| 95 | + |
| 96 | +## 4. Permissions Matrix |
| 97 | + |
| 98 | +Pangolin uses a hierarchical RBAC system. |
| 99 | + |
| 100 | +### Roles |
| 101 | + |
| 102 | +| Role | Scope | Description | |
| 103 | +| :--- | :--- | :--- | |
| 104 | +| **Root** | System | Manages Tenants. Cannot manage data inside a tenant directly without assuming a tenant context (if allowed). | |
| 105 | +| **Tenant Admin** | Tenant | Full control over a specific Tenant's resources (Users, Catalogs, Roles). | |
| 106 | +| **Tenant User** | Tenant | Zero access by default. Must be granted specific permissions. | |
| 107 | + |
| 108 | +### Permissions Granting |
| 109 | + |
| 110 | +Permissions are additive. A user can be granted specific Actions on specific Scopes. |
| 111 | + |
| 112 | +| Scope | Description | Implied Children | |
| 113 | +| :--- | :--- | :--- | |
| 114 | +| **Tenant** | Entire Tenant | All Catalogs, Namespaces, Tables | |
| 115 | +| **Catalog** | Specific Catalog | All Namespaces, Tables within | |
| 116 | +| **Namespace** | Specific Namespace | All Tables within | |
| 117 | +| **Table/Asset** | Specific Table | None | |
| 118 | + |
| 119 | +| Action | Description | |
| 120 | +| :--- | :--- | |
| 121 | +| **Read** | Read metadata and data. | |
| 122 | +| **Write** | Insert, update, delete data. | |
| 123 | +| **Create** | Create new resources (Tables, Namespaces). | |
| 124 | +| **Delete** | Drop resources. | |
| 125 | +| **List** | See that the resource exists (Discovery). | |
| 126 | +| **ManageDiscovery** | Mark assets as strictly discoverable (metadata visible, data locked). | |
| 127 | + |
| 128 | +### Common Scenarios |
| 129 | + |
| 130 | +- **Data Analyst**: Grant `Read` on specific `Namespace`. |
| 131 | +- **Data Engineer**: Grant `Read`, `Write`, `Create` on specific `Catalog`. |
| 132 | +- **Auditor**: Grant `List` (Discovery) on `Tenant` + `Read` on `audit_logs` (conceptually). |
0 commit comments