Aller au contenu

Gitlab corp#

Deployment configuration#

Gitlab corp is deployed in the corp zone using an helm chart. The configuration is referenced in env-ng (gitlab) for the corp zone.

Some notable configuration aspects:

  • s3 buckets are created to store gitlab artifacts (created by fe_buckets configuration)
  • a SAML IDP provider is defined to authenticate users with keycloak corp
  • the DB is an FE RDS instance (created by fe_rds and fe_rds_provisioning configurations)

Some implementation details and specific procedures are detailed in the project README such as:

  • backup/restore
  • rebootstrap
  • SMTP check
  • ...

Updates are made like other configurations through envs-ng/trackbone.

Provisioning configuration#

Another configuration is used to make some provisioning: gitlab_provision.

This configuration is in charge of:

  • provisioning users (the source of users is in envs-ng in the file users.cue) and their SSH keys
  • creating project groups
  • assigning roles to users on groups, more on this in the Project group role mapping section
  • setting some application settings

Updates are made like other configurations through envs-ng/trackbone.

Authentication#

The SAML integration allows users to login through keycloak corp. Some role mapping is setup to that some users are granted the admin role in gitlab.

Users are pre-provisioned in advance to have the correct roles on project groups. On the first login of the user with SAML the user is automatically linked to the existing account. Excerpt from gitlab.cue deployment:

// SAML configuration
appConfig: omniauth: {
    autoLinkSamlUser:      true
    blockAutoCreatedUsers: false
}

The blockAutoCreatedUsers is set to false because by default gitlab will block users that authenticate though IDPs.

The SAML group mapping is done in the provider configuration field:

provider: {
    name:             "saml"
    label:            "Keycloak"
    groups_attribute: "roles"
    admin_groups: ["administrator"]
    required_groups: ["developer"]
    ...
}

This configuration tells gitlab that it should look in the roles attribute of the SAML token to find the list of roles of the user. The users must have at least the developer role to connect. Users that have the admin role will be admin on gitlab. For more info see: https://docs.gitlab.com/ee/integration/saml.html#saml-groups

The SAML client for gitlab is created by keycloak-vault-corp configuration. This client has two roles administrator and developer. The client is not full-scope meaning only theses roles can be mapped in the token.

To assign theses roles to users the following setup has been made:

  • in the keycloak-caascad-users configuration we add the client roles in the realm roles corp-gitlab-developer and corp-gitlab-administrator
  • the corp-gitlab-developer realm role is set on the corp-power-user group
  • the corp-gitlab-administrator realm role is set on the corp-administrator group
  • users are assigned to corp-administrator or corp-power-user groups in users.cue

In summary, a user that is part of the corp-administrator group will have the administrator role in the gitlab client. A user that is part of the corp-power-user group will have the developer role the gitlab client.

Project group role mapping#

To define the role of users on projects we define the different project groups (and subgroups) in the gitlab_provision configuration.

This allows to define upfront what will be the roles of users in the projects that will be created in theses groups. We don't want to manage roles per repo.

Currently we support the roles of owner and developer. The setup is done only on the caascad group as we don't need specific permissions in subgroups. The permissions will trickle down to all subgroups and projects.

Excerpt from gitlab_provision.cue:

groups: {
    caascad: {
        description: "Caascad project artifacts"
        owners: [
            for username, user in Users
            if list.Contains(user.groups, "corp-administrator") {username},
            "ci-infra-prd",
            "ci-infra-stg",
        ]
        developers: [
            for username, user in Users
            if !list.Contains(user.groups, "corp-administrator") {username},
        ]
    }
    ...
}

In the example above we setup the user mapping based on their group in keycloak corp.

  • users that are part of the corp-administrator group will be given the owner role on the caascad group. These users are also gitlab admins because of SAML role mapping.
  • other users will be given the developer role on the caascad group