Access control#

By default, Lobby accepts API calls from either an Authenticated Player or a Service Account. In some cases, you might want more control over how lobbies are created or joined. In those cases you can use Access Control.

Service Account controlled lobbies#

In the following example, lobbies can only be created and players can only join via a Service Account. This allows you to control the lobby by restricting write access for Players.

Creating project policies via CLI with the following JSON definition will Deny all write access to Lobby service APIs, except the Reconnect, Heartbeat and Tokens endpoints. Note that any API that requires read access (HTTP GETs) will still be accessible.

{
  "statements": [
    {
      "Sid": "DenyLobbyServiceWrite",
      "Resource": "urn:ugs:lobby:/v1/*",
      "Principal": "Player",
      "Action": ["Write"],
      "Effect": "Deny"
    },
    {
      "Sid": "AllowLobbyServiceReconnect",
      "Resource": "urn:ugs:lobby:/v1/*/reconnect",
      "Principal": "Player",
      "Action": ["*"],
      "Effect": "Allow"
    },
    {
      "Sid": "AllowLobbyServiceHeartbeat",
      "Resource": "urn:ugs:lobby:/v1/*/heartbeat",
      "Principal": "Player",
      "Action": ["*"],
      "Effect": "Allow"
    },
    {
      "Sid": "AllowLobbyServiceTokens",
      "Resource": "urn:ugs:lobby:/v1/*/tokens",
      "Principal": "Player",
      "Action": ["*"],
      "Effect": "Allow"
    }
  ]
}

Upsert the policies with ugs access upsert-project-policy -p <project-id> -e <env-name> <file-path>. At this point, any API call that violates the policy will be rejected with a 403 - Forbidden error.