Secret and deployment name normalization required when using SCM username in PersonalAccessToken management

[cccs-eric]

Describe the bug

I have seen the following problems when dealing with Gitlab PersonalAccessTokens (PATs), but I can't see why it would not apply to other SCMs.

My corporate gitlab username is <firstname>.<lastname>. This username is causing the following two errors in che-server:

1- Uppercase letters in the username are not valid
My goal was to register a k8s secret as described in the documentation. So here is the YAML for the secret:

apiVersion: v1
kind: Secret
metadata:
  name: gitlab-myuser-access-token-secret
  labels:
    app.kubernetes.io/part-of: che.eclipse.org
    app.kubernetes.io/component: scm-personal-access-token
  annotations:
    che.eclipse.org/expired-after: '-1'
    che.eclipse.org/che-userid: '1e09e618-a40c-4fdd-915f-46d818223fd5'
    che.eclipse.org/scm-userid: '19'
    che.eclipse.org/scm-username: 'First.Last'
    che.eclipse.org/scm-url: 'https://my.gitlab..net'
data:
  token: <redacted>

Notice the uppercase letters in the scm-username annotation. When KubernetesGitCredentialManager tries to create a secret using this username, I get the following error:

Secret "First.Last-git-credentials-secret-2l5wo" is invalid: metadata.name: Invalid value: "First.Last-git-credentials-secret-2l5wo": a DNS-1123 subdomain must consist of lower case alphanumeric characters, '-' or '.', and must start and end with an alphanumeric character (e.g. 'example.com', regex used for validation is '[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*')
        at io.fabric8.kubernetes.client.dsl.base.OperationSupport.requestFailure(OperationSupport.java:568)
        at io.fabric8.kubernetes.client.dsl.base.OperationSupport.assertResponseCode(OperationSupport.java:507)
        at io.fabric8.kubernetes.client.dsl.base.OperationSupport.handleResponse(OperationSupport.java:471)
        at io.fabric8.kubernetes.client.dsl.base.OperationSupport.handleResponse(OperationSupport.java:430)
        at io.fabric8.kubernetes.client.dsl.base.OperationSupport.handleCreate(OperationSupport.java:251)
        at io.fabric8.kubernetes.client.dsl.base.BaseOperation.handleCreate(BaseOperation.java:815)
        at io.fabric8.kubernetes.client.dsl.base.BaseOperation.create(BaseOperation.java:333)
        at io.fabric8.kubernetes.client.dsl.base.BaseOperation.createOrReplace(BaseOperation.java:394)
        at io.fabric8.kubernetes.client.dsl.base.BaseOperation.createOrReplace(BaseOperation.java:391)
        at org.eclipse.che.api.factory.server.scm.kubernetes.KubernetesGitCredentialManager.createOrReplace(KubernetesGitCredentialManager.java:150)
        at org.eclipse.che.api.factory.server.scm.AuthorizingFileContentProvider.fetchContent(AuthorizingFileContentProvider.java:72)
        at org.eclipse.che.api.factory.server.urlfactory.URLFactoryBuilder.createFactoryFromDevfile(URLFactoryBuilder.java:107)
        at org.eclipse.che.api.factory.server.gitlab.GitlabFactoryParametersResolver.createFactory(GitlabFactoryParametersResolver.java:88)
        at org.eclipse.che.api.factory.server.FactoryService.resolveFactory(FactoryService.java:98)

I easily fixed that one by updating the secret to che.eclipse.org/scm-username: 'first.last'. I think it would be nice at this stage to call a lowercase() function on the provided username to normalize it.

2- '.' character is not allowed
A little bit further down when it's time to create the deployment, the '.' character in the username creates a problem:

Message: Deployment.apps "workspaceoc8dj2lck468sfs7.pyspark" is invalid: [spec.template.spec.volumes[7].name: Invalid value: "first.last-git-credentials-secret-facn6": a DNS-1123 label must consist of lower case alphanumeric characters or '-', and must start and end with an alphanumeric character (e.g. 'my-name',  or '123-abc', regex used for validation is '[a-z0-9]([-a-z0-9]*[a-z0-9])?')
        at org.eclipse.che.workspace.infrastructure.kubernetes.namespace.KubernetesDeployments.createDeployment(KubernetesDeployments.java:213)
        at org.eclipse.che.workspace.infrastructure.kubernetes.namespace.KubernetesDeployments.deploy(KubernetesDeployments.java:188)
        at org.eclipse.che.workspace.infrastructure.kubernetes.KubernetesInternalRuntime.doStartMachine(KubernetesInternalRuntime.java:789)
        at org.eclipse.che.workspace.infrastructure.kubernetes.KubernetesInternalRuntime.startMachines(KubernetesInternalRuntime.java:632)
        at org.eclipse.che.workspace.infrastructure.kubernetes.KubernetesInternalRuntime.internalStart(KubernetesInternalRuntime.java:214)
        at org.eclipse.che.api.workspace.server.spi.InternalRuntime.start(InternalRuntime.java:141)
        at org.eclipse.che.api.workspace.server.WorkspaceRuntimes$StartRuntimeTask.run(WorkspaceRuntimes.java:969)
        at org.eclipse.che.commons.lang.concurrent.CopyThreadLocalRunnable.run(CopyThreadLocalRunnable.java:38)

This second problem might have greater ramifications in the system, so might be tougher to fix.

Che version

7.29.1

[skabashnyuk]

Fixed in #19715