1
0
mirror of https://github.com/tektoncd/catalog.git synced 2024-11-21 05:55:35 +00:00
catalog/task/kubeconfig-creator/0.1
Quan Zhang e294e1246b [TEP-0110] Update Tekton Catalog installation instructions
Prior to this change, the installation instructions directly use the resource urls in the Catalog repo, which results in tight coupling between the organization and how users fetch resources (as described in TEP-0110). This commit updates the installation guide to install Tekton Catalog resources via Tekton Hub Api: https://github.com/tektoncd/hub/pull/539

This change decouples the Tekton Catalog organization from resouces resolution, which enables Tekton Catalog reorganization.
2022-08-16 16:25:52 +01:00
..
samples Update all images using openshift to latest stable 4.6 2021-01-05 10:15:11 +00:00
tests Add a run for the kubeconfig-creator task 2020-10-07 20:22:20 +01:00
kubeconfig-creator.yaml Add platforms annotation to several tasks 2021-07-26 15:09:08 +01:00
README.md [TEP-0110] Update Tekton Catalog installation instructions 2022-08-16 16:25:52 +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://api.hub.tekton.dev/v1/resource/tekton/task/kubeconfig-creator/0.1/raw

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)

Platforms

The Task can be run on linux/amd64, linux/s390x and linux/ppc64le platforms.

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:4.6
    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.