Table of Contents

o2_api.png

Introduction

Note: Applicable to Enterprise version (Free to download and use if daily ingestion volume is under 200 GB)

When using OpenObserve to monitor your infrastructure, applications often need to interact with OpenObserve APIs to consume data programmatically. While data ingestion is secured with ingestion tokens, non-ingestion APIs previously required native user credentials, which could risk exposing sensitive login details. Service Accounts in OpenObserve provide a secure solution for programmatic API access. This post explains how Service Accounts work and how you can use them to enhance security and streamline automation.

Understanding Service Accounts in OpenObserve

Service Accounts in OpenObserve enable secure, programmatic access to APIs without sharing user credentials. They support two types:

  • Native Service Accounts: For local authentication setups.
  • SSO Service Accounts: For integration with external Identity Providers (IdPs).

Key features of Service Accounts include:

  • Token-Based Access: Use secure tokens for API calls.
  • ReBAC Governance: Leverage Relationship-Based Access Control (ReBAC) for fine-grained permissions.
  • Token Rotation: Easily rotate tokens to maintain security.
  • UI Restriction: Service Accounts cannot log into the OpenObserve UI, ensuring programmatic use only.
  • Quota Management: Service accounts are bound by a per-user quota defined by the role-level rate limit rule and also consumed from the overall org-level quota.

Role of ReBAC

ReBAC, powered by OpenFGA, enables precise control over Service Account permissions, ensuring access only to authorized resources and APIs.

Using Native Service Accounts in Local Authentication Mode

To create and use a Native Service Account in Local Authentication Mode, follow these steps:

  1. Navigate to IAM: Access the Identity and Access Management section in OpenObserve.
  2. Select Service Accounts: Go to the Service Accounts tab.
  3. Add a Service Account: Click the Add Service Account button.
  4. Enter Details: Provide required information, such as Email, First Name, and Last Name.

add-service-account.png

  1. Retrieve Your Token: After creation, you’ll receive a unique token for secure API access.
  2. Configure ReBAC Controls: Set up permissions using Relationship-Based Access Control:
    • Go to IAM > Roles > Add Role.
    • Select appropriate permissions.
    • Assign the Service Account to the role.
    • Click Save.

permissions.png

These steps prepare your Service Account for secure API interactions.

Leveraging SSO Mode with Token Exchange

For organizations using an external Identity Provider (IdP), OpenObserve’s Service Accounts support token exchange for seamless integration. Here’s how token exchange works and how to use it.

What is Token Exchange?

OAuth 2.0 Token Exchange (RFC8693) enables a client to exchange one token (e.g., from an IdP) for another to access resources securely. This is useful for:

  • Delegation & Impersonation: Allowing a service to act on behalf of a user or another service.
  • Scope Adjustment: Downgrading or upgrading token permissions to match specific needs.
  • Cross-Domain Access: Accessing resources across different trust domains.

How Token Exchange Works

The token exchange process involves:

  1. Client Initiates Request: The client sends a request to the authorization server’s token endpoint with the urn:ietf:params:oauth:grant-type:token-exchange grant type, the token to exchange, and desired token type.
  2. Validation: The server verifies the client’s credentials and the token’s validity.
  3. New Token Issued: If valid, the server generates and returns a new token.

Tokens are categorized as:

  • Subject Token: Represents the identity of the party on whose behalf the request is made.
  • Actor Token: Identifies the client or service making the request.
  • Requested Token: The new token issued, tailored to the requested scopes and resources.

Using Token Exchange with OpenObserve

Token exchange enables secure access to OpenObserve APIs when your application uses an external IdP. For example, if your application holds a token from your organization’s IdP, you can exchange it for a token issued by dexIdP (OpenObserve’s federated OpenID Connect provider) to access OpenObserve APIs.

The process:

  1. Your application sends its IdP-issued token to OpenObserve’s token exchange endpoint.
  2. OpenObserve’s dexIdP validates the token and issues a new token scoped for OpenObserve APIs.
  3. The application uses the new token to call OpenObserve APIs securely.

token-exchange-flow.png

This ensures a seamless trust relationship between your IdP and OpenObserve, with tokens scoped for secure API access.

Configuring Trust Between Your IdP and OpenObserve

To enable token exchange, configure dexIdP as a federated OpenID Connect provider. Below is a sample dex configuration:

- type: oidc
  id: api-google
  name: APIGoogle
  config:
    issuer: https://accounts.google.com
    scopes:
      - groups
      - federated:id
      - email
    userIDKey: email
    groupsKey: groups
    getUserInfo: true

Set the environment variable in OpenObserve to match the connector ID:

O2_DEX_TOKEN_EXCHANGE_CONNECTOR_ID = "api-google"

This establishes trust between your IdP and dexIdP for token exchange.

Managing Service Accounts with Token Exchange

To exchange a token, use OpenObserve’s /config/token API. Sample request:

{
  "token": "ya29.a0ARW5m75VtoH4fF4cAYmjkac3SAMZ8MVoEUDFcuQwohObvHcb9g8D7BvdGVZeoCVK8LjamX9XckcoNli8g7iO6_8QbyFShHB_OCk7L42ucPIMbvgF-rfCJficqDd1xc9DfmEoYaCgYKAeQSARISFQHGX2MiTjup_6LuKHyX9qIfEWWaUw0170",
  "token_type": "AccessToken"
}

The token_type can be AccessToken or IdToken, depending on your setup.

The API response:

{
  "access_token": "eyJhbGciOiJSUzI1NiIsImtpZCI6IjAwZWI3Njc5NGViOTFjMjAxZmZiZWMwZWE1ZTBiNzcwMjk2NzdiNGUifQ.eyJpc3MiOiJodHRwOi8vbG9jYWxob3N0OjU1NTYvZGV4Iiwic3ViIjoiQ2hWaGMyaHBjMmhBYjNCbGJtOWljMlZ5ZG1VdVlXa1NDbUZ3YVMxbmIyOW5iR1UiLCJhdWQiOiJleGFtcGxlLWFwcCIsImV4cCI6MTczNTU0OTEyNywiaWF0IjoxNzM1NTQ3MzI3LCJhdF9oYXNoIjoicEc4WGZyR1pURWVkUk1hcE5hWnFnZyIsImZlZGVyYXRlZF9jbGFpbXMiOnsiY29ubmVjdG9yX2lkIjoiYXBpLWdvb2dsZSIsInVzZXJfaWQiOiJhc2hpc2hAb3Blbm9ic2VydmUuYWkifX0.J2wzp0YeXySIdjHX1z6qik_g4G4hY_pWsigyjdKOKKiSKbBixfc-i295y4Ci37QYoFgRZcM-OACas0F-24DPVuYnZoAWcgjVRLhv-_-KxD1kyDfvP_8zypHqQm5e9fTd5Bi55WXMH-GNQLm3zNbbMbK9s-VIcX4xaWGSdUkXtsuL368JDOL4E0vQ6Q3SiOo_SK9neKtsSkKZSf9al6BNDH1Bo71xOMHOxs6Rh_XXDIv8znuNz0csemvGVkVbGU-lO0Dt9_EsQJRmZUfWVq2OcKEy3z95ROBQtRhreSl-IB41tpW2NkO8BlJ3sPPNAKVk6Ypc_knppNLQ",
  "token_type": "bearer",
  "expires_in": 1799,
  "issued_token_type": "urn:ietf:params:oauth:token-type:access_token"
}

The subject of the exchanged token is stored as a Service Account in OpenObserve. To control its API access:

  1. Navigate to the IAM menu.
  2. Assign appropriate permissions to the Service Account for precise resource access.

This ensures robust security and granular control.

Conclusion

OpenObserve’s Service Accounts provide a powerful way to securely integrate applications with OpenObserve APIs. With token exchange, dexIdP integration, and ReBAC, you can achieve seamless cross-domain access, dynamic permission management, and enhanced security. Whether using Native Service Accounts or SSO-based token exchange, this feature simplifies automation while keeping your data secure.

Ready to streamline your observability workflows? Explore Service Accounts in OpenObserve today.

Check out our GitHub repository to explore self-hosting options and join the community.

About the Author

Manas Sharma

Manas Sharma

TwitterLinkedIn

Manas is a passionate Dev and Cloud Advocate with a strong focus on cloud-native technologies, including observability, cloud, kubernetes, and opensource. building bridges between tech and community.

Latest From Our Blogs

View all posts