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.