Security¶

Security model for OpenObserve covering multi-tenancy, RBAC, API token management, S3 bucket encryption, and authentication. See also: observability/openobserve/index, observability/openobserve/architecture, observability/openobserve/operations.

Security Architecture Overview¶

OpenObserve provides three tiers of security capability depending on edition:

Feature	Open Source	Enterprise	Cloud
Basic auth (username/password)	Yes	Yes	Yes
Multiple users	Yes	Yes	Yes
Multi-tenancy (organizations)	Yes	Yes	Yes
RBAC (predefined roles)	No	Yes (with OpenFGA)	Yes (preconfigured)
Custom roles	No	Yes	Yes
User groups	No	Yes	Yes
Service accounts	No	Yes	Yes
SSO (SAML/OIDC)	No	Yes	Yes

flowchart TD
    subgraph "External"
        Clients[API Clients<br/>Collectors / Agents]
        Users[Browser Users]
        IdP[Identity Provider<br/>SAML / OIDC / Dex]
    end

    subgraph "OpenObserve"
        API[API Gateway<br/>Basic Auth Validation]
        RBAC[RBAC Engine<br/>OpenFGA Enterprise]
        Ingester[Ingester<br/>Data Processing]
        Querier[Querier<br/>SQL / PromQL]
    end

    subgraph "Storage"
        Meta[(Meta Store<br/>PostgreSQL / SQLite)]
        S3[S3 / GCS / Azure Blob<br/>SSE-KMS Encrypted]
        WAL[Local WAL<br/>Disk Buffer]
    end

    Clients -->|Authorization: Basic base64 user:pass| API
    Users -->|Login / SSO| API
    API -->|Validate credentials| Meta
    API -->|Check permissions| RBAC
    RBAC --> IdP
    API --> Ingester
    API --> Querier
    Ingester --> WAL --> S3
    Querier --> S3

Authentication¶

Basic Authentication¶

All OpenObserve API endpoints require HTTP Basic authentication:

GET /api/default/_search
Authorization: Basic base64("username:password")

The root user is configured at startup:

auth:
  ZO_ROOT_USER_EMAIL: "[email protected]"
  ZO_ROOT_USER_PASSWORD: "secure-password"
  ZO_ROOT_USER_TOKEN: ""

Root User

The root user has unrestricted access to all organizations and settings. The root token (ZO_ROOT_USER_TOKEN) can be used for API automation.

SSO Integration (Enterprise)¶

OpenObserve Enterprise supports SAML 2.0 and OIDC for single sign-on. The Dex identity service is commonly deployed alongside OpenObserve for OIDC:

# values.yaml for Enterprise Edition
openfga:
  enabled: true    # Required for RBAC
dex:
  enabled: true    # OIDC identity provider

SSO configuration steps: 1. Deploy OpenFGA for authorization decisions. 2. Deploy Dex (or configure an external IdP) for authentication. 3. Map IdP groups to OpenObserve roles via the UI or API.

Multi-Tenancy¶

OpenObserve uses organizations as the primary multi-tenancy boundary. Each organization has isolated:

Streams (logs, metrics, traces)
Dashboards
Alerts
Pipelines
User permissions

Organization Isolation¶

# Query data in a specific organization
GET /api/{organization}/_search
Authorization: Basic base64("user:pass")

Data from Organization A is not accessible from Organization B unless the user has explicit permissions in both.
Each organization can have separate retention policies, stream settings, and pipeline configurations.
Quotas can be set per organization (Enterprise) to limit ingestion volume, storage, and query frequency.

Stream-Level Quotas (Enterprise)¶

Organizations can enforce quotas to prevent noisy-neighbor scenarios:

Maximum ingestion rate per stream.
Maximum storage per organization.
Maximum query frequency per user.

Role-Based Access Control¶

Predefined Roles (Enterprise/Cloud)¶

OpenObserve provides five built-in roles:

Role	Dashboards	Streams	Alerts	Users	Settings
Root	All	All	All	All	All
Admin	All (org)	All (org)	All (org)	Manage (org)	All (org)
Editor	Create/Edit	Read/Write	Create/Edit	None	None
Viewer	View only	Read only	View only	None	None
User	Limited	Limited	None	None	None

Custom Roles (Enterprise)¶

Administrators can create custom roles with fine-grained permissions using OpenFGA:

POST /api/roles
{
  "name": "logs-analyst",
  "permissions": [
    "streams:read",
    "streams:query",
    "dashboards:read",
    "dashboards:create"
  ]
}

User Groups (Enterprise)¶

Users can be organized into groups, and permissions assigned at the group level:

Group membership managed via the UI or API.
Role assignments inherited by all group members.
Simplifies permission management for large teams.

Service Accounts (Enterprise)¶

Service accounts provide machine-to-machine authentication with role-based token access:

POST /api/service_accounts
{
  "name": "fluentbit-ingester",
  "role": "Editor"
}

Tokens are scoped to the service account's role and organization.
Separate from user accounts; not affected by user lifecycle events.
Suitable for collectors, CI/CD pipelines, and automation tools.

API Token Management¶

Root Token¶

The root token is configured at deployment time:

auth:
  ZO_ROOT_USER_TOKEN: "secure-random-token"

This token grants unrestricted API access. Protect it as a secret:

# Kubernetes secret
kubectl create secret generic openobserve-root-token \
    --from-literal=token="$(openssl rand -hex 32)"

User Tokens¶

Each user authenticates via Basic Auth. The API validates credentials against the metadata store (PostgreSQL or SQLite). There is no separate token issuance for OSS users; Enterprise users can create service account tokens.

Object Storage Encryption¶

OpenObserve stores all telemetry data in S3-compatible object storage as compressed Parquet files. Encryption at rest is enforced at the bucket level.

S3 Configuration¶

auth:
  ZO_S3_ACCESS_KEY: "AKIAIOSFODNN7EXAMPLE"
  ZO_S3_SECRET_KEY: "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"
config:
  ZO_S3_BUCKET_NAME: "openobserve-prod"
  ZO_S3_REGION_NAME: "us-west-1"

EKS IAM Role Integration¶

On Amazon EKS, use IAM Roles for Service Accounts (IRSA) instead of static credentials:

serviceAccount:
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::123456789:role/zo-s3-eks

This eliminates static S3 credentials from the deployment and relies on temporary, automatically-rotated IAM credentials.

Encryption Recommendations¶

Method	Use Case
SSE-S3	Default; AWS-managed keys
SSE-KMS	Recommended; audit trail via CloudTrail; customer-managed key rotation
SSE-C	Maximum control; client provides key per request

Bucket policies should restrict access to the OpenObserve service account only:

{
  "Effect": "Deny",
  "Principal": "*",
  "Action": "s3:*",
  "Resource": "arn:aws:s3:::openobserve-prod/*",
  "Condition": {
    "StringNotEquals": {"aws:PrincipalArn": "arn:aws:iam::123456789:role/zo-s3-eks"}
  }
}

Metadata Store Security¶

OpenObserve uses PostgreSQL (recommended for production) or SQLite (development) for metadata:

auth:
  ZO_META_POSTGRES_DSN: "postgres://openobserve:password@postgres:5432/openobserve?sslmode=require"

Always use sslmode=require for PostgreSQL connections in production.
Create a dedicated database user with schema-level permissions only.
Store the DSN as a Kubernetes secret, not in plaintext values.

Network Security¶

Port	Protocol	Purpose	Exposure
5080	HTTP	Web UI and API	Behind TLS proxy
5081	HTTP	gRPC ingestion (OTLP)	Internal only
5082	HTTP	Internal cluster communication	Internal only

TLS Termination¶

OpenObserve does not include built-in TLS termination. Deploy behind a reverse proxy (Nginx, Envoy, AWS ALB) for HTTPS:

server {
    listen 443 ssl;
    ssl_certificate /etc/nginx/certs/server.crt;
    ssl_certificate_key /etc/nginx/certs/server.key;

    location / {
        proxy_pass http://openobserve:5080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

Hardening Checklist¶

Area	Recommendation
Root credentials	Change default password immediately; use strong password or token
TLS	Terminate TLS at reverse proxy; enforce HTTPS
S3 encryption	Use SSE-KMS with customer-managed keys
S3 credentials	Use IAM roles (IRSA) instead of static access keys
PostgreSQL	Enable `sslmode=require`; dedicated user
RBAC	Enable OpenFGA for granular permissions (Enterprise)
Service accounts	Use dedicated tokens for collectors and automation
Network	Restrict gRPC ingestion port to internal traffic only
Secrets	Store all credentials in Kubernetes secrets or Vault
Quotas	Set ingestion and storage quotas per organization