Video Transcript
GitGuardian makes it easy for teams of any
size to manage code security. The platform makes it simple to add secret
detection, IaC scanning, and honeytokens into your defense strategy, no matter how large
to code base or how many developers are involved. We also make it simple to manage access to
the GitGuardian dashboard as your security team grows and you need to assign roles and
permissions. Let's start by understanding the basic roles
users can have in a GitGuardian Workspace. When we say Workspace, we are referring to
the GitGuardian dashboard and all the incidents and tools it contains. There are 4 main roles for workspace members,
The owner The Manager
The member. And Restricted members Let's take a closer look at these roles, starting
with The Owner If you created your GitGuardian account, then
this is likely the role you have. It is the most powerful role, allowing you
to full access to add or remove members, create and manage teams, and manage SSO settings
and even delete the whole workspace. The Manager role is nearly as powerful as
the Owner role, with the big exception that managers can not delete the workspace. This makes it easy to assign trusted team
members full access to invite others, change workspace settings, and for customers on the
Business plan or higher, create and manage API service accounts. The Member role is intended to let individuals
access incidents and act on them accordingly but without the ability to add or remove other
members themselves or modify any workspace settings. The fourth role is the Restricted member role. These are folks who have been invited, generally
temporarily and with very limited access, only able to access specific assigned incidents
on the platform. This is a very safe way to work with developers
who need to be involved to close multiple incidents where they were the author or responsible
for the remediation process. You can find a full matrix view of what actions
each role can take listed in our documentation. You can quickly jump there by searching the
docs for the keyword "role" For larger and more complex organizations,
there is often a need to further group users by project. And some orgs also want to employ finer-grain
access controls for Members, allowing only edit or view options. GitGuardian makes these goals easy to accomplish
as well, thanks to Teams Teams let you group users to work on specific
incidents related to specific repositories. They are also a way to give individual members
fine-grain permissions for handling incidents or granting workspace members specific admin
abilities within the team. By default, each account starts out with an
All Incidents team already created, so let's start there for our explanation. As the name implies, members of this team
can access all the incidents in your GitGuardian workspace. The owner is be default the first member of
this team. All Managers in your workspace are part of
the "All-incidents" team and cannot be withdrawn from it. From there it is up to Owners and Managers
to invite other team members. Workspace members who are outside All-Incidents,
like Members 1 and 6 in this example, will not be able to see this team under their settings
and will need to be invited to it. As we will show in the demo section, they
can be invited to this or other teams at the same time they are invited to your Workspace Once a workspace member accepts the invitation
to join a team, the team managers can then set their permissions at a granular level For Incidents, Member's permissions can be
set to: Full Access, allowing them to edit or share
incidents with other workspace members outside the team
The Can edit setting lets them resolve, ignore or comment on incidents. The most restricted permission level is "Can
View" AS the name suggest team members can see incident details but can not otherwise
interact with the incident. Teams Members can also be granted permission
to administer the team. This is a great way to let team leads get
their work done within the organization without granting them full Manager permissions for
the whole workspace. The "Can manage" settings lets members edit
team settings and add, remove members, and alter their permissions. Of course, the opposite is true as well; the
"Cannot manage" setting removes these abilities GitGuardian allows anyone with Owner or Manager
workspace roles to create custom teams. Custom teams give you a very granular way
to divide the workload between the appropriate team members. In our example, we see the workspace owner
is a member of Team X and Team Y but not part of Team Z. Unlike with the All Incident team, there is
no requirement for Owners and Managers to be part of all custom teams, Just like with All Incident teams, though,
each individual member can have finer-grain permissions granted or revoked. Each team can also customize which monitored
repositories comprise its Permiter. For example, Team X might only care about
one specific project, and Teams Y and Z might be managing the code security of different
but related repositories in a microservices architecture. We really do make it easy to empower your
team to handle incidents at scale. Next, Let's take a look at the dashboard to
walk through how to add or remove workspace members and adjust their roles and then explore
how to leverage teams. Let's start with Workspace member permissions: In the GitGuardian dashboard, click on settings
towards the bottom of the left sidebar menu. Then click on Members in the WorkSsace Settings From here, you can see all the existing team
members, any pending invitations, and at the top, the fields we need to invite
a new user. When inviting them, you can choose to assign
them to any existing teams. If they don't already have an existing GitGuardian
account, they will be invited to create one and then will be able to accept your invitation. In the Members section, you can search for
specific workspace members or filter by role or what teams they are assigned to. Here I am promoting one workspace team member
to manager, and let's demote our existing manager to a member. This will not affect their team membership
nor rights on that particular team. If needed, you can dismiss a workspace user
from here using the trash bin icon on the right side of the screen. If you do so, they will also remove them from
any associated teams. Next, let's move to look at managing teams In the Workspace settings menu, click on Teams From here, you can create a new team by clicking
on the Create team button in the top right of the screen. All you need to get started is a new team
name and optionally, you can provide a description, which we recommend to make it easier for others
to understand why this team exists. Once created, your new team will appear in
the My Teams section. Clicking on it or any other listed team will
take you to the team management screen. Here you can manage your team members, inviting
any Workspace member and assigning them incident and team permissions. In the perimeter section, Team managers can
define the specific repositories they need to focus on,
and all team members can quickly see which repos are in their perimeter. Anyone with the Can manage role can rename
the org or update the description. GitGuardian also provides a full log of the
changes made to the Team And Finally, and dangerously, Anyone with
the Can manage role can delete the team. Back on the top level for Teams settings,
There is a section for Other Teams. Anyone outside of a team can see all the available
teams in a WorkSpace, excluding the special case of the default All-Incidents team. Workspace members can request to join one
of the listed teams, which then prompts the team's managers to accept or deny their request. Thanks for watching and learning about GitGuardian
workspace roles and teams management No matter how large your security team grows,
how many developers you work with, or how many repositories you work to keep safe, GitGuardian
can help make your life a lot easier when it comes to code security and secrets management.