User Groups, Roles and Permissions

Garden Cloud features a role-based access control system for managing read/write access to all its resources.

User Groups

A given user is a member of 0 or more user groups. Each group grants the user a set of permissions, which can optionally be scoped to apply only within certain projects or environments. groups.

By default, Garden Cloud is initialized with two user groups: Admins and Developers.

The Admins group has full access to all functionality in the system (for all projects and environments), and cannot be edited or deleted. In addition, Garden Cloud will throw an error when trying to remove the last member from the Admins group. This ensures that there's always someone in your organization who has full access to Garden Cloud.

You can create as many groups as you like.

Let's say we have three projects in an example organization's Garden Cloud setup:

• The app project, which is the primary repo (containing the backend and frontend services for the main application).

  • This is where the core dev team in this example organization does most of their work.

• The website project, for the company website.

  • Most members of the core dev team don't spend much time working here, and occasionally, an outside contractor is brought in to work on the website.

• The infra project, which contains infrastructure / production-related config .

This example organization's engineering team is organized as follows:

• A main dev team that maintains and develops the main application (and occasionally works on the website). They also sometimes create secrets for the website dev team.

• A website dev team that is responsible for the company website (and occasionally brings in temporary, outside contractors).

• An ops team that is responsible for operating the Kubernetes clusters for dev, CI and production, setting up secrets etc.

We could set up the following user groups to represent this team structure:

Main Dev Team

Here, the main dev team group has the admin role in the website project (across all of its environments), and the user role in the dev and staging environments in the app project. This team doesn't have permission to manage users or edit user groups and permissions.

In the How Roles Work section below, we'll cover in more detail what these settings entail.

Website Dev Team

The website dev team group has the user role for all environments in the website project, but has no access to the app or infra projects.

Ops Team

Finally, the ops team has the admin role for all projects. It can also manage projects (which means that members of this group can create and delete projects).

How Groups and Roles Work

A group has global permissions and project-level permissions.

The available global permissions are:

• Manage users & groups: Permission to add and remove users, create and edit user groups, and to add and remove users from user groups.

• Manage projects: Permission to create and delete projects.

Project-level permissions are granted by assigning the Admin or User role to either all projects, specific projects, or specific environments within a given project.

The permissions granted by a role only apply within the selected projects and environments.

The following table lists the permissions granted by each role:

	Admin	User
Create secrets	Yes	No
Update projects	Yes	No
Delete namespaces	Yes	No
Read secrets	Yes	Yes
View projects	Yes	Yes
View/create environments	Yes	Yes
View/create/update namespaces	Yes	Yes
Stream events and log entries	Yes	Yes

A given user has the combined permissions of all the groups they're a member of.