Skip to main content
Every compute endpoint checks one IAM action before it does anything, with one exception noted below.
The API reference shows the action on each endpoint’s own page, so you do not have to come back here to look one up. Both come from the same place: the authorization call in the service, read at build time.

​
Resources

Named resources can be addressed readably in a policy. For example, a keypair CRN carries its immutable name:
Instance and pool CRNs carry immutable names. Image CRNs pin name, architecture and version. Platform images and flavors use the platform account handle.

​
The actions

​
Scope collection permissions

Create and list actions check a typed collection CRN with the configured region and requesting account handle. For example, crn:compute:sa-saopaulo-1:my-account:instance/* grants instance creation and listing in that region and account; a policy naming another region or account does not. Flavors are a region-global catalog: compute:ListFlavors checks crn:compute:<region>:platform:flavor/* using the platform account handle. Image listing and creation check crn:compute:<region>:<account>:image/* using the requesting account, including the platform account for compute:CreateImage. Listing can return platform images with platform in their object CRNs; those object CRNs are distinct from the collection used to authorize the request. Existing grants with "resources": ["*"] still work. Typed resource patterns in deny statements now match these collection actions too, and an explicit deny takes precedence over an allow. This policy allows launching and listing instances in one account and region. Its separate statement limits operations on existing instances by tag:
Create actions expose submitted tags as basalt:RequestTag/<key>. Keep basalt:ResourceTag/<key> conditions on existing-resource operations: the instance does not exist yet during creation, and list checks name a collection.

​
Reading is not one action

Three console endpoints require three different actions, deliberately: The third is not a read. It is interactive access to a running machine, and it is the one to withhold from anyone who only needs to diagnose a boot.
Minting a console ticket (POST /v1/instances/{instance_id}/console/ticket) checks no IAM action at all. It requires authentication and org context and nothing else, because the ticket carries identity, not authorization: whether the console may actually open is decided when the socket connects, against compute:StartSerialConsole as policy stands at that moment.Freezing the decision into the ticket would mean a permission revoked in the intervening minute still let the console open. A ticket for an instance you cannot reach is issued and then useless.

​
Sub-resources are governed by their parent

Listing an instance’s NICs or volumes needs compute:GetInstance — there is no separate read action for either. The same pattern covers pools: reading a pool’s floating IPs or its instances needs compute:GetInstancePool, and attaching an address, detaching one or refreshing the pool all need compute:UpdateInstancePool.
That means compute:UpdateInstancePool is one grant covering three quite different things: resizing the pool, rolling every member onto a new template, and attaching a public address to it. There is no way to allow the resize and withhold the roll.

​
An action whose name does not match the call

PATCH /v1/instances/{instance_id}/volumes/{volume_id} changes delete_on_termination — the flag that decides whether a volume survives the instance being deleted. It is authorized by compute:AttachVolume.The audit record for it reads compute:UpdateVolumeAttachment, which is a label rather than an action: no policy can grant it, and searching for it finds nothing.

​
Image ownership limits permissions

All accounts use compute:CreateImage, compute:UpdateImage and compute:DeleteImage, including the platform account. There are no separate CreatePlatformImage, UpdatePlatformImage or DeletePlatformImage actions. Update and delete require the selected account to own the image. Public catalog visibility and wildcard IAM grants do not bypass ownership. A request from a customer account to change a platform image returns 403; another customer’s image returns 404. Select the owning account and grant the ordinary image action on its CRN to manage it. Withdrawn images remain inspectable with the ordinary read actions. An owner can delete one after removing instance and pool references. Deleting images remain readable during cleanup, but mutation requests return 404.

​
Next

Writing policies

Conditions, operators, and how deny is evaluated.

Troubleshooting

What a status means, and why a launch failed.