Tyk

Tyk is an API management platform from Tyk Technologies. Connect the Tyk Dashboard of a self-managed installation or of Tyk Cloud to Oleria to see who can manage your APIs and what can call them: every Dashboard user and the permissions they hold, user groups, security policies, and the gateway API keys and OAuth clients that act on their own. Oleria reads this data from the Tyk Dashboard API with the API key of a Dashboard user. You can review access to your Tyk organization and take action directly from Oleria.

​

What Oleria discovers

Once connected, Oleria continuously discovers and maps the following from your Tyk organization:

• Accounts - every Dashboard user, with their name, email address, whether they’re active, when they were created, when they last signed in, and when they last changed their password. Developers in the classic developer portal are also imported, with their email address, whether they’re active, when they were created, and when they last signed in. Users with a Dashboard API key also show token authentication. The Dashboard user that Oleria connects as is marked as the integration’s own account.
• Administrators - Dashboard users marked as an admin (IsAdmin), and users outside any user group with no permission restrictions at all, which Tyk treats as admins, are marked as administrators. A user in a user group takes admin from the group: they’re an administrator if they’re marked as an admin themselves, or if their group is an admin group.
• Non-human identities - gateway API keys and OAuth 2.0 clients. Each key shows its alias, whether it’s active, when it was created, last updated, last used, and expires, and the APIs it grants. A key without an alias is named key followed by the start of a hash. Each OAuth client shows its name, client ID, the API it belongs to, its redirect URI, and when it was last used. On Tyk Cloud, Tyk’s own Tyk System Integration User is imported as a system account.
• Credentials - each Dashboard user’s Dashboard API key, each gateway key, each OAuth client secret, and the certificates stored in the Dashboard. Gateway keys are shown as a password for basic-auth keys, a key pair for JWT keys, a certificate for keys bound to a certificate, or an API token. Certificates show their expiry date and fingerprint, and are linked to the keys bound to them. Oleria imports only metadata, such as the type, status, expiry date, and when a key or client secret was last used. It never imports or stores secret values. The Dashboard’s user list includes each user’s Dashboard API key, which Oleria uses only to find its own user, and with key hashing off it uses each gateway key only to build a one-way ID.
• Groups - Dashboard user groups and their members. A Tyk user belongs to at most one group.
• Roles - one role for each Dashboard permission and level that any user or group holds, named like users: read or keys: write, plus an Administrator role. Each user group is a member of the roles its own permissions grant, and of Administrator only when the group is marked as an admin. Each security policy is also a role, described with the APIs it grants and its rate, quota, and key expiry limits. Gateway keys are members of the policies applied to them, and OAuth clients are members of their policy.
• Ownership - a gateway key or OAuth client that names a classic-portal developer is shown as owned by that developer.
• Activity - changes recorded in the Tyk Dashboard audit log, such as users, groups, keys, policies, and OAuth clients being created, updated, or deleted, users’ access being revoked, Dashboard API keys being reset, passwords being reset, and certificates being added or removed. Each event shows the Dashboard user who made the change, the IP address, and the HTTP status. See Activity.

Oleria refreshes this data on its regular sync schedule.

​

Prerequisites

• A Tyk Dashboard, self-managed or on Tyk Cloud, that Oleria can reach over HTTPS from the internet.
• For a self-managed Dashboard, an allowlist entry for its domain. Contact support@oleria.com before you connect. Tyk Cloud hosts under tyk.io don’t need one.
• A Tyk administrator who can create Dashboard users and set their permissions.
• For activity, Tyk Dashboard 5.7 or later with the audit log enabled and stored in the database. See Activity.
• Admin access to the Oleria workspace.

​

Set up a Tyk Dashboard user

The integration needs these Tyk Dashboard permissions. An administrator has all of them. If the user can’t read users or user groups, the sync fails. If it can’t read policies, keys, OAuth clients, certificates, developers, SSO profiles, the audit log, or analytics, Oleria skips that data and syncs the rest.

​

Connect Tyk to Oleria

​

Verify the integration

Confirm the Tyk instance appears on the Connected tab of your Oleria Integrations page with a status of Healthy. The integration’s Capabilities and operation readiness section shows Read users, Read groups, and Read roles, and checks them against your Dashboard user: Read users needs users: read, Read groups needs user_groups: read, and Read roles needs users: read and policies: read. After the first sync completes, you can review the discovered accounts, non-human identities, credentials, groups, and roles in your Oleria workspace.

​

Edit the integration

You can change the Dashboard API key of an existing integration, for example to rotate it. Select Update to validate and save your change.

• To keep the stored key, leave Dashboard API key empty.
• You can’t change the Dashboard URL of an existing integration. To connect another Dashboard, add a new integration.
• The new key must belong to a user in the same Tyk organization. Oleria refuses a key from a different organization.

​

Activity

Oleria imports activity from the Tyk Dashboard audit log. Tyk offers the audit log API on Dashboard 5.7 and later, when the audit log is enabled (audit.enabled) and stored in the database (audit.store_type set to db). The Dashboard user also needs audit_logs: read. If the audit log isn’t enabled or the user can’t read it, Oleria imports no activity and syncs everything else.

• The audit log records Dashboard API requests. Oleria imports only changes (POST, PUT, PATCH, and DELETE requests), so read requests aren’t imported.
• Changes made by the Dashboard user that Oleria connects as, including Oleria’s own remediation actions, aren’t imported. Use a dedicated user for Oleria so that no one else’s changes are hidden.
• Oleria matches each event to a Dashboard user by email address. If no user has that email, for example because the user was deleted or signs in through SSO without a Dashboard user, the event keeps the email address but isn’t linked to an account.
• Requests that Tyk rejected show their HTTP status as an error.
• Changes that Oleria doesn’t recognize, such as changes to API definitions or webhooks, are imported as custom activity.

​

Remediation actions

Oleria can take these actions in Tyk. Each one runs as the Dashboard user whose API key you connected. Keep these limits in mind when you use these actions:

• Before each action, Oleria checks that its Dashboard user has the permissions listed in the permissions table. A write permission counts as read. Oleria skips this check when its user is an administrator, belongs to a user group, or can’t be identified. Tyk doesn’t document whether a user with users: write but without admin can grant permissions it doesn’t hold itself, so we recommend an administrator for actions.
• Oleria reads the user or key before it changes it. If it’s already in the requested state, the action makes no change, and reverting it makes no change either.
• Oleria sends each change once, then reads it again to confirm. If the response is lost and the change doesn’t show when Oleria reads it again, the action fails and reports that the change may have been applied. Check the Dashboard before you run the action again.
• Oleria refuses to change its own Dashboard user, because the change could disconnect the integration. It also refuses to disable, delete, or remove permissions or the group of Tyk Cloud’s Tyk System Integration User.
• Oleria finds its own Dashboard user by matching the API key against the Dashboard’s user list. If it can’t, for example because security.forbid_admin_view_access_token hides other users’ keys, Oleria refuses Disable user accounts, Delete user, Remove user from group, and Remove user from role, because the target could be its own user. Enable user accounts, Add user to role, Add user to group, and Create user still run, but only reverting Create user works. The others’ reverts are refused for the same reason, and reverting Add user to group makes no change and says why.
• A Tyk user belongs to only one group. Add user to group refuses a user who is already in another group, because the change would move them. Remove the user from that group first. Tyk may also apply the group’s permissions to the user, so review the user’s permissions after a group change.
• Tyk treats a user with no permissions as an admin. Oleria refuses any change that would leave a user with no permissions. It also refuses to add a single permission to a user with no permissions of their own: outside a group that would remove their admin access, and for a user in a group, Tyk doesn’t document how a personal permission combines with the group’s. Set that user’s permissions in the Dashboard instead. It also refuses to remove Administrator from a user who is an admin only because they have no permissions, including a user whose user group no longer exists. Oleria reads a user’s admin access the same way in its actions as in the sync.
• Once a user leaves their group, Tyk would treat them as an admin if they have no permissions of their own. So when Remove user from group takes such a user out of their group, Oleria also sets their permissions to {"IsAdmin": "false"}, which grants nothing and isn’t admin. Undoing Add user to group does the same. Tyk doesn’t document whether it keeps that setting. If Tyk shows the user as an admin after the change, Oleria puts the user back in the group with their previous permissions, and the action fails and says so.
• A user holds either read or write on each object. Add user to role refuses to grant one level while the user holds the other on the same object. Remove that role first.
• Security policy roles are held by keys and OAuth clients, not Dashboard users, so you can’t add a user to a policy role or remove them from one.
• Create user needs exactly one user group, and that group can’t be an admin group or have an empty permission map, which Tyk treats as admin. Oleria never creates an administrator. A group made by Create group is accepted, but it grants nothing, so the new user has no Dashboard access until you add permissions to the group. Create user sets the password you give, or a generated one if you choose to generate a password. Oleria never shows or logs the password, including a generated one. If you give no password, the new user signs in through SSO or after an administrator resets their password. If a user with the same email address already exists, the action makes no change.
• Disable NHI accounts applies only to gateway API keys. Oleria can’t disable OAuth clients, because Tyk can only delete them, which also drops their tokens and can’t be undone. It also can’t disable Tyk Cloud’s Tyk System Integration User, which runs Tyk Cloud’s control plane.
• Disable NHI accounts addresses each key by its hash. If key hashing is off and the Dashboard lists a key without a hash, Oleria refuses to disable it, because the key ID would be the secret itself. Tyk must also allow keys to be updated by their hash (enable_update_key_by_hash). If the key isn’t in the first 10,000 pages of the Dashboard’s key list, Oleria can’t find it: disable it in the Dashboard instead.
• Create group creates the group without permissions. Add them in the Dashboard under System Management > User Groups. If a group with the same name already exists, the action makes no change. Reverting deletes the group only while no user is in it. Otherwise the revert makes no change and says why.
• Oleria can’t revoke user sessions in Tyk. Disabling a user already signs them out of the Dashboard.

​

Known limitations

• No MFA. The Tyk Dashboard has no built-in multi-factor authentication, so Oleria shows MFA as not required. MFA enforced by an SSO identity provider in front of the Dashboard isn’t visible to Oleria.
• SSO is never shown as required. Tyk doesn’t record which users sign in through SSO. If the Dashboard has any SSO profiles, Oleria shows SSO as configured for every Dashboard user. Password sign-in stays available alongside SSO, so Oleria never shows SSO as required. SSO shows as unavailable if the user can’t read SSO profiles (idm: read), or if reading them fails for any other reason. The rest of the sync carries on.
• Users who sign in only through SSO. Tyk doesn’t list SSO users who don’t have a registered Dashboard user, so Oleria doesn’t import them.
• Group permissions. Each group is shown as holding the roles its permissions grant, and each user as holding the roles of their own permissions. A group with no permissions isn’t shown as an admin group. A user in a group who has no permissions of their own isn’t shown as an admin, because the group’s permissions apply to them. Tyk doesn’t document this for users with Dashboard accounts. If a user’s group no longer exists, the user is shown by their own permissions, so a user with none is shown as an admin. Tyk doesn’t document whether deleting a group removes its users from it.
• write doesn’t imply read in Oleria. Tyk treats write as including read, but a user with users: write appears only as a member of the users: write role.
• Denied permissions aren’t shown. A permission set to deny, such as owned_analytics: deny, isn’t imported as a role.
• Hidden Dashboard API keys. If security.forbid_admin_view_access_token is set, Oleria can’t see other users’ Dashboard API keys. Oleria then shows a Dashboard API key credential for every user, can’t mark its own user, and imports its own changes as activity. Destructive actions are refused, as described in Remediation actions.
• Keys issued to OAuth clients. Gateway keys that Tyk issued to an OAuth client are tokens of that client. Oleria shows the OAuth client and doesn’t import these keys separately.
• Key listing turned off. If Tyk hashes keys and hashed key listing (enable_hashed_keys_listing) is off, as on Tyk Cloud, the Dashboard can’t list gateway keys. Oleria then imports no gateway keys or their credentials, and syncs the rest.
• OAuth client status. Tyk has no status for an OAuth client, so a client shows as active when its API is active. Oleria doesn’t show when an OAuth client was created.
• Ownership by developers. Oleria links an OAuth client to a developer through the client’s user_id metadata. Tyk doesn’t document what that field means, so confirm in Tyk before you act on it.
• Last-used dates. Oleria reads when each gateway key and OAuth client was last used from Tyk’s analytics, looking back 90 days. It reads up to 5,000 keys and clients per sync, split between keys and OAuth clients, and stops after 45 minutes. Keys and clients with no traffic in that time, keys listed without a hash, keys and clients past the limit, and Dashboard API keys have no last-used date. If the user can’t read analytics (analytics: read), analytics are off, or a lookup fails, Oleria leaves those dates empty and syncs the rest.
• Sign-in activity. Oleria imports Dashboard sign-ins and failed sign-ins if Tyk records them in the audit log. Tyk doesn’t document whether it does. Password changes made by editing a user appear as user updates, and group and permission changes appear as updates to the user.
• No AI agents. Oleria doesn’t collect AI agents in this version. The Dashboard API has no AI agent inventory. Tyk AI Studio is a separate product with its own host, users, and API key, and the Dashboard API key can’t read it. Tyk recommends giving each AI agent its own API key or OAuth client and policy, and those keys and clients appear in Oleria as non-human identities.
• Not connected. The Enterprise Developer Portal has its own host and token, and the Tyk Cloud console has no public API for its users, teams, or organizations, so Oleria doesn’t import them. Oleria doesn’t use the Dashboard Admin API.
• Self-managed and custom domains. Oleria connects to Tyk Cloud hosts under tyk.io. A self-managed Dashboard, or a Tyk Cloud Dashboard on a custom domain, needs an allowlist entry for that domain first. Contact support@oleria.com. Hosts that resolve to private or loopback addresses can’t be connected. Oleria recognizes Tyk Cloud’s Tyk System Integration User only on hosts under tyk.io. On any other host, a user with that name is imported as a person.
• Rate limits. Tyk doesn’t document a Dashboard API rate limit. Oleria paces its requests to each Dashboard, 10 per second by default, and during a sync it waits and retries when the Dashboard reports it’s busy. Actions aren’t retried: if an action reports a rate limit, run it again later.

​

Troubleshooting

​

Contact us

For questions about this integration, contact us at support@oleria.com.