Skip to main content
New Relic is an observability platform for monitoring applications and infrastructure. Connect your New Relic organization to Oleria to see every user with their user type and sign-in policy, the groups and roles that grant access to your New Relic accounts, and the API keys and system identities that can act on them. Oleria connects with a New Relic User API key. Oleria reads access to your organization and its accounts. It doesn’t model apps, dashboards, or other New Relic entities, or roles granted on a single entity.

​
What Oleria discovers

Once connected, Oleria continuously discovers and maps the following from your New Relic organization:
  • Accounts - every user in every authentication domain, with their user type, last activity where New Relic records it, and the MFA and SSO policy of their authentication domain. Users who were added but haven’t verified their email appear as disabled. Users who hold the Organization Manager or Authentication Domain Manager role are marked as administrators. Oleria takes each user’s creation date from the audit log.
  • Non-human identities - user API keys, ingest keys (license and browser keys), and system identities. Disabled keys are included. Each API key is paired with a credential that shows its status, creation date, and last rotation, which is its creation date because New Relic keys are replaced, not re-keyed. User API keys are linked to the user who owns them, because a user key acts with its user’s access, and show when they were last used. System identities show their creation date from the audit log.
  • Groups - user groups and system identity groups, and their members. The built-in groups are marked as built-in, groups in an authentication domain provisioned by SCIM as synced, and the rest as custom. Custom groups show their creation date from the audit log.
  • Roles - the user types (Full platform, Core, and Basic) and every standard and custom role in your organization, with the users, groups, system identities, and system identity groups that hold each one. Each grant shows its scope: organization, account, or group.
  • Resources - your New Relic accounts and their parent accounts, and who can reach each account through account-scoped role grants.
  • Activity - events from the New Relic audit log (NrAuditEvent) in each account, such as sign-ins and changes to users, groups, user types, system identities, and API keys. Each event reads as a sentence, such as “admin@example.com updated group Admin”. Events on a key link to the New Relic account it belongs to. When an API key performed the action, Oleria shows the key as the actor, acting for the user who owns it.
Oleria refreshes this data on its regular sync schedule.

​
Prerequisites

  • A New Relic user with the Core or Full platform user type who holds the Authentication Domain Manager role, for example a member of the built-in Admin group. Basic users can’t create a User API key.
  • The data center region your New Relic organization is hosted in: US, EU, or JP.
  • Admin access to the Oleria workspace.
Each Oleria integration covers one New Relic organization.

​
Create a User API key in New Relic

1

Create a User key

Sign in to New Relic as the user described in the prerequisites. Open the user menu, select API keys, and create a key of type User.The key acts with its user’s user type and roles, so Oleria sees what that user can see. To disable API keys from Oleria, use a user who can manage those keys, such as the user who created them.
2

Copy the key

Copy the key before you leave the page. It starts with NRAK-.

​
Connect New Relic to Oleria

1

Open the integration

Go to your Oleria workspace, select Integrations, then select the New Relic tile.
2

Complete the connection form

3

Authenticate

Select Authenticate. Oleria checks the key with New Relic and that its user holds the Authentication Domain Manager role, then saves the integration under your New Relic organization’s name. If the role is missing, Oleria refuses the key and names the role.

​
Verify the integration

Confirm New Relic appears on the Connected tab of your Oleria Integrations page with a status of Healthy. After the first sync completes, you can review the discovered users, groups, roles, and API keys in your Oleria workspace. The integration’s Capabilities tab shows Read users, Read groups, and Read roles with the New Relic permission each one needs, Authentication Domain Manager, and checks them against your key.
If you replace the API key in New Relic, update it in Oleria by editing the integration. Leave User API key (optional) blank to keep the stored key.

​
Remediation actions

Beyond discovery, Oleria can act on New Relic access to remediate risk. Before a user, group, or role action runs, Oleria checks that the connected user holds the Authentication Domain Manager role, through a group or a direct grant, and reports it if it’s missing. Disable NHI supports these non-human identities:
  • User API keys - supported.
  • Ingest keys - supported.
  • System identities - not supported. New Relic system identities have no disabled state. The only change New Relic allows is permanent deletion.
Oleria never disables the API key the connection uses. It won’t remove the connected user from a group, change or remove its user type, or delete it. Users in an authentication domain provisioned by SCIM are managed by your identity provider, so Oleria won’t change their group memberships or user type, or delete them. Make those changes in your identity provider.

​
Known limitations

  • MFA and SSO come from the authentication domain. New Relic doesn’t expose whether a user has enrolled in MFA. Oleria shows the policy of the user’s authentication domain: whether MFA is required for a password domain, or that SSO is required for an SSO domain, where MFA is up to your identity provider.
  • Dormant account detection is partial. New Relic records a user’s last activity only after they’ve been active, so users who have never been active show no date.
  • No password change date. New Relic doesn’t expose when a user last changed their password.
  • Creation dates come from the audit log. New Relic doesn’t store when a user, group, or system identity was created, so Oleria reads it from the audit log, which New Relic keeps for 13 months. Objects created before then, such as the organization’s first user and the built-in groups, show no creation date.
  • Last use for user keys only. New Relic reports when a user API key was last used, but not ingest keys or system identities.
  • Key creators aren’t shown. Oleria links each user API key to the user who owns it. Who created a key appears only in the audit log. Ingest keys belong to an account, not a user, so they have no owner.
  • System identities have no credential. New Relic doesn’t return a system identity’s client secret.
  • Role permissions aren’t listed. New Relic doesn’t list what each role allows, so Oleria shows the role and the scope of each grant.
  • Some data isn’t inventoried. Apps, dashboards, and other entities, roles granted on a single entity, Teams, and data access policies aren’t listed.
  • Groups are flat. New Relic groups can’t contain other groups.
  • No IP address in activity. New Relic audit events carry no IP address or user agent for the person who acted.
  • Some audit events aren’t classified. An audit event that Oleria doesn’t recognize appears with New Relic’s action name. Group membership changes made through the New Relic API are recorded as group updates.
  • Organization roles, Create group, and Revoke permission to resource need New Relic Pro or Enterprise. Role actions change user types on every plan, and on Pro or Enterprise they also grant and revoke organization-scoped roles. On other plans, New Relic refuses these changes and Oleria reports the missing permission. Grant account-scoped roles through a group in New Relic.
  • New users start as Basic. Change the user type afterwards with Add user to role. Oleria can’t create users in an authentication domain provisioned by SCIM.
  • One organization per integration. Add one integration for each New Relic organization.

​
Existing SCIM connections

If you connected New Relic earlier with the SCIM setup, that connection keeps syncing users, groups, and group memberships without reconnecting. A New Relic SCIM token works only with New Relic’s SCIM API, so until you add a User API key, the connection doesn’t collect roles, accounts, API keys, system identities, or audit activity, and Oleria can’t take remediation actions on it, including Enable user and Disable user, which aren’t available for New Relic because New Relic users have no disabled state. Its Capabilities tab shows Read roles as not supported. To switch, create a User API key as described in Create a User API key in New Relic. Then edit the integration, enter the key in User API key, choose your Region, and select Update. After the update, the connection stops using the SCIM token and reads everything described on this page. What changes after the switch:
  • The first sync gives your New Relic users new IDs, because the New Relic API doesn’t expose SCIM user IDs. Update any access reviews or workflows that reference specific New Relic users.
  • Update any workflows that use Enable user or Disable user. Use Delete user instead.
  • Adding and removing group members and creating users work again, now through the User API key. Creating groups, changing user types and organization roles, revoking account access, deleting users, and disabling API keys are new.

​
Contact us

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