We have som credentials contain underscore in an existing Jenkins instance. This prevents us from migrating old credentials to this new format.

       
      We hope there's a way to customize the credentials name containing the string not allowed by Kubernetes.

      NOTE PRs to address this in kubernetes-credentials-provider will not be accepted. see this comment as to why. The ticket is still open as this can be done completely outside of the kubernetes-credentials-provider plugin

          [JENKINS-62360] Ability to customize credentials id

          Gareth Evans added a comment -

          Running into the same issue:

          Secret "SYNK_TOKEN" is invalid: metadata.name: Invalid value: "SYNK_TOKEN": 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])?)*')
          

          Maybe we could add a label of `"jenkins.io/credentials-id": "SOME_UNDERSCORED_NAME"` to be used as the credential ID rather than `metadata.name`?

          Gareth Evans added a comment - Running into the same issue: Secret "SYNK_TOKEN" is invalid: metadata.name: Invalid value: "SYNK_TOKEN" : 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])?)*' ) Maybe we could add a label of `"jenkins.io/credentials-id": "SOME_UNDERSCORED_NAME"` to be used as the credential ID rather than `metadata.name`?

          Gareth Evans added a comment -

          Gareth Evans added a comment - https://github.com/jenkinsci/kubernetes-credentials-provider-plugin/pull/53

          James Nord added a comment - - edited

          This is not going to be fixed or accepted into the k8s credential provider.

          If a mapping is needed a new credential provider that can do aliases should be created and maintained separately. I want the existing code to do one thing only and I firmly believe that useable IDs can be created that conform to the restrictions.
          The exception would only be for migration - but for migration that new aliasing credential provider is the perfect solution and it should be able to track and report places (jobs config) where something is still being used with the old ID, and the plugin can be removed after the migration has occurred - so forcing the the k8s-cred-provider would have the added complexity for some users for a short (months) period of time seems bad.

          James Nord added a comment - - edited This is not going to be fixed or accepted into the k8s credential provider. If a mapping is needed a new credential provider that can do aliases should be created and maintained separately. I want the existing code to do one thing only and I firmly believe that useable IDs can be created that conform to the restrictions. The exception would only be for migration - but for migration that new aliasing credential provider is the perfect solution and it should be able to track and report places (jobs config) where something is still being used with the old ID, and the plugin can be removed after the migration has occurred - so forcing the the k8s-cred-provider would have the added complexity for some users for a short (months) period of time seems bad.

            Unassigned Unassigned
            topikachu Yi Gong
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated: