How memberships work

A membership gives one user a role in one project. A user has no access to a project until they have a membership in it, but a platform administrator has access to every project without one.

Several users and projects#

A user can be a member of many projects and have a different role in each one. In this table, each cell with a role is one membership:

A user has one membership in a project at most, so giving Anna a new role in finance replaces deployer there. weikio get members finance lists the memberships of a project, and weikio describe user anna@example.com lists the memberships of a user. Projects and access shows how to manage them with the weikio CLI, the admin UI and Git.

Roles#

A role is a set of permissions. A platform administrator defines a role once for the whole installation, and you can use it in any project. Weik.io comes with four roles, and each one can do everything the role before it in this list can:

• viewer can see definitions, deployments, status, logs, events and entities.
• editor can also change integrations, kamelets, APIs, API subscriptions and variables. It can set secrets and read their values where the environment allows that, start, stop and invoke what’s deployed, and resend events.
• deployer can also deploy, promote and roll back, and set the entity store’s type policies.
• admin can also add, change and remove the project’s members and read its audit log, as long as the membership covers every environment and the whole project.

A platform administrator can add more roles, and the helpdesk role in the table is an example. Roles and grants lists each role’s permissions as the verbs the CLI and the API use.

The admin role applies only in its project, so Mia can manage the members of logistics and has no access to finance. Platform administrator is a setting on a user, apart from roles.

If your users sign in through an identity provider, claim mappings can create a membership or add more roles to it, and those roles apply only to sessions signed in through that provider.

Limiting a membership#

A membership covers the whole project unless you limit it. You can limit it to some environments and to some integrations and APIs. A membership that lists only integrations covers no APIs, and one that lists only APIs covers no integrations. Ville’s membership could cover only production and two integrations:

$ weikio member add finance ville@example.com --role helpdesk --env production --integrations erp-invoice-export,nightly-payroll

Target: https://hub.example, project finance (argument), user ville@example.com
member finance/ville@example.com created (role helpdesk; environments production; integrations erp-invoice-export, nightly-payroll; revision 4105)

A membership that lists integrations or APIs covers those and nothing else: their definitions, deployments, logs, metrics and traces, and the right to change them. A user who needs an API and the integration behind it is given both by name.

What the project shares, its kamelets and its own variables and secrets, can be seen by every member and is changed only through a membership that lists no integrations and no APIs. A project’s kamelet is changed only through such a membership that also covers every environment.

A limit to environments applies to what’s tied to an environment, such as deployments, logs and the values set for it. An integration’s definition belongs to the project, so an editor limited to production can still change it. Environments and gateways belong to the whole installation, and a member sees those their membership reaches.

Grants and API keys#

A grant is a role in one project with its limits, and a membership is how a user gets one. The CLI and the admin UI use that word too, as in --grant and the Grant project access dialog.

An API key has grants of its own, and they can be less than its owner’s membership gives. A deployer can create a key with the role viewer for the same project. A key never has more rights than its owner’s membership gives at the time of each request, so lowering a user’s role also lowers what their keys can do. Roles from claim mappings don’t count for a key. API keys shows how to create one.

When something is deleted#

What happens to a membership depends on what you delete:

• Deleting a user deletes their memberships and API keys.
• Deleting a project deletes its memberships with everything else in it.
• Deleting a custom role leaves the memberships that use it, and they give nothing through that role. A role created later under the same name is another role.
• The four roles that come with Weik.io can’t be deleted.