Home

Welcome to the EDAMAME integrations wiki.

This wiki documents how to connect EDAMAME's conditional access control to third-party identity, source control, and Zero Trust network providers. Each guide covers the configuration you perform in the provider's own console, the details you then enter in EDAMAME Hub, and how enforcement behaves once the integration is live.

Setup guides

The Hub provider column is the name to select when you click Add Conditional Access in EDAMAME Hub, which does not always match the vendor's current product name.

Provider	Hub provider	Guide
Microsoft Entra ID (formerly Azure AD)	Azure	Setting Up Azure for Access Control Integration
Google Cloud Identity	Google	Setting Up Google for Access Control Integration
GitHub	Github	Setting Up GitHub for Access Control Integration
GitLab	Gitlab	Setting Up Gitlab for Access Control Integration
NetBird	Netbird	Setting Up Netbird for Access Control Integration
Tailscale	Tailscale	Setting Up Tailscale for Access Control Integration
Fortinet FortiGate	Fortigate	Setting Up Fortigate for Access Control Integration
Netskope	Netskope	Setting Up Netskope for Access Control Integration

Building your own integration

If your provider is not listed above, EDAMAME can drive any HTTP or GraphQL API through a JSON configuration:

• Integration principles and architecture — how an integration works, which device identifier to key on, and what a provider's API has to offer before it can be integrated at all. Start here.
• Comprehensive JSON Configuration Guide for IP Allow List Management — the configuration schema reference.

How enforcement differs by provider

The guides are not interchangeable, because providers expose different enforcement primitives. It is worth knowing which model applies before you choose one:

• Allow-list providers — Entra ID, Google Cloud Identity, GitHub, GitLab. EDAMAME maintains a list of the IP addresses of compliant devices, and the provider restricts access to that list.
• Group membership providers — NetBird, FortiGate. EDAMAME maintains the membership of a group you create, and your own policy or firewall rule decides what membership grants.
• Device authorization providers — Tailscale. EDAMAME authorizes and deauthorizes devices directly, across the whole tailnet. Read that guide's prerequisites before enabling it.
• Device tagging providers — Netskope. EDAMAME only applies and removes a tag on compliant devices; your own Netskope policy, keyed on that tag, makes the access decision. Nothing is enforced until you build that policy chain.

Apart from Netskope, EDAMAME replaces the whole list or membership on each update rather than adding entries incrementally, so manual entries you add on the provider side will be removed. Keep manual exceptions in a separate list, group, or rule. Netskope is the exception: it updates one device at a time and preserves tags applied by other tools.

Device-side requirements

The allow-list providers work from the device's public IP address, which EDAMAME already knows, so they need nothing installed beyond the EDAMAME agent itself. The same is true of FortiGate, which matches on the device's MAC address — though the FortiGate itself has to be on a network segment where it observes that MAC directly.

The NetBird, Tailscale and Netskope integrations are the exception. They identify devices by an identity that only exists inside the provider's own client, so those guides add device-side requirements: the provider's client must be installed and connected, and the EDAMAME agent must run with elevated privileges to read the identity out of it.

There is no fallback to the IP or MAC address for these three. EDAMAME does hold both for every device, but neither means anything to a provider that addresses devices by its own identifier, so a device that fails either requirement is not addressable at all. What that costs the device depends on the provider's enforcement model, and it is never nothing:

• NetBird — the device is left out of the group EDAMAME rewrites, so it never receives what membership grants.
• Tailscale — the device is not in the compliant set, and EDAMAME deauthorizes every authorized device that is not. A working device therefore gets kicked off the tailnet, not merely passed over.
• Netskope — the device is never tagged, so under the allow-on-tag policy the guide recommends it is denied.

All three fail towards denial rather than towards access, so a broken agent cannot quietly leave a device authorized. The cost is that the symptom looks identical to a device that never ran the provider's client. If devices are compliant in EDAMAME but never reach the provider, that checklist is the place to start.

Netskope on Linux additionally needs a recent EDAMAME agent: reading the device identifier there was added after the integration shipped. See that guide's prerequisites.

The reasoning behind these differences — why one provider matches on a public IP, another on a MAC address, and another on an identity issued by its own client — is covered in Integration principles and architecture.