What Oleria discovers
Once connected, Oleria continuously discovers and maps the following from your Harness account:-
Accounts - every user in the Harness account, with name, email, whether they’re an administrator, their account role, and how they can sign in. Users who hold Account Admin or FME Administrator at the account are marked as administrators. Each user’s account role is the broadest role they hold, and their other roles are listed too.
- Sign-in methods - Harness username and password, LDAP, SAML, each OAuth provider the account allows (such as Google or GitHub), and Harness two-factor authentication. When the account signs in only through SAML or an OAuth provider, users are shown with SSO required, and MFA is left to that provider. When the account allows OAuth providers alongside passwords, users are shown with SSO configured.
- MFA - whether each user has turned on Harness two-factor authentication, and whether the account requires users to enroll.
- Last activity and created date - Harness doesn’t store these on the user, so Oleria derives them from the account’s audit trail. See Known limitations.
- Pending invitations - people who haven’t accepted their invitation are shown as disabled, with the roles and groups they’ll receive when they accept.
- Groups - every user group at the account, organization, and project scopes, with its members. Built-in groups, such as All Account Users, and groups synced from an identity provider are marked as such.
-
Roles - Harness grants a role over a resource group at a scope: the account, an organization, or a project. Oleria shows each of these role bindings as a separate role, for example
Project Admin on Mobile App over All Project Level Resources, along with the users, groups, and service accounts that hold it. The Harness role definitions, both managed and custom, appear as account roles. -
Resources - Split projects, their environments, feature flags, and segments, as a hierarchy. Production environments are labeled, and each feature flag is linked to its owners. Oleria shows which users, groups, service accounts, and role bindings can reach each project and environment, with the exact Split permissions, such as
fme_fmefeatureflag_edit. -
Non-human identities (NHIs):
- Service accounts - at the account, organization, and project scopes, with the roles they hold and the user who created them.
- Service account tokens - linked to their service account, with creation date and expiry.
- Personal access tokens - linked to the user who owns them, with creation date and expiry. A personal access token acts with its user’s access.
- Activity - the Harness audit trail, including sign-ins, user and group changes, role assignments, service account and token changes, and settings changes, with the user or service account that made each change and the object it changed.
Oleria doesn’t import feature flag definitions, targeting rules, treatments, experiments, metrics, or SDK traffic.
Prerequisites
- A Split account on Harness, on any plan, including the Free plan. Custom roles, custom resource groups, and SAML or LDAP sign-in appear only on plans that offer them.
- A Harness account administrator, to create the service account, its role binding, and its token.
- Admin access to the Oleria workspace.
Use a service account token, not a personal access token. A service account token keeps working when people leave, and its access doesn’t change with a person’s roles. Legacy Split admin API keys aren’t supported, because Split accounts on Harness are managed with Harness API tokens.
Permissions
A Harness token has exactly the access of the roles its service account holds. For discovery, give the service account the Account Viewer role over the All Resources Including Child Scopes resource group at the account. Account Viewer includes every permission Oleria reads:
When you connect, Oleria checks that the token can read users, groups, roles, resource groups, and service accounts at the account, and checks them again in one project along with Split environments and feature flags. It names any permission that’s missing. A token whose role covers only All Account Level Resources fails this check, because it can’t read anything inside projects. Without
core_audit_view or core_authsetting_view, the connection still works, and Oleria leaves activity, last activity, or sign-in requirements empty.
To let Oleria take remediation actions, also give the service account the Account Admin role over All Resources Including Child Scopes. On plans with custom roles, you can instead create a custom role with only the permissions each action needs. See Remediation actions.
Set up access in Harness
1
Create the service account
Sign in to Harness as an account administrator. Select Account Settings -> Access Control -> Service Accounts, and select New Service Account. Enter a name such as
oleria and a description, and save it. Create it at the account scope so it can read every organization and project.2
Add the role binding
On the service account, select Manage Role Bindings and add the Account Viewer role with the All Resources Including Child Scopes resource group. If you’ll run remediation actions, also add Account Admin with the same resource group. Then apply the changes.
3
Create the API key and token
On the service account’s page, select API Key and create a key named
Oleria. Under that key, select Token, enter a name, and choose an expiry that fits your rotation policy. Generate the token and copy it right away. Harness shows it only once.4
Note your Harness host
If your Harness account is on a dedicated cluster, note the host you sign in to, for example
app3.harness.io. For most accounts, the host is app.harness.io and you can leave it empty in Oleria.The Harness interface changes over time. If these steps don’t match what you see, refer to Harness’s service account and API key documentation.
Connect Split to Oleria
1
Open the integration
Sign in to your Oleria workspace, navigate to Integrations, and select Split.
2
Complete the connection form
Fill in the connection form:
3
Authenticate
Select Authenticate. Oleria reads the Harness account from the token, checks that the token has the permissions in Permissions, and then saves the integration. The integration is named after your Harness account.
Edit the connection
You can replace the API Token of an existing integration, for example when you rotate it. Leave the field empty to keep the stored token. To connect a different Harness account, add a new integration.Verify the integration
Confirm the Split integration appears on the Connected tab of your Oleria Integrations page with a status of Healthy. After the first sync completes, check that users, groups, role bindings, Split projects and environments, and NHIs appear in your Oleria workspace, and that your account administrators are marked as administrators.When the token expires or is deleted, discovery stops. Harness deletes expired tokens. Generate a new token on the same service account and enter it by editing the integration.
Remediation actions
Oleria runs actions with the integration’s token. Before an action runs, Oleria checks that the token’s service account, or for a personal access token its user, holds the permissions the action needs at the account and at each organization or project the action changes, and names any that are missing.
Each action needs these permissions:
Oleria refuses these actions and sends no change to Harness:
- Any action on the integration’s own service account, its tokens, or, for a personal access token, its own user.
- Deleting the account’s only user who holds Account Admin directly.
- Changing the members of a built-in group, such as All Account Users, whose members follow the scope’s membership, or of a group synced from an identity provider. Make that change in the identity provider instead.
- Revoke access to resource when the access also comes from a binding at the organization or account, from a group, or, for an environment, from a binding that also covers the rest of the project, other environments, or other kinds of resources. Removing those would take away much more than the one resource, so Oleria names the bindings and groups involved instead.
- Revoke access to resource on a project when a binding at that project also grants permissions outside Split, such as the built-in Project Admin or Project Viewer role over all project resources. Use Remove user from role to remove that binding.
- Running Delete user on a service account. Use Disable NHI accounts instead.
- Disabling a personal access token. Harness lets only the user who owns a personal access token delete it.
- If the target is already in the requested state, the action succeeds without making a change, and there’s nothing to revert.
- Delete user is the way to cut off a user’s access. Harness can’t disable or suspend a user, or end their sessions.
Known limitations
- No user disable, enable, or session revoke. Harness has no API to suspend a user or end their sessions. Turning a user off through SCIM removes them from the account. Use Delete user to remove access.
- No password-change data. Harness doesn’t report when a user last changed their password.
- Last activity and created dates come from the audit trail. Harness doesn’t store a last sign-in, created date, or creator on users, or a creator on service accounts and tokens. Oleria derives them from the last 90 days of the audit trail, so older events don’t count. A user’s created date is when they joined the account, not when they were added to an organization or project.
- No token last-used date. Audit records name the user or service account that acted, not the token it used.
- Split object changes aren’t in the activity. Changes to feature flag targeting, kills, and segments appear only in the Split audit log page and its outgoing webhooks, not in the Harness audit trail that Oleria reads.
- SDK API keys aren’t inventoried. Harness has no API to list Split SDK API keys.
- Expired tokens don’t appear. Harness deletes a token when it expires.
- Some objects depend on the plan. Custom roles, custom resource groups, and SAML or LDAP sign-in need a Harness plan that offers them. On other plans they don’t appear.
- Users overlap with the Harness integration. A Split integration covers every user in the Harness account, because Harness roles grant access to Split. If you also connect the Harness integration, the same people appear in both.
- Legacy Split accounts aren’t supported. Accounts that haven’t moved to Harness use Split admin API keys, which this integration doesn’t accept.
- Some behavior isn’t confirmed on a live account yet. SAML and LDAP sign-in, required two-factor authentication, custom roles and resource groups, and Revoke access to resource for a group have been tested against Harness’s API documentation, not a live account. If something doesn’t match what this page describes, contact us.