kubernetes-credentials-provider-plugin

Credentials provider that allows storing credentials in Kubernetes

Project maintained by jenkinsci Hosted on GitHub Pages — Theme by mattgraham

The Kubernetes Credentials Provider is a Jenkins plugin to enable the retrieval of Credentials stored as Kubernetes Secrets.

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.

Using

Pre-requisites

Jenkins must be running in a kubernetes cluster
The pod running Jenkins must have a service account with a role that sets the following:
- get/watch/list permissions for secrets¹

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.

Managing credentials

Adding credentials

Credentials are added by adding them as secrets to Kubernetes, this is covered in more detail in the examples page.

To restrict the secrets added by this plugin use the system property com.cloudbees.jenkins.plugins.kubernetes_credentials_provider.KubernetesCredentialProvider.labelSelector to set the Kubernetes Label selector expression.

-Dcom.cloudbees.jenkins.plugins.kubernetes_credentials_provider.KubernetesCredentialProvider.labelSelector="env in (iat uat)"

Updating credentials

Credentials are updated automatically when changes are made to the Kubernetes secret.

Deleting credentials

Credentials are deleted automatically when the secret is deleted from Kubernetes.

Viewing credentials

Once added the credentials will be visible in Jenkins under the /credentials/ page. Any credentials that are loaded from Kubernetes can be identified by the Kubernetes provider icon in the view.

Using the credentials inside Jenkins

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
16
17
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"
# folder/job scope - optional
    jenkins.io/credentials-store-locations: "['thisIsJobA', 'thisIsJobB', 'thisIsFolderA/thisIsJobC']"
type: Opaque
stringData:
  username: myUsername
  password: 'Pa$$word'

you could use it via the Credentials Binding plugin

withCredentials([usernamePassword(credentialsId: 'another-test-usernamepass',
                                  usernameVariable: 'USER', 
                                  passwordVariable: 'PASS')]) {
  sh 'curl -u $USER:$PASS https://some-api/'
}

or by passing the credentialId directly to the step requiring a credential:

git credentialsId: 'another-test-usernamepass', url: 'https://github.com/foo/bar'

Issue reporting

Any issues should be reporting in the main Jenkins JIRA tracker. The issue tracker is not a help forum, for help please use IRC or the user mailing list

Releases and Change logs

The release notes are managed in GitHub. The latest release will be visible in the Jenkins Update center approximatly 8 hours after a release.

Developing

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 configmaps ↩