Account and platform

Access control

Roles, permissions, and where a grant takes effect.

Access on Plany is a permission checked against a resource. A role is a set of permissions, and you grant a role to a user or a service account on a resource.

The roles Plany ships

Granted on the account, and reaching every project in it.

Role	Can
`roles/account.owner`	Everything, on their own account. Cannot be removed from the account.
`roles/account.admin`	Manage the account, its members and its projects, and run everything in them. Cannot change billing or delete the account.
`roles/account.billing`	Manage payment, credit and plans; read the statement and costs. No access to resources beyond enough project visibility to see where money went.
`roles/account.viewer`	Read-only across the account and its resources. Can also be granted on a single project.

The split between owner, admin and billing is the one that matters in practice: a studio wants its engineers running servers without being able to change the card on file, and its finance person able to do the opposite.

An admin can read the activity record but cannot verify it. Proving the record has not been altered is the owner's to do, because an admin is one of the people it might be evidence about.

Granted on one project.

Role	Can
`roles/project.owner`	Full control of the project, including who has access to it.
`roles/project.editor`	Create and manage resources. Cannot delete the project, change its access, delete a container repository, or read a secret's value.
`roles/project.viewer`	Read-only. Player counts and sessions, but not players' connection addresses.
`roles/microvm.operator`	Start, stop and restart game servers, and read their logs and who is on them. Cannot create or delete servers.

microvm.operator is the role for a community moderator or a support person: they can restart a stuck server — and read its logs to see why it is stuck — without being able to spend money creating new ones or destroy a world by deleting one.

Narrow roles for the things you run, each granted on one resource. Plany grants them to a workload's own identity for you; if you give a workload a service account of your own, you grant them yourself.

Role	Granted on	Can
`roles/secretmanager.accessor`	One secret	Read that secret's value, and nothing else — not even list the project's secrets. See Secrets.
`roles/registry.puller`	One repository	Pull images from it. Cannot push. See Container registry.
`roles/sandbox.invoker`	One sandbox	Call a sandbox that has no public address. Cannot read anything about it.

Plany also uses roles of its own for the game servers and connection handling it runs for you. You do not grant or manage those; ListRoles shows them.

Granting a role

Team & access → choose a member or service account → Grant a role → pick the role and where it applies

Terraform has plany_account_iam_member, plany_project_iam_member, plany_secret_iam_member, plany_registry_repository_iam_member and plany_sandbox_iam_member. Each manages one grant and leaves every other grant on the resource alone.

Where a grant applies

A role granted on a resource applies to that resource and everything beneath it. A role on accounts/acme reaches everything in the account; a role on one secret reaches that secret and nothing else.

Granting a role below the thing somebody needs to reach does nothing, and nothing tells you so — the check simply denies. Grant on the resource itself, or on something above it.

Reading and writing policy

Call	Does
`GetIamPolicy`	The grants on one resource.
`SetIamPolicy`	Replaces them. Pass the `etag` you read, and a change made by somebody else in between is refused rather than overwritten.
`CheckPermissions`	"Could I do this here?" — returns which of the permissions you asked about are allowed, which is what to grey out a button with.
`ListRoles`	The catalogue, with each role's permissions.

Shell

grpcurl -H "authorization: Bearer $PLANY_API_KEY" \
  -d '{"resource": "projects/", "permissions": ["playpute.gameServers.create", "playpute.gameServers.delete"]}' \
  api.plany.cloud:443 plany.iam.v1.IamService/CheckPermissions

When a change takes effect

Change	Takes effect
Granting or removing a role	Within about 30 seconds.
Disabling or revoking an API key	Within about a minute.
A token already issued	Not until it expires — an hour by default.

Revoking a credential does not end tokens already issued from it. To cut access immediately, revoke the credential and call RevokeToken with its name. See Authentication.

Everything fails closed

When a question about access cannot be answered, the answer is never "allow". You may see an UNAVAILABLE worth retrying; you will not see something let through because a check could not run.