Credentials provider that allows storing credentials in Kubernetes
The plugin supports most common credential types and defines an
extension point that can be implemented by other plugins to add support for custom Credential types.
Because granting these permissions for secrets is not something that should be done lightly it is highly advised for security reasons that you both create a unique service account to run Jenkins as, and run Jenkins in a unique namespace.
Credentials are added by adding them as secrets to Kubernetes, this is covered in more detail in the examples page.
Credentials are updated automatically when changes are made to the Kubernetes secret.
Credentials are deleted automatically when the secret is deleted from Kubernetes.
Once added the credentials will be visible in Jenkins under the
Any credentials that are loaded from Kubernetes can be identified by the Kubernetes provider icon in the view.
To use credentials in a pipeline you do not need to do anything special, you access them just as you would for credentials stored in Jenkins.
for example, if you had the follwing Secret defined in Kubernetes:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 apiVersion: v1 kind: Secret metadata: # this is the jenkins id. name: "another-test-usernamepass" labels: # so we know what type it is. "jenkins.io/credentials-type": "usernamePassword" annotations: # description - can not be a label as spaces are not allowed "jenkins.io/credentials-description" : "credentials from Kubernetes" type: Opaque stringData: username: myUsername password: 'Pa$$word'
you could use it via the Credentials Binding plugin
or by passing the credentialId directly to the step requiring a credential:
The release notes are managed in GitHub. The latest release will be visible in the Jenkins Update center approximatly 8 hours after a release.
This page contains more information on a developer environment.
it is reported that running in KOPS on AWS you will also need permissions to get/watch/list