Roles, permission groups and access

The three layers that decide what each member may do, the groups every organization starts with, and the rules that stop anyone climbing.

Everyone in an organization has one role. On top of it they can be put in permission groups, which add organization-wide permissions, and be granted access to individual resources. What a member may do is everything the three give them together.

Nothing in any layer ever takes a permission away. Denial is the absence of a grant, which keeps "why can they do this?" answerable by looking at the member's role, their groups, and the grants that name them.

Layer 1: organization roles

Three roles, deliberately coarse.

A developer may create applications, networks, vaults, image namespaces, databases, database instances, managed services and solutions; connect their own GitHub or GitLab account; use the coding agent and create studio projects; and see who else is in the organization. They see only what they created and what they were given. A colleague's application does not appear in their list and does not answer to its name.

The person who creates a resource holds everything on it, whatever their role.

What only the owner can do

Two permissions belong to the owner alone:

• Appointing and removing administrators. An administrator who could appoint administrators could never be demoted.
• Editing the organization's legal details: the company name, registration numbers and address that invoices and contracts are made out to.

These cannot be put in a permission group or handed to a CLI credential, by anyone, including the owner.

Layer 2: permission groups

Roles are coarse on purpose, and most teams need something in between: someone who deploys but does not delete, someone who looks after the databases, someone who runs the shop. A permission group is a named set of organization permissions. Putting a member in it adds those permissions to their role.

Groups inherit. A group can name other groups as parents, and its members hold everything the parents hold, transitively. Widening a parent widens every group built on it. A group cannot inherit from itself, even through others.

The built-in groups

Every organization starts with these. They are defined by the platform: you can put members in them and build your own groups on top of them, but you cannot change or delete them. A platform upgrade that adds a permission to one reaches every organization at once.

The application permissions are slices of one another:

isogrid iam permissions lists every permission with a one-line description, and isogrid iam groups get <group> shows exactly what a group holds once inheritance is counted. See Repositories, groups and access.

Layer 3: access to one resource

A grant gives one member, or one group, a set of capabilities on one resource: one application, one database, one vault, one repository. It is how a developer gets into something they did not create, and how an outsider gets into exactly one thing.

Capabilities are specific. On an application, for example:

Every other kind of resource has its own set in the same shape: view, the things you can do with it, share, and delete.

Presets bundle the common cases, so most grants are one choice:

A preset is expanded when the grant is written. The grant itself is a plain set of capabilities, so you can start from a preset and remove one thing.

A grant covers the resource, not a copy of it. Granting on an application covers its service, its builds and its volumes. Granting on a repository covers every application built from it, including ones created later.

Grants are made from the resource's sharing settings in the console, or for repositories with isogrid repos grant.

You can only hand out what you hold

This is the rule that makes it safe to let people other than the owner manage access. It applies everywhere:

• Creating or changing a group. You cannot give a group a permission you do not hold, or make it inherit from a group that holds more than you.
• Putting someone in a group. You cannot add a member to a group that holds a permission you do not.
• Granting on a resource. You need that resource's share capability, and you can grant only capabilities you hold on it yourself. Someone who can deploy an application cannot give anyone the right to delete it.
• Revoking a grant. You can withdraw only a grant that gives no more than you hold. A grant made by someone with more access stays until someone with that much removes it.

Managing groups also needs the iam:manage permission, which owners and administrators hold and iam-administrators adds. So an IAM administrator who may manage members but not billing cannot build a "Billing" group and join it.

CLI credentials

A credential made with isogrid login acts as you, in one organization, and is limited in three ways:

It never holds more than you do. Its scopes are a ceiling, checked against your role and groups on every request rather than copied when it was issued. Take someone out of a group, or demote them, and every credential they minted narrows at the same moment.

It holds only what was left ticked on the approval page. member:manage, iam:manage, organization:manage and network:share are offered but not ticked by default, because their effects land on other people.

Some things it can never do, whatever it asks for and whoever approves it: read or change billing, appoint administrators, edit the organization's legal details, or mint and revoke credentials. Those want a person at a keyboard.

Scopes narrow organization permissions. Access that comes from a grant on a resource, or from having created it, is not affected by them, so a narrow credential still reaches what you were invited to. isogrid whoami prints what a credential will actually be allowed; that is the list to read when something is refused. See Deploying from CI/CD for minting one for a pipeline.

Examples

Let the QA team deploy, but not delete

Create a group qa and put the testers in it. What to give it depends on how widely they work:

• Every application: make qa inherit from deployers. They can create applications and deploy, start and stop all of them, and change and delete none.
• Only the staging applications: leave the group with no permissions, and grant it the operator preset on each staging application. They can deploy, start, stop and read logs there, and see nothing else.

isogrid iam groups create --name QA --inherits deployers
isogrid iam groups add-member qa tester@acme.example

When someone joins QA, adding them to the group is the whole of onboarding. When they leave it, they lose everything the group gave them at once.

Hand one solution to a marketing agency

The agency's contact needs to run the shop and nothing else.

1. Invite them to the organization as a developer. On their own, they see nothing they did not create.
2. On the shop solution, grant them the solution-operator preset: they can see it, read its connection details and admin login, and start, stop and redeploy it. Choose solution-manager if they should also change its settings; neither preset lets them delete it.
3. When the engagement ends, revoke the grant or remove them from the organization.

They never see your applications, databases or bill, and cannot pass the shop on to anyone else, because neither preset includes sol:share.

Give a contractor one repository

See Git repositories: the member who connected the repository grants the contractor repo-deployer on it, and the contractor can build and deploy the applications made from it without being given each one.

Edge cases worth knowing before you meet them

A member cannot find an application that exists. Holding nothing on a resource looks the same as it not existing, so members cannot discover what colleagues run by guessing names. Grant them access, or put them in a group that sees every application.

"You do not have 'app:deploy' on this application" from someone who can see it. They hold something, so the resource is not hidden, but not that. The error lists what they hold.

An administrator cannot build from a colleague's private repository. Repositories follow their own rules: the member who connected the account decides, and a private repository is closed even to the owner. See Git repositories.

A built-in group cannot be edited. Build your own on top of it with --inherits.

A CLI command is refused that works in the console. The credential was approved with fewer permissions than you hold. isogrid whoami shows which; isogrid login --force approves a wider one.

What to read next

• Git repositories — who may build from what.
• Repositories, groups and access — the same, from the terminal.