Workspace settings

Collaboration and sharing options

Enable public sharing

In the workspace settings, Managers can activate or deactivate public sharing across the entire workspace. Enabling public sharing allows users to access an incident without needing to be registered.
For more details about public sharing, please refer to our Collaboration and sharing section.

Public sharing is available in all plans:

• in the Free plan, both Managers and Members can perform public sharing.
• in the Business plan, only users with Full_access incident permission can perform public sharing.

Public sharing is OFF by default.

Allow team owners to invite users

info

This feature is only available for workspaces with a Business plan.

Enabling this setting allows users with the Member role to invite people to the teams they manage (i.e. where they have the can_manage team permissions). Team owners can only invite new users by adding them to their teams and cannot invite new users to the workspace via the Settings > Members page.
Newly added users will be assigned the Member role. Upon signing up, they will automatically be added to the team from which they were invited.

This setting is ON by default. Deactivate it in your workspace settings if you want the privilege of adding new users to your workspace to remain exclusive to Managers.

“Full access” incident permissions allow to invite users

info

This feature is only available for workspaces with a Business plan.

Enabling this setting allows users with Full access incident permission to invite new users to the workspace. Users with Full access incident permission can only invite new users by granting them access to the incident where they have Full access permission, and cannot invite new users to the workspace via the Settings > Members page.
Upon signup:

• the newly added user will only have access to the incident they have been invited from
• to prevent privilege escalation, the role of the new user will be the same as the person who granted them access to the incident:
  • If granted access by a Restricted user, the new user will have the Restricted role.
  • If granted access by a Member user, the new user will have the Member role.
  • If granted access by a Manager user, the new user will have the Member role since we consider the highly privileged Manager role can only be given specifically on the Settings > Members page.

This setting is ON by default. Deactivate it in your workspace settings if you want the privilege of adding new users to your workspace to remain exclusive to Managers.

Security options

Enforce a maximum lifetime for API personal access tokens

info

This feature is only available for workspaces with a Business plan.

In the workspace settings, Managers can enforce a maximum lifetime for API personal access tokens created within their workspace. This applies whether the creation happens via the API > Personal access tokens page or via ggshield using the ggshield auth login command.

If existing personal access tokens exceed the new maximum lifetime at the time of the setting modification, GitGuardian will force their lifetime to fit the new setting, starting from the time of the setting modification.

By default, there is no enforced maximum lifetime for API personal access tokens.

Restrict git patch visibility

info

This feature is only available for workspaces with a Business plan.

In the workspace settings, Managers can active the restriction for git patch visibility.

When the restriction is activated, the git patch of an occurrence will be visible to a user if either of the following conditions are met:

• The user is a member of a team that includes the repository where the occurrence took place. It's worth noting that since workspace Managers are automatically part of the "All-incidents" team, they will always have access to all the git patches.
• The user is directly involved in the occurrence, meaning their email matches the committer email of the occurrence.

It is important to note that while the restriction on git patch visibility is in effect, the metadata of an occurrence will still be visible to users. Only the git patch of the occurrence will be impacted by the restriction.
This means that there may be instances where a user has access to a secret incident that contains multiple occurrences. The user will be able to view the metadata of all occurrences, but only a subset of them will have visible git patches.

This distinction is critical to ensure an effective remediation when multiple teams are involved and collaboration is necessary. By restricting access to the code (git patch) of each other's occurrences, teams can maintain the necessary level of confidentiality while still working together to resolve the incident.

When the restriction on git patch visibility is enabled, the git patches of occurrences are hidden on the public share page of an incident.

Was this page helpful?