6.2 KiB
| type | stage | group | info |
|---|---|---|---|
| reference, howto | Manage | Access | To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#designated-technical-writers |
Group Managed Accounts (PREMIUM)
CAUTION: Warning: This is a Closed Beta feature.
- Introduced in GitLab 12.1.
- It's deployed behind a feature flag, disabled by default.
When SSO for Groups is being enforced, groups can enable an additional level of protection by enforcing the creation of dedicated user accounts to access the group.
With group-managed accounts enabled, users are required to create a new, dedicated user linked to the group. The notification email address associated with the user is locked to the email address received from the configured identity provider. Without group-managed accounts, users can link their SAML identity with any existing user on the instance.
When this option is enabled:
- All users in the group will be required to log in via the SSO URL associated with the group.
- After the group-managed account has been created, group activity will require the use of this user account.
- Users can't share a project in the group outside the top-level group (also applies to forked projects).
Upon successful authentication, GitLab prompts the user with options, based on the email address received from the configured identity provider:
- To create a unique account with the newly received email address.
- If the received email address matches one of the user's verified GitLab email addresses, the option to convert the existing account to a group-managed account. (Introduced in GitLab 12.9.)
Since use of the group-managed account requires the use of SSO, users of group-managed accounts will lose access to these accounts when they are no longer able to authenticate with the connected identity provider. In the case of an offboarded employee who has been removed from your identity provider:
- The user will be unable to access the group (their credentials will no longer work on the identity provider when prompted to SSO).
- Contributions in the group (e.g. issues, merge requests) will remain intact.
Assertions
When using group-managed accounts, the following user details need to be passed to GitLab as SAML assertions to be able to create a user.
| Field | Supported keys |
|---|---|
| Email (required) | email, mail |
| Full Name | name |
| First Name | first_name, firstname, firstName |
| Last Name | last_name, lastname, lastName |
Feature flag (PREMIUM ONLY)
Currently the group-managed accounts feature is behind a feature flag: group_managed_accounts. The flag is disabled by default.
To activate the feature, ask a GitLab administrator with Rails console access to run:
Feature.enable(:group_managed_accounts)
Project restrictions for Group-managed accounts
Introduced in GitLab 12.9.
Projects within groups with enabled group-managed accounts are not to be shared with:
- Groups outside of the parent group.
- Members who are not users managed by this group.
This restriction also applies to projects forked from or to those groups.
Outer forks restriction for Group-managed accounts
Introduced in GitLab 12.9.
Groups with group-managed accounts can disallow forking of projects to destinations outside the group. To do so, enable the "Prohibit outer forks" option in Settings > SAML SSO. When enabled, projects within the group can only be forked to other destinations within the group (including its subgroups).
Credentials inventory for Group-managed accounts (ULTIMATE)
Introduced in GitLab 12.8.
Owners who manage user accounts in a group can view the following details of personal access tokens and SSH keys:
- Owners
- Scopes
- Usage patterns
To access the Credentials inventory of a group, navigate to {shield} Security & Compliance > Credentials in your group's sidebar.
This feature is similar to the Credentials inventory for self-managed instances.
Limiting lifetime of personal access tokens of users in Group-managed accounts (ULTIMATE)
Introduced in GitLab 12.10.
Users in a group managed account can optionally specify an expiration date for personal access tokens. This expiration date is not a requirement, and can be set to any arbitrary date.
Since personal access tokens are the only token needed for programmatic access to GitLab, organizations with security requirements may want to enforce more protection to require regular rotation of these tokens.
Setting a limit
Only a GitLab administrator or an owner of a Group-managed account can set a limit. Leaving it empty means that the instance level restrictions on the lifetime of personal access tokens will apply.
To set a limit on how long personal access tokens are valid for users in a group managed account:
- Navigate to the {settings} Settings > General page in your group's sidebar.
- Expand the Permissions, LFS, 2FA section.
- Fill in the Maximum allowable lifetime for personal access tokens (days) field.
- Click Save changes.
Once a lifetime for personal access tokens is set, GitLab will:
- Apply the lifetime for new personal access tokens, and require users managed by the group to set an expiration date that is no later than the allowed lifetime.
- After three hours, revoke old tokens with no expiration date or with a lifetime longer than the allowed lifetime. Three hours is given to allow administrators/group owner to change the allowed lifetime, or remove it, before revocation takes place.