Skip to main content
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.
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.

​
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, select that organisation, and list its Cloud DNS zones:
Set the zone to organisation-only access. With no role filter, every active member of the linked organisation can enter:
To limit access to particular organisation-wide roles, repeat --role:
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 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

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.