Login access policy

Open in ChatGPTOpen in ClaudeAPI referenceTerraform

A login access policy controls who can log in to your Coralogix team, on top of, not in place of, password or SSO authentication. Use it to configure four independent sign-in requirements:

• IP access: only the IPv4 addresses and ranges you list can log in to the team.
• Domain access: only users whose email address uses a listed domain can log in to the team.
• Login policy: enforce SSO login and 2FA for all team members.
• Client access: only the users and groups you list can log in through a given OAuth client.

The IP access, Domain access, and Client access tabs are independent allow lists: while a list is empty, that check allows everyone. Add the first entry to start enforcing it. Each team has its own IP access, domain access, and client access lists.

When to use a login access policy

Three common scenarios:

• Lock the team to corporate networks. Only sessions originating from your office network or VPN reach the team.
• Restrict access to company email domains. Only addresses on the domains you list (for example, acme.com and acme-eng.com) can authenticate, so personal accounts and lookalike domains cannot be added to the team.
• Grant UI access without CLI or agent access. Members keep the web app, and only the groups you choose can sign in through the CLI, an MCP client, or another OAuth client.

The tabs are independent, so you can roll them out one at a time, for example, restrict by email domain first while you collect the IP ranges you want to allow.

Ready to get started?

Open Settings and select Login access policy, then add your first allowed address on the IP access tab.

What you need

• A role with the TEAM-IP-ACCESS:MANAGE permission to manage IP access. The Platform Admin and TeamAdmin roles can manage both IP access and domain access by default.
• A role with the SECURE-LOGIN:MANAGE permission to manage Login policy settings. The Platform Admin role has this permission by default.
• A role with OAUTH-CLIENT:READ to see the Client access tab, and OAUTH-CLIENT:MANAGE to change a login restriction. The Platform Admin role has both by default.
• The IP address or range, the email domain, or the users and groups you want to allow.

IP access

The IP access tab lists the IPv4 addresses and CIDR (Classless Inter-Domain Routing) ranges allowed to log in to the team. While the list is empty, the team allows all connections. Once you add the first entry, the team accepts logins only from a listed address or range.

Add an allowed IP address

1. Open Settings, select Login access policy, and open the IP access tab.
2. Select Add IP address to open the Add allowed IP address dialog.
3. In IP address, enter a single IPv4 address or a CIDR range, for example, 192.168.1.1 or 10.0.0.0/24.
4. (Optional) In Name, enter a label such as the office or network name.
5. Leave Active on to enforce the entry as soon as you add it, or turn it off to add the entry without enforcing it yet. When inactive, the IP address is not enforced.
6. Select Add IP address.

Warning

Adding or activating a range that does not include your current IP address can lock you out of the team. Coralogix warns you before you confirm, and stops you from activating a rule that would cut off your own access.

Manage IP entries

The IP access table shows each entry's IP, Name, and Active state. From the row toolbar you can:

• Deactivate or Activate: stop or resume enforcing an entry without deleting it. You can also flip the per-row toggle in the Active column.
• Delete: remove an entry. Removing the last entry allows connections from everywhere again.
• Download: export the current list as a CSV.

The Coralogix Support Team row controls access for Coralogix Customer Success over its VPN. Turn it off to block that access.

Import IP addresses from a CSV

Select Upload CSV to replace the entire IP allow list from a file.

• Columns: ip_address (required), name, enabled (true or false, controls the Active toggle). Use one entry per row.
• Each value can be a single IPv4 address or a CIDR range.
• Importing replaces all existing entries. Review the preview before you apply it.
• Select Download template to start from the expected format.

Domain access

Limited access

Domain access is currently available to selected teams. Speak to Coralogix Customer Support for access.

The Domain access tab lists the email domains allowed to log in to the team. While the list is empty, the team allows all email domains. Once you add the first domain, only users whose email address uses a listed domain can log in.

The table shows each domain's Domain, Name, Source, Added on, Added By, and Affected users. Domains added through cluster configuration or the API appear as read-only and are tagged accordingly.

Add an allowed domain

1. Open the Domain access tab.
2. Select Add domain.
3. In Domain, enter the domain, for example, acme.com.
4. (Optional) In Name, enter a label such as the company name.
5. Select Add domain.

Warning

Removing the domain that matches your own email address blocks your access to the team. Coralogix warns you before you delete your own domain.

Import domains from a CSV

Select Upload CSV to replace the manually configured domain list from a file.

• Columns: domain (required), name. Use one entry per row.
• Read-only domains from cluster configuration are not affected by the import.

Login policy

The Login policy tab controls authentication requirements for all team members. It has two independent settings: SSO enforcement and 2FA enforcement.

Enforce SSO

When SSO enforcement is on, new members and members who do not have an explicit login method configured must sign in with SSO. Members who already have an explicit login method set are not affected.

SSO enforcement requires an active SAML configuration on the team. See SSO with SAML.

To enable SSO enforcement:

1. Open Settings, select Login access policy, and open the Login policy tab.
2. Turn on Enforce SSO.
3. In the confirmation dialog, select Enforce SSO.

To disable SSO enforcement, turn off the Enforce SSO toggle.

Warning

SSO enforcement applies to all new members and existing members without an explicit login method. Review your team's login methods in Settings > Team members before enabling.

Enforce 2FA for all members

When 2FA enforcement is on, every member of the team must set up two-factor authentication before they can continue using Coralogix. Members who have not yet set up 2FA are temporarily blocked from accessing the team until they complete 2FA setup. 2FA enforcement is account-level: enabling it here requires 2FA across all of the user's Coralogix teams, not just this one.

To enable 2FA enforcement:

1. Open Settings, select Login access policy, and open the Login policy tab.
2. Turn on Enforce 2FA.
3. In the confirmation dialog, select Enforce 2FA.

To disable 2FA enforcement, turn off the Enforce 2FA toggle.

Warning

2FA enforcement applies at next sign-in; active sessions aren't signed out. Members who have not yet set up 2FA will be blocked from accessing the team when they next sign in until they complete setup. Communicate the change to your team before enabling it.

Client access

Coralogix channels such as the CLI, an MCP client, the web app, and embedded views all authenticate through an OAuth client. By default any member of the team can log in through any of them, so granting someone the web app also grants them the CLI. The Client access tab narrows that: for each OAuth client, you choose which users and groups may log in through it.

Early access

The Client access tab is rolling out to selected accounts. If you don't see it under Login access policy, contact us via our in-app chat or by emailing [email protected].

A client restriction is checked at login, when the client asks Coralogix for a token. It controls who may obtain a token through that client, not what they can do once they have one. Permissions still come from the member's roles and groups, so a restriction can never widen someone's access, only stop them from signing in through that particular client.

Open Settings, select Login access policy, and open the Client access tab. The header shows how many of your clients are restricted, for example 2 of 9 clients restricted.

Review the client table

Each row is one OAuth client that members can log in through:

Column	Description
Client name	The client's name. For a client your team created, this is the name entered on the OAuth Clients page.
Type	How a session is obtained through the client. Interaction is an interactive login through a client your team created. Embedded is an iframe session established through the embedded flow. Global is a Coralogix system client shared by every team on the cluster, such as the CLI or an MCP client.
Client ID	The client's identifier. Select it to copy.
Login restriction	No restriction when everyone on the team may use the client, otherwise a count of the allowed users and groups, for example 1 user · 2 groups, with their names.
Last updated	When the client's allow list last changed. A client that has never been restricted shows -.

Global clients are managed by Coralogix rather than by your team, so the table can list clients your members never sign in through. Restricting one only affects logins your own team makes through it, so you can leave the clients you don't recognize alone.

Use the search box to find a client by name or client ID, and the All, Restricted, and Everyone filters to narrow the table to clients that do or don't carry a restriction.

Service-to-service clients don't appear here. They authenticate as a backing API key rather than as a member signing in, so there is no login to restrict. See Service to service client type.

Restrict who can log in through a client

1. Open Settings, select Login access policy, and open the Client access tab.
2. Select the client's row to open the Login restriction drawer.
3. Choose a mode:
   • Everyone on the team: any user with access to the client's allowed teams can log in through it. This is the default.
   • Specific users and groups: only the users and groups on the allow list can log in. Everyone else is denied.
4. For Specific users and groups, open the picker and select the users and groups to allow. Each entry appears on the Allow list below, where you can remove it again.
5. Select Save.

Saving replaces the client's allow list rather than adding to it, and switching a client back to Everyone on the team clears its restriction entirely. A client set to Specific users and groups needs at least one entry before you can save.

Warning

A client restriction applies to you as well. Before you restrict a client you rely on, such as the CLI, confirm that you are on its allow list, either directly or through one of the allowed groups. Check your groups in Settings > Team members.

Who can change a restriction

Viewing the tab requires OAUTH-CLIENT:READ. Changing a restriction requires OAUTH-CLIENT:MANAGE. Without the manage permission the table is read-only: rows don't open, so you can review every client's restriction but not change one.

How the tabs work together

IP access, Domain access, Login policy, and Client access are evaluated independently. For the allow lists: an empty list never blocks anyone. It allows all IP addresses, all email domains, or every member of the team for that check. When more than one list has entries, a user must satisfy all of them to log in: connect from an allowed IP address, use an allowed email domain, and be on the allow list of the client they are signing in through. Login policy settings apply to all members regardless of the allow lists.

Limitations

• IP access supports IPv4 addresses and IPv4 CIDR ranges only. IPv6 is not supported.
• In CIDR notation, host bits must be zero, for example, use 10.0.0.0/24, not 10.0.0.5/24.
• Importing a CSV replaces the entire list for that tab. It is not additive.
• Domains added through cluster configuration are read-only in the UI; you cannot edit or delete them there.
• A domain name can be at most 255 characters.
• Client access restrictions apply per team. A client used by several teams is restricted separately in each of them.
• Service-to-service clients cannot be restricted on the Client access tab. Scope them through their backing API key's permissions instead.
• A client restriction allows or denies login. It does not narrow what a member can do once signed in. To give a client a narrower permission set, create your own OAuth client with the access it needs.

Permissions

Permission	Description
TEAM-IP-ACCESS:MANAGE	Configure and modify the team's IP access list.
TEAM-IP-ACCESS:READCONFIG	View the team's IP access list.
SECURE-LOGIN:MANAGE	Configure SSO enforcement and 2FA enforcement on the Login policy tab.
SECURE-LOGIN:VIEW	View Login policy settings.
OAUTH-CLIENT:MANAGE	Change a client's login restriction on the Client access tab.
OAUTH-CLIENT:READ	View the Client access tab.

API

You can manage IP access programmatically with the IP Access API, which supports bulk creation and CIDR notation. See the IP Access reference.

Related resources

• Login methods
• OAuth Clients
• SSO with SAML
• Two-factor authentication
• Permissions list