Add a prefix to deploy tokens

What does this MR do and why?

Add a prefix to deploy tokens

Prefixes Group & Project Deploy Tokens with gldt- following the guidance at https://docs.gitlab.com/ee/development/secure_coding_guidelines.html#token-prefixes.

GitLab applies a prefix to some of its generated secrets. For example, a Personal Access Token begins with glpat-. This MR adds a prefix to Deploy Tokens. It also updates our frontend secret detection which helps prevent users from leaking tokens via Issue / MR comments.

It applies to both Group & Project tokens: GroupDeployToken has_one DeployToken, and the latter is where the plaintext is generated. This change means both types of deploy keys will be prefixed gldt-.

Resolves Add prefix to deploy tokens (#376752 - closed)

Changelog: changed

Note: Deploy Tokens are different to Deploy Keys:

• https://docs.gitlab.com/ee/user/project/deploy_tokens
• https://docs.gitlab.com/ee/user/project/deploy_keys/

See https://gitlab.com/gitlab-com/gl-security/appsec/appsec-team/-/issues/482+ for past & future work on other token types.

Prefix Selection

gldt is not being used anywhere else:

% rg 'gldt'
app/models/deploy_token.rb
12:  DEPLOY_TOKEN_PREFIX = 'gldt-'

Nor at https://gitlab.com/gitlab-org/security-products/analyzers/secrets/-/blob/master/gitleaks.toml?ref_type=heads.

Note that dynatrace secrets are vaguely similar, being prefixed with dt0c01.

Changes

Screenshots or screen recordings

Screenshots are required for UI changes, and strongly recommended for all other merge requests.

Before	After

Note that these secrets are for GDK and I revoked them anyway 👍

How to set up and validate locally

Before

1. Create or find a project
2. Follow the steps at https://docs.gitlab.com/ee/user/project/deploy_tokens/#create-a-deploy-token to create a Group and Project token.
   1. Note the lack of prefix.
3. Clone the project

% git clone https://$TOKEN_USERNAME:$TOKEN@gdk.test:3443/test/private-test.git
Cloning into 'private-test'...
remote: Enumerating objects: 3, done.
remote: Counting objects: 100% (3/3), done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
Receiving objects: 100% (3/3), done.

After

1. Check out the branch
2. Follow the steps at https://docs.gitlab.com/ee/user/project/deploy_tokens/#create-a-deploy-token to create a Group and Project token.
   1. Note that they are now prefixed.
3. Use the new, prefixed, tokens to clone the project
4. Use the old tokens to clone the project (to verify it's not a breaking change)

% git clone https://$TOKEN_USERNAME:$TOKEN@gdk.test:3443/test/private-test.git
Cloning into 'private-test'...
remote: Enumerating objects: 3, done.
remote: Counting objects: 100% (3/3), done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
Receiving objects: 100% (3/3), done.

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• I have evaluated the MR acceptance checklist for this MR.
  • I'll set as DRAFT until I go through the checklist
  • You have considered the technical aspects of this change’s impact on GitLab.com hosted customers and self-managed customers.
    • To reviewers: there should be no impact, as old tokens will continue to work. However after Prefixes OAuth Application Secrets with gloas (!131601 - merged) we discovered that a third party was doing input validation on our tokens and broke, resulting in this discussion: https://gitlab.com/gitlab-com/gl-infra/gitlab-dedicated/team/-/issues/3249+. It may be the case that other third parties expect tokens in the old format, but there's no way to determine this. And we didn't do so for PATs, Trigger Tokens, Feed Tokens, et al.
    • The customer result is that, they are now less likely to leak a token (because our frontend warns about comments containing them) and if they inadvertently leak a Deploy Token they would now be more likely to detect it.
  • You have confirmed that if this MR contains changes to processing or storing of credentials or tokens, authorization, and authentication methods, or other items described in the security review guidelines, you have added the security label and you have @-mentioned @gitlab-com/gl-security/appsec.
  • You have considered using a feature flag for this change because the change may be high risk.
    • We didn't use FF for Trigger Tokens, Feed Tokens, OAuth Tokens, so I think it's fine.

Related to #376752 (closed)