Accounts, security and compliance

Signing in

Members sign in to the studio app with their email address and password, or through your organization's own identity provider once single sign-on is set up. The sign-in screen asks for the email address first and sends people from a verified domain to their identity provider.

Browser sessions are held in HttpOnly cookies and protected against cross-site request forgery.

Multi-factor authentication

Any member can add an authenticator app (TOTP) and recovery codes to their account. Multi-factor authentication is optional by default.

An Owner can require it for the whole organization. Once it is required, members in the Owner, Admin, Operator and Billing roles can still view everything, but every change they try is refused until they enrol.

Remote Desktop and the browser terminal always need a completed second factor, whether or not the organization requires it. See Remote access.

Single sign-on

An Owner can connect the organization to its own identity provider over SAML 2.0 or OpenID Connect.

• Verified domains. Prove you own an email domain by publishing a DNS TXT record. People from a verified domain are sent to your identity provider when they sign in.
• Just-in-time accounts. Optionally, a person from a verified domain who signs in for the first time gets an account with a default role.
• Group mapping. Identity-provider groups can map to the Admin, Operator, Read-Only and Billing roles. The Owner role is never granted through single sign-on.
• Enforcement. An Owner can require single sign-on for everyone, while naming one break-glass Owner who can still sign in with a password if the identity provider is unavailable.

SCIM provisioning

Your identity provider can manage member accounts through SCIM 2.0 with a per-organization bearer token that an Owner issues (issuing a new token replaces the old one).

• Users can be created, updated, deactivated and searched. Groups are not provisioned over SCIM.
• Deactivating a user ends their sessions.
• The last Owner of an organization cannot be removed this way.

Roles

Every member has one of these roles: Owner, Admin, Operator, Read-Only and Billing. What each role can do:

The Owner holds everything, including the organization's identity settings and billing changes. Operators run the fleet (including deploying) but cannot touch billing, identity or members. The Billing role handles billing and does not see your servers.

API keys are limited by their level and scopes, and never by more than the member who owns the key. See Studio API and API keys.

Isolation between studios

Each organization's data is isolated from every other organization's, enforced in the application and again in the database. A request for something that belongs to another organization is answered as not found.

Hardware is never shared: a host belongs to one organization.

DDoS protection

Hosts run on our infrastructure providers' networks, which protect them against distributed denial-of-service attacks at the infrastructure level, with mitigation designed for game traffic, up to 100 Gbps.

Audit log

The audit log records who did what and when, including attempts that were refused. Console commands and every line typed in the browser terminal are recorded with their full text.

It can be read in the studio app and exported as CSV. The role table above shows which roles can read and export it.

When GameGrid support staff need to work inside your organization, their access is time-limited, requires a recorded reason, and its start and end are written to your audit log.

IP allow-lists

Each API key can carry its own IP allow-list, so a key taken from your build system is useless anywhere else. The allow-list applies to API keys; members sign in from wherever they are, protected by their password, second factor or identity provider.

Compliance questions

For data-processing terms, security questionnaires and compliance documentation, contact us.