> ## Documentation Index
> Fetch the complete documentation index at: https://docs.ankra.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Private access for proxied domains

> Require Ankra organisation membership and optional roles for ankra.cc and custom domains proxied by Ankra Cloud.

Ankra Cloud can protect services on generated `ankra.cc` hostnames **and custom domains** with the same organisation identity used in Ankra Platform. Set a domain's Cloud DNS zone to **organisation** access and the relay sends visitors through Platform sign-in, then checks their current organisation membership and allowed role before forwarding a request. Existing public zones stay public until you change their policy.

This applies to hostnames served through the Ankra Cloud proxy. A DNS record that sends traffic directly to an origin does not pass through this gate. A private zone cannot use a direct HTTP route that bypasses the proxy.

<Note>
  The `ankra org access-gateway` commands are merged into the CLI source but await the next tagged CLI release. Check `ankra org access-gateway --help` before following the commands below.
</Note>

## Choose who can enter

First, link the Ankra Cloud account that owns the zone to its Ankra Platform organisation. Sign in to the [Ankra CLI](/integrations/ankra-cli), select that organisation, and list its Cloud DNS zones:

```bash theme={null}
ankra org current
ankra org access-gateway zones
ankra org access-gateway get <zone-id>
```

Set the zone to organisation-only access. With no role filter, every active member of the linked organisation can enter:

```bash theme={null}
ankra org access-gateway set <zone-id> --mode organisation
```

To limit access to particular organisation-wide roles, repeat `--role`:

```bash theme={null}
ankra org access-gateway set <zone-id> --mode organisation --role admin --role operator
```

The built-in role names are `owner`, `admin`, `operator`, `member`, and `viewer`; you can also use a custom role's ID. A member must hold at least one allowed role. The policy applies to the zone's proxied hostnames and is inherited by its subzones. To make the zone public again, run `ankra org access-gateway set <zone-id> --mode public`.

Reading zones and policies requires `members.read`; changing a policy requires `members.manage`. The organisation is taken from the authenticated CLI session, and the Cloud account and zone are checked server-side. You cannot select a different organisation by putting its ID in the policy.

## Use your own identity provider

Members sign in through Ankra Platform. An organisation can configure its own OpenID Connect provider under **Organisation → Settings → Single sign-on** and map provider groups to Ankra roles. The gateway then uses that Platform sign-in and checks current membership and roles; it does not maintain a separate Cloud user list. Follow [Single Sign-On](/guides/single-sign-on) for provider setup, plan requirements, and how to require SSO for the organisation.

A browser visiting a private service is sent to sign-in when needed. Non-browser requests do not start the interactive flow; sign in through the service's browser page first. If membership or the required role is removed, subsequent checks deny access.

## Check readiness

```bash theme={null}
ankra org access-gateway status \
  --platform-cluster <platform-cluster> \
  --relay-cluster <cloud-control-cluster> \
  -o json
```

The status command checks the Platform API and relay deployments, their credential references, and the relay's broker URL through Ankra. It does not reveal credentials, prove that both sides have the same token, or perform a browser sign-in. Read the zone policy with `get` and test the private hostname in a browser before relying on it.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.