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.