Teams and enterprise
Brunel Access
Put your company's own sign-in page in front of your Brunel workspace, in the manner of Cloudflare Access. Identity provider or GitHub, allow and block policies, a policy tester and an audit trail of every decision.
Brunel Access is available on Enterprise. When it is on, every browser session of your team's members, on brunel.cloud and on the console addresses, must pass your gate before anything else, and the gate decides with your rules.
How it works for a member
- The member signs in to Brunel with GitHub, as usual.
- Brunel sends them to your company's access page, with your name and your verification mark:
https://brunel.cloud/access- They continue with a method you allow: your identity provider (Okta, Microsoft Entra ID, Google Workspace or any OIDC provider) and/or their GitHub identity.
- Brunel evaluates your policies with that identity, its address and its country. Allowed: they go back to the page they asked for. Denied: the page says so, and nothing of your workspace is shown.
The access lasts the duration you set (1 to 720 hours), then the member passes the gate again. Every change of your settings asks everyone to pass it again.
Set it up
In Enterprise → Access (https://enterprise.brunel.cloud/team/access):
- Methods. Tick *Identity provider* (configure it first in Single sign-on) and/or *GitHub identity*.
- Duration. How many hours an access lasts.
- Policies. Start from the proposed one (employees of your verified domain) and add your own.
- Test. Use the policy tester, and Test my sign-in with your identity provider.
- Turn Access on and save.
Policies
Policies follow the Cloudflare Access model:
- Block policies are checked first, then Allow policies, in the order you set.
- A policy matches when any of its *Include* rules matches, all of its *Require* rules match, and none of its *Exclude* rules matches.
- Nothing matches: denied.
| Rule | Matches | Example |
|---|---|---|
| Everyone | anyone who reaches the page | |
| Emails | exact addresses from your identity provider | alice@acme.com |
| Email domain | addresses of a domain, from your identity provider | acme.com |
| GitHub users | GitHub logins | octocat |
| GitHub organizations | active members of an organization | acme |
| Identity provider groups | the groups claim of the ID token | engineering |
| IP ranges | IPv4 and IPv6 addresses or CIDR ranges | 203.0.113.0/24 |
| Countries | ISO country codes of the connection | FR, DE |
| Sign-in method | idp or github | idp |
Emails count only when they come from your identity provider, which is trusted for its own addresses unless it sends email_verified: false. GitHub identities have no email in Brunel Access: use GitHub users or organizations for them.
Examples
| Goal | Policy |
|---|---|
| Employees only, through the identity provider | Allow · Include *Email domain* acme.com · Require *Sign-in method* idp |
| Engineers from the office or the VPN | Allow · Include *Identity provider groups* engineering · Require *IP ranges* 203.0.113.0/24 |
| Contractors on GitHub, but not from abroad | Allow · Include *GitHub organizations* acme-contractors · Require *Countries* FR |
| Never from some countries | Block · Include *Countries* KP, IR |
| Exclude one person | Allow policy · Exclude *Emails* leaver@acme.com |
Policy tester
Describe someone (method, login, email, groups, organizations, address, country) and see what your current policies, saved or not, would decide and which policy decides.
Audit trail
Every decision is written to the audit log as access.granted or access.denied, with the policy that decided, the method, the address and the country. Every change of settings is recorded as access.updated. The last 50 decisions are shown on the Access page.
Under the hood
- The access is kept on Brunel's servers, bound to the member's session: it holds on every Brunel address, ends with the session, and can never be copied to another browser.
- API keys are not affected by Access (your IP allowlist still applies to them). Sign every member out ends sessions and keys at once.
- A new team, or a new member, is recognized by every server within 30 seconds; settings themselves apply at the next request.
- With Require single sign-on in restricted access and Access off, Brunel runs the same gate with your identity provider as the only method and everyone allowed.