User permissions

Purpose of this guide

This guide is meant to explain how to assign users to roles and teams to achieve the goal of granting the correct level of permissions to the correct projects.

Related Documentation

• User permissions concepts: An introduction to the concepts behind group and team memberships and user roles
• Namespace configuration guide: Guide to using the Infrastructure-as-Code configuration project to configure your namespace
• Configuration schema reference: Reference for the allowed settings for the cg-workshop.yml file

Namespace and subgroup roles

These two files in your Config project will combine to set a Maintainer for the entire namespace, and create a subgroup that has two Developer users and a Reporter.

These permissions flow to all projects contained in the subgroup, so developer.one will have Developer access to any projects in subgroup-a, but no permissions to projects in other subgroups or in the root Namespace.

settings.auto.tfvars

namespace_roles = {
  maintainers = [
    "maintainer.lastname"
  ]
}

cg-workshop.yml

subgroups:
  subgroup-a:
    # other settings omitted
    members:
      developers:
        - developer.one
        - developer.two
      reporters:
        - reporter.one

warning

User permissions flow down the subgroup hierarchy, and can only be increased the further down you go.

For example, a user with Maintainer access to the Namespace can be granted Owner of a subgroup, and they'll have all of the permissions of the owner for that subgroup and any projects in it. However, if they are granted Developer of a subgroup, they will still have Maintainer access, because their Namespace role is applied to the subgroup as well.

tip

An exception to the hierarchical rule of permissions is that subgroup users are given the same level of permission on the config project and file template projects as they have in a subgroup, so that they can submit configuration updates for a Namespace Owner to approve

Creating a team

The following example creates a team that does not grant access to anything other than the config and file templates projects.

cg-workshop.yml

teams:
  operations:
    name: Agency Operations Team
    namespace_role: none
    managed_projects_role: developer
    members:
      - first.member
      - second.member

Granting a team access to subgroups and projects

That team can then be added directly to projects or subgroups by using the group_roles key.

tip

On subgroups, members and group_roles can both be used, and can be useful to grant the team a base access level while increasing permissions for certain users.

cg-workshop.yml

subgroups:
  subgroup-a:
    # other settings omitted
    members:
      developers:
        - developer.one
        - developer.two
      reporters:
        - reporter.one
    group_roles:
      developers:
        - teams/operations

projects:
  cross-team-project:
    # settings omitted
    # project exists in the root Namespace
    group_roles:
      maintainers:
        - teams/operations

warning

group_roles applied to a subgroup also flow down to any subgroups nested within, just like direct memberships.