Permissions

Actions

Action	Allows
containerinstance/read	See instances, their components, pods, endpoints, revisions, snapshots and schedule
containerinstance/write	Create and change instances and their endpoints, start, stop, restart, re-deploy, roll back, schedule snapshots; includes containerinstance/delete
containerinstance/delete	Delete instances
containerinstance/scale	Set every component's replica count through the scale route (stsh ci scale)
containerinstance/createSnapshot	Take a snapshot
containerinstance/restoreSnapshot	Restore a snapshot in place
containerinstance/deleteSnapshot	Delete a snapshot
containerinstance/readLogs	Read the containers' logs
containerinstance/exec	Open a terminal in a pod
containerinstance/readFiles	List and download files on persistent volumes
containerinstance/writeFiles	Upload, rename, move and delete files on persistent volumes
containerinstance/access	Get through the sign-in of an endpoint with Require sign-in

The last five are data actions: a role grants them only when it lists them as data actions. A terminal and the file actions reach inside the pod, where everything the workload can read is readable, vault secrets included; that is why no reader role has them.

Roles

Role	See	Change, delete	Snapshots	Logs	Terminal	Files	Signed-in access
Reader	Yes	No	No	Yes	No	No	No
Apps Reader	Yes	No	No	No	No	No	No
Apps Operator	Yes	Yes, and scale	No	No	No	No	No
Blueprint Reader	Yes	No	No	Yes	No	No	No
Blueprints Operator	Yes	Yes	No	Yes	Yes	Read and write	No
Contributor	Yes	Yes, and scale	Take	Yes	Yes	Read and write	Yes
Owner	Yes	Yes, and scale	Take, restore, delete	Yes	Yes	Read and write	Yes

Platform Owner and Platform Contributor hold every action in every boundary; Platform Reader can see instances but has none of the data actions.

Caution

The table shows what the platform allows. Apps Operator also holds Kubernetes pods/exec and read access to pods in the resource group's namespace, where container instances run next to apps, so it needs no terminal permission to get a shell: anyone in the role with direct cluster access can kubectl exec into an instance's containers and read what the workload can, the vault secrets in /secrets/env.json included. Such a session bypasses the portal's terminal and its checks.

Signed-in access is what gets a person through an endpoint with Require sign-in. Reader, Blueprint Reader and Blueprints Operator list containerinstance/access among their data actions, but the sign-in check reads only a role's ordinary actions, so it refuses them — see Require sign-in.

Assign roles on the boundary or the resource group — see Role assignments.

Important

Two tasks need more than the table shows:

• Changing an instance that uses vault secrets. Every save of such an instance — on the Components or Endpoints tab, through the CLI or the API, and a rollback — grants its identity Secrets Reader on each vault it references again, with your permissions. That grant needs the Owner role, so Contributor, Apps Operator and Blueprints Operator cannot save changes to it. Start, stop, restart, re-deploy and stsh ci scale do not make the grant.
• Logs and terminal. They need the role assigned on the boundary; see View logs and open a terminal.

What else a task needs

Task	Also needs
Create or change an instance that pulls from a private registry	kernel/deployments/read on the boundary
Create or change an instance whose variables reference vault secrets	The Owner role on each referenced vault, its resource group or the boundary — assigned to you directly or activated through just-in-time access; Owner held through a group does not count — so that the instance's identity can be given Secrets Reader
Read the live log stream	kernel/crates/readLogs on the boundary
Open a terminal	kernel/crates/exec on the boundary
Delete an instance deployed from a blueprint	secretvault/delete on its vault