Skip to main content

Okta

The Okta Matano managed log source lets you ingest your Okta System logs directly into Matano.

Usage

Use the managed log source by specifying the managed.type property in your log_source as OKTA.

name: okta

managed:
type: OKTA
properties:
base_url: <MY_OKTA_BASE_URL> # e.g. tenant-9179588-admin.okta.com

For the tables you would like to enable from this managed log source, under a tables/ subdirectory in your log source directory, create a file with the name <table_name>.yml>. For example:

my-matano-dir/
└── log_sources/
└── okta/
└── log_source.yml
└── tables/
└── system.yml

For a complete reference on configuring log sources, including extending the table schema, see Log source configuration.

Tables

The Okta managed log source supports the following tables:

  • system

Ingest

Pull (default)

Matano integrates with your Okta account to automatically pull relevant logs on a regular basis (every 5 min).

To get started with the integration, specify the following properties in the log source configuration file:

managed:
type: OKTA
properties:
base_url: <MY_OKTA_BASE_URL> # e.g. tenant-9179588-admin.okta.com

After the first deployment, this log source will also generate a secret in AWS secret's manager to store secrets related to this integration.

S3

To ingest Okta system logs via S3, without polling the API specify the following properties in the log source configuration file only, without specifying a base_url to poll:

name: okta

managed:
type: OKTA

For a log source named okta, a file under the path okta/afe3c55a-8b05-4ac7-be76-b6fda08af95d/system-log.log will be routed to the system table.

S3 Path scheme to table:

  • * (all) -> system

Secret

To finish onboarding the log source, populate the api_token key in the secret generated by Matano in AWS Secrets Manager, with the value from your OAuth app.

Schema

Okta log data is normalized to ECS fields. Custom fields are normalized into the okta field. You can view the complete mapping to see the full schema.