Projects and access

A project is a group of related integrations and APIs and the people allowed to work on them, such as finance or hr. Environments, such as devtest and production, are defined once for the whole platform, and every project deploys into them. Access is given per project: a member has a role in the project, and the grant can be narrowed to some environments and to single integrations or APIs.

Create a project#

A platform administrator creates projects:

$ weikio project create finance --display-name "Finance" --label team=finance

Target: https://hub.example
project finance created (revision 4102)

Creating a project also creates its own store for the built versions of its integrations, 1 GiB unless --store-bytes gives another size. The project is the boundary of what an agent reaches without the backend in between, so a site serving one project can’t read another project’s code or jars. weikio describe project finance shows the project with its ID, its store, its integrations and its members.

A rename with weikio rename project finance finance-ops keeps the project’s ID and everything in it. Deleting a project deletes everything in it in every environment, and the command asks you to type the project’s name first.

Create the environments#

Environments are platform-wide and created once by a platform administrator, usually as kind: environment documents in Git:

$ weikio apply -f platform/environments.yaml

Target: https://hub.example
environment devtest created
environment production created

$ weikio get environments

NAME         ORDER   PRODUCTION   EVENTS BUDGET   ENTITY EVENTS   ENTITY STORE   GATEWAYS                      AGENTS
devtest      1       no           2 GiB           1 GiB           512 MiB        devtest (default)             2/2 online
production   2       yes          8 GiB           4 GiB           2 GiB          internal (default), partner   1/2 online

An environment marked as production needs --env on every command that changes it, and it can refuse to reveal secrets. Environments and promotion shows how a version moves from one to the next.

Give a person access#

weikio member add grants a role on a project to a person, given by e-mail:

$ weikio member add finance anna@example.com --role deployer --env devtest,production

Target: https://hub.example, project finance (argument), user anna@example.com
member finance/anna@example.com created (role deployer; environments devtest, production; revision 4104)

A grant can be as narrow as one integration. Here a helpdesk person sees two integrations in production and nothing else:

$ 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 grant without --env covers every environment, and without --integrations and --apis the whole project. On an existing member, member add replaces the role and every limit with what the command gives, so give every limit the member keeps. weikio get members finance lists the members, and weikio member remove finance ville@example.com removes a person from the project at their next request.

What a grant covers#

One rule decides what a grant covers, everywhere:

• A grant that lists no integrations and no APIs covers the whole project.
• A grant that lists some covers exactly those and nothing else: their definitions, deployments, logs, metrics and traces, and the right to change them. Someone 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 grant that lists nothing. A project’s kamelet is changed only through such a grant that also covers every environment.

A person who signs in with no grant sees a page saying they have no access yet and to ask their administrator, and Settings › Users filters the users with no membership.

In the admin UI#

Settings › Access › Project access lists who has which role in which project, one grant per row, to a platform administrator and to a project’s own admins. The Grant project access dialog sets the project, the role, the environments, the integrations and APIs and the reason, and shows the weikio member add line that does the same.

/settings/projects/finance/members

In Git#

Roles and members are documents too, so access is reviewed in a pull request like any other change:

apiVersion: weik.io/v1
kind: role
metadata: { name: helpdesk }
spec: { verbs: [read] }
---
apiVersion: weik.io/v1
kind: member
metadata: { name: anna@example.com, project: finance }
spec:
  role: helpdesk
  environments: [production]
  integrations: [erp-invoice-export, nightly-payroll]

$ weikio apply -f platform/access/finance-helpdesk.yaml

Roles and grants lists the roles that ship and the verbs a custom role is made of.