Added option to take credential id from annotation to allow forbidden characters in k8s to be used in credential id

[UrosGligovic]

Added option to take credential id from annotation to allow forbidden characters in k8s to be used in credential id (uppercase letters for example)

[jtnord]

I'm not sure why you need this. IDs need to be unique - an annotation allows you to have collisions and this is not handled in this PR.
It also makes it harder to diagnose issues when a specific secret is not found or misbehaving as there is no 1:1 match.

[UrosGligovic]

I needed it when migrating a Jenkins instance that had a shared library that could take credential IDs from multiple places (repos could specify which credentials to use for the specific build via a config file) to k8s. I agree with the downsides, as at the moment I don't have time to implement handling of collisions should I close the PR?

[paquintana]

Agree, it's useful for migrations. Can it be added at least as experimental feature?

[topikachu]

Hi, @jtnord
We are migrating a bunch of Jenkins credentials to this new format. However, there's a blocking issue that many credentials id contains underscore not allowed by Kubernetes.
And we are not able to fix all pipelines in a short time.

Would you please merge this pull request and released a new version?

Thanks

[jhoenzsch]

I definitely have an interest in adding this functionality. I support a over a thousand developers working on dozens of Jenkins instances and while we are encouraging all teams to use compliant naming schemes and eventually will force them to do so, we can't delay the migration to use of Kubernetes secrets. Right now we are just working with a forked version of the repository but I would love to see this be added even if just as an experimental feature.

[denkojonasz]

Hi,
Any plans to merge? We are interested in this feature as well.

[MichalAugustyn]

Hello @jtnord, @UrosGligovic

I have been working on this PR for a few days already and did not manage to come up with a good solution to verify the credential uniqueness.

By introducing a simple condition before addSecret action, It is possible to avoid overwriting the existing credential if the ID conflicts with the annotation, but there is a problem when the Secret is being deleted.

In other words. Let's assume that we have a credential:

metadata:
  name: unique-name

After applying a following creds:

metadata: 
  name: unique-name-2
  annotations:
      jenkins.io/credentials-id: unique-name

Nothing happens with the existing Jenkins credential. It is not being overwritten as the referred object already exists in Jenkins.
After deleting this secret in the Kubernetes, a DELETE event is being created and the KubernetesCredentialsProvider deletes the credential.

There is no way to connect the specific Kubernetes object with a Jenkins credential. I have also tried to avoid any actions in case of two or more conflicting objects - no ADDITION, MODIFICATION, or DELETION with a SEVERE notification in the Jenkins log.

Even though, I would vote to add the simple condition before ADDING/MODIFYING credential and accept the risk of an accidental credential deletion.
The use of credential-id annotation requires an awareness of this mechanism and will not be used by mistake. We could also mention it in the docs.

Guys, let's decide if we want to move this PR forward as it seems that at least a few people are waiting for this change.
I am also the one - this hit us during Jenkins migration.

[jtnord]

in order to support the desired behaviour I would be tempted to introduce a new plugin that did mapping from requestedIDs to new IDs it could probably work for any provider (maybe not user providers), and it could do so without any UI involvement (ie it would be silent). for extra rewards you could probably see where the legacy credential was used and then migrate jobs as you see fit. the mapping would be 1:1 and there could be no conflicts (unless you tried to map foo to bar and there was already a credential called foo in the underlying provider. the configuration could be stored in a global jenkins config (managed as CasC, or just a plain text file in JENKINS_HOME - which you could if so desired inject via a ConfigMap in K8s).

in fact - if we did not use an annotation and stored this in a configMap simiar to described above I would possibly be inclined to accept it into this plugin, however I think it may have more use that just this plugin (as you could prepare a migration to k8s as the credential provider long in advance of actually migrating to k8s)

[jtnord]

based on my last comment I am closing this as I have no intention in supporting this functionality in this plugin.