Composite Identity onboarding and offboarding flow

Problem

Currently, there is no "onboarding flow" for Duo Workflow. An user has a feature flag enabled, and that is enough. We might also be checking that the instance is gitlab.com, because SM instances are not yet supported.

With the addition of composite identity for remote execution, we need to think about when the service account is created. Composite Identity uses a service account as the "primary user". We are going to use a single service account for the whole instance, both on gitlab.com and for self-managed instances.

Rather than creating this service account when the first workflow is generated, an instance admin should go through some type of setup flow that creates the service account and persists its id in the database so that we know which service account to use. Note that there is currently no UI for creating service accounts (API only)

Attributes of a service account that can be customized:

• username
  • When a service account is created, the default username is something like service_account_1231e32efr324. As a result, we probably want to customize this and/or allow the customer to customize it. We had a thread about this topic for the Amazon Q composite identity service account here.
• avatar
• name
• private_profile (defaults to false, I recommend making it true here)
• composite_identity_enforced (needs to be true)

Desired Outcome

We have an easy setup for admins that allows the enable Duo Workflow for their instance and creates the needed service account

Proposed solution

• Add a button to "Enable Duo Workflow"
• Turning the checkbox on, creates the Service Account and makes other needed changes to set it up correctly
• The service account should be created with a default username, avatar, name, and and both private_profile and composited_identity_enforced set to true.
• After enabling there should be a button to "Disable Duo Workflow", which would block the service account and do any other actions to make sure it can no longer be used for Duo Workflow to get access
• The service account should be automatically added to any group, the first time a workflow is run there (same behavior as with Amazon Q integration)
• There should be a disclaimer for that behavior.

Out of scope: Choosing a custom username, avatar or name for the service account is not part of this issue, and can be explored separately in the future.

Further Information: For Q, going through the setup flow also sets a boolean attribute (amazon_q_ready) to true. We may want to consider something similar for Duo Workflow, although it would be good to consult with groupcustom models on this since they are owners of AI settings and this would be introducing a new granular settings pattern.

Proposed Design

• Add GitLab Duo Settings for the instance level on .com.
• Within these settings, add a box for turning GitLab Duo on and Off.

Default: Workflow Off	Workflow On	"Are you sure" Modal	Off Confirmation

Full UX Flow ✨

Figma File ✨