> ## Documentation Index
> Fetch the complete documentation index at: https://docs.nebuly.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Permissions and Authentication

## Overview

Nebuly uses two distinct authentication mechanisms depending on the type of access.

**End-user authentication** is handled through your enterprise identity provider (Google,
Microsoft, Okta or built-in basic autnetication). Users log into the Nebuly UI via SSO or basic authentication.

**Ingestion authentication** uses API keys. Any service sending data (interactions, traces) to Nebuly must include a project API key in every request:

```http theme={null}
Authorization: Bearer <api-key>
```

API keys are scoped to a project and can be created under **Settings → Project → API keys**.

### Default admin user on first startup

On first startup, you should create an initial admin user through the Helm values under `auth`.

```yaml theme={null}
auth:
  adminUserEnabled: true
  # -- The username of the initial admin user.
  adminUserUsername: "admin@nebuly.ai"
  # -- The password of the initial admin user.
  adminUserPassword: "securePassword"
```

Use a strong password that follows your organization's security standards (minimum length, mixed character types, and no reused credentials).
The initial admin user is intended for bootstrap access: use it to create additional users and assign roles, then disable it if your security policy requires removing the default admin account after setup.

### Roles and permissions

Nebuly has four built-in roles. Role assignment is managed directly in **Settings → Members**.
Admins can create users with specific roles and update both roles and project/organization access at any time.

| Role           | Description                                                                                  |
| -------------- | -------------------------------------------------------------------------------------------- |
| `admin`        | Full platform access. Manages members and all projects.                                      |
| `projectadmin` | Full access within a subset of projects. Can manage project members, API keys, and settings. |
| `member`       | Can view and interact with data within assigned projects. Cannot manage members or settings. |
| `viewer`       | Read-only access within assigned projects. Cannot modify any data or settings.               |

### Configuring SSO for self-hosted deployments

SSO is configured at the infrastructure level via the Nebuly Terraform module.
Pass your identity provider credentials as a module input and Terraform will
automatically inject them into the generated Helm values.

Supported providers: `google`, `microsoft`, `okta`.

```hcl theme={null}
module "platform" {
  source = "nebuly-ai/nebuly-platform/azurerm" # or /aws, /google

  google_sso = {
    client_id     = "<your-client-id>"
    client_secret = "<your-client-secret>"
  }
}
```

After `terraform apply`, re-run `terraform output helm_values` to pick up the updated values before upgrading the Helm chart.

Terraform module references:
[AWS](https://registry.terraform.io/modules/nebuly-ai/nebuly-platform/aws/latest) ·
[Azure](https://registry.terraform.io/modules/nebuly-ai/nebuly-platform/azurerm/latest) ·
[GCP](https://registry.terraform.io/modules/nebuly-ai/nebuly-platform/google/latest)