Skip to main content

​
How to Set Up Bots

Note: The Bots tile under Settings is only visible to users with Admin privileges. If you don’t see it, ask your organization’s OpenMetadata Admin to generate a bot token for you or grant you Admin access.
The default account for any ingestion pipeline deployed from the UI is ingestion-bot. To configure ingestion-bot from the UI, go to the settings page and access the Bots tile. settings-bot bot-listing You can either create a new bot or update the existing ingestion-bot.

​
Update ingestion-bot

Click on ingestion-bot and you will be redirected to it’s details page, there you can
  • Revoke the token if already present
  • Copy the generated token
bot-listing
  • Generate new token
generate new token token generate page

​
Create a new bot

Click the Add bot button, and you will be directed to the bot creation page. Fill in the required details and then click on the Create button. create bot

​
Notes:

1. ingestion-bot The ingestion-bot bot is created (or updated if it already exists) as a system bot that cannot be deleted, and the credentials used for this bot, if they did not exist before, will be the ones present in the OpenMetadata configuration. Otherwise, a JWT Token will be generated to be the default authentication mechanism of the ingestion-bot. 2. JWT Token auth mechanism If you decide to configure a JWT Token for the authentication mechanism ensure that you have also the value http://localhost:8585/api/v1/system/config/jwks in your publicKeyUrls list:
  • For bare metal configuration:
  • For docker configuration, the value to be updated is AUTHENTICATION_PUBLIC_KEYS:
  • In the case of kubernetes, you have to update publicKeys values:
3. Redeploying ingestion pipelines After updating ingestion-bot, redeploy the ingestion pipelines because the previous credentials are no longer valid.

​
Automate Bot Management Securely

Use a dedicated functional user account when an automation workflow creates or manages bots through the REST API. Do not use an individual administrator’s Personal Access Token (PAT). The workflow would stop when that person leaves, loses access, or revokes the token.
  1. Create a functional user account for the automation workflow.
  2. Assign only the roles and policies required to create or update bots. Avoid granting the Admin role unless the workflow requires other administrative operations.
  3. Sign in as the functional account and create a PAT.
  4. Store the PAT in a secrets manager and inject it at runtime. Do not commit it to source control, place it directly in a script, or write it to logs.
  5. Set an expiration that matches your credential-rotation process. Rotate the PAT before it expires and revoke it immediately if it might have been exposed.
Requests made with the PAT are recorded as actions by the functional account. This separates automation activity from an individual administrator’s activity, but it does not identify which job or invocation used the shared credential. Use a separate functional account for each automation workflow when you need distinct audit attribution. The PAT has the same permissions as its functional account. Anyone who obtains the token can act with those permissions until the token expires or is revoked. Restrict access to the secret, use the shortest practical lifetime, and monitor the functional account’s activity.