1
0
mirror of https://github.com/tektoncd/catalog.git synced 2024-11-22 06:02:51 +00:00
catalog/task/kubeconfig-creator/0.1
2020-08-12 08:52:06 +01:00
..
samples Modifies directory names based on the proposal 2020-07-14 19:01:58 +01:00
kubeconfig-creator.yaml Bump images to 0.15.2 2020-08-12 08:52:06 +01:00
README.md Modifies the path in readme for samples directory 2020-07-15 02:43:58 +01:00

Kubeconfig Creator Task

This Task do a similar job to the Cluster PipelineResource and are intended as its replacement. This is part of our plan to offer replacement tasks for Pipeline Resources as well as document those replacements.

This task creates a kubeconfig file that can be used to configure access to the different clusters. A common use case for this task is to deploy your application/function on different clusters.

The task will use the kubeconfigwriter image and the provided parameters to create a kubeconfig file that can be used by other tasks in the pipeline to access the target cluster. The kubeconfig will be placed at /workspace/<workspace-name>/kubeconfig.

This task provides users variety of ways to authenticate:

  • Authenticate using tokens.
  • Authenticate using client key and client certificates.

Install the Task

kubectl apply -f https://raw.githubusercontent.com/tektoncd/catalog/master/task/kubeconfig-creator/0.1/kubeconfig-creator.yaml

Workspace

  • output: A workspace that stores the generated kubeconfig file, such that it can be used in the other tasks to access the cluster.

Parameters

  • Name: Name of the cluster.
  • URL: Address of the target cluster (e.g.: https://hostname:port)
  • Username: Username for basic authentication to the cluster (default: "")
  • Password: Password for basic authentication to the cluster (default: "")
  • Cadata: Contains PEM-encoded certificate authority certificates (default: "")
  • ClientKeyData: Contains PEM-encoded data from a client key file for TLS (default: "")
  • ClientCertificateData: Contains PEM-encoded data from a client cert file for TLS (default: "")
  • Namespace: Default namespace to use on unspecified requests (default: "")
  • Token: Bearer token for authentication to the cluster (default: "")
  • Insecure: If true, skips the validity check for the server's certificate. This will make your HTTPS connections insecure (default: false)

Usage

This example task uses a shared workspace with PVC to store the kubeconfig in the output directory. Kubeconfig file is stored at /workspace/<workspace-name>/kubeconfig.

Task can be used with the other task in the pipeline to authenticate the cluster. In this example, pipeline has a task kubeconfig-creator that generates a kubeconfig file for the cluster and the test-task uses that kubeconfig file and verifiy whether the application has an access to the cluster or not by using some kubectl/oc commands.

Required params can be passed in the pipeline as follows:

params:
  - name: name
    value: cluster-bot
  - name: username
    value: admin
  - name: url
    value: https://api.ci-ln-13f81c2-d5d6b.origin-ci-int-aws.dev.rhcloud.com:6443
  - name: cadata
    value: LS0tLS1C....
  - name: clientCertificateData
    value: LS0tLS1C....
  - name: clientKeyData
    value: LS0tLS1C....

This can be referred for the pipeline example.

Test-task uses shared-workspace to fetch the kubeconfig file from the input named workspace and uses oc commands to check whether the cluster is configured or not.

steps:
  - name: get
    image: quay.io/openshift/origin-cli:latest
    script: |
      export KUBECONFIG="$(workspaces.input.path)/$(inputs.params.filename)"
      #
      # check that the cluster is configured
      oc get pods

Workspace with PVC is used, as shown below.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: kubeconfig-pvc
spec:
  resources:
    requests:
      storage: 5Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteOnce

Finally, PipelineRun is used to execute the tasks in the pipeline and get the results. Reference for sample PipelineRun can be found here.

NOTE

  • Since only one authentication technique is allowed per user, either a token or a password should be provided, if both are provided, the password will be ignored.

  • clientKeyData and clientCertificateData are only required if token or password is not provided for authentication to cluster.