Ability to use smtp:username as a secret
<!--
NOTICE: This Issue tracker is for the GitLab Helm chart, not the GitLab Rails application.
Support: Please do not raise support issues for GitLab.com on this tracker. See https://about.gitlab.com/support/
-->
## Summary
We need to use AWS Access key ID in the smtp user field to connect to an AWS Simple Email Service endpoint.
This is detected by GitLeaks as a Critical Issue.
In 7.3.0 the way to use smtp password was enhanced, but smtp username is not handled as a secret.
https://gitlab.com/gitlab-org/charts/gitlab/-/commit/ca343d8c83bf8483002775a04e9dd5cc4cf9fb39
## Steps to reproduce
Description:
Running Gitleaks leaks in a pipeline detects smtp:user_name as critical vulnerability if you need to use AWS Access key ID (which should be a secret instead)
## Configuration used
(Please provide a _sanitized_ version of the configuration used wrapped in a code block (```yaml))
From values file:
```yaml
smtp:
enabled: true
address: email-smtp.eu-central-1.amazonaws.com
port: 587
user_name: <AWS Access key ID>
password:
secret: gitlab-smtp-password
key: password
domain: "gitlab.xyz.aws.xyz.net"
authentication: login
starttls_auto: true
openssl_verify_mode: peer
pool: false
```
## Current behavior
(What you're experiencing happening)
The AWS Access key ID is detected as a Critical Vulnerability
## Expected behavior
(What you're expecting to happen)
The Gitlab Helm Chart allows smtp:user_name value as a Kubernetes Secret
## Versions
- Chart: (v7.3.0)
- Platform:
- Cloud: ( EKS )
- Self-hosted: (-)
- Kubernetes: (`kubectl version`)
- Client: 1.24
- Server: 1.24
- Helm: (`helm version`)
- Client: -
- Server: -
## Relevant logs
(Please provide any relevant log snippets you have collected, using code blocks (```) to format)
```
AWS Access Token secret has been found in commit
Project:
/ devops / cluster-management
File:
clusters/services-shared/addons/gitlab.yaml:80
Identifiers:
Gitleaks rule ID AWS
Severity:
Critical
Tool:
Secret Detection
Scanner Provider:
Gitleaks
```
issue