1
0
mirror of https://github.com/tektoncd/catalog.git synced 2024-11-28 06:30:40 +00:00
catalog/gcloud/README.md
ishani2412 c89d3965b7 Improve Readme.md
PR to improve the Readme.md migrating the install task URL from
master to v1beta1

Signed-off-by: ishani2412 <ishani.1613039@kiet.edu>
2020-06-02 09:03:51 +01:00

4.0 KiB

gcloud

This task performs operations on Google Cloud Platform resources using gcloud.

Install the Task

kubectl apply -f https://raw.githubusercontent.com/tektoncd/catalog/v1beta1/gcloud/gcloud.yaml

Parameters

  • gcloud-image: gcloud CLI container image to run this task.

    default: google/cloud-sdk:slim

    You can use a specific version of the gcloud CLI using google/cloud-sdk:263.0.0-slim.

    The default image (:slim) does not include any optional gcloud components. You can use an image with optional components installed by removing the slim (e.g., google/cloud-sdk, or google/cloud-sdk:263.0.0).

  • ARGS: The arguments to pass to gcloud CLI. default: ["help"]

Usage

Authorizing gcloud commands

GKE Default Node Identity

On GKE, by default, instance metadata is available to workloads running in Pods, and this extends to Tekton TaskRuns. This means that, by default, gcloud commands will be authorized as the cluster's node identity, which is typically [PROJECT_NUMBER]-compute@developer.gserviceaccount.com. You can specify this account when creating or updating a GKE cluster.

GKE Workload Identity

Exposing node identity to all workloads on a cluster's nodes may not be what you want. For example, you might want certain workloads to operate under different identities, or to not have authorization to perform actions at all.

To solve this, GKE allows cluster administrators to enable Workload Identity (beta), which ties a Kubernetes Service Account (KSA) on the cluster to a Google IAM Service Account (GSA) on the cluster's project. With Workload Identity, users can run TaskRuns as different KSAs, and have them be authorized as different GSAs.

Outside GKE

To authorize gcloud as an IAM Service Account manually, or outside of GKE, you can download an IAM Service Account Key and invoke gcloud auth activate-service-account within your workflow to authorize further gcloud commands as that IAM Service Account.

Running the Task

Checking authorization

You can invoke gcloud auth list to check that authorization is set up correctly:

Create a file, check-auth.yaml:

apiVersion: tekton.dev/v1beta1
kind: TaskRun
metadata:
  generateName: auth-check-
spec:
  serviceAccountName: workload-identity-sa  # <-- a SA configured with Workload Identity
  taskRef:
    name: gcloud
  params:
  - name: ARGS
    value: ['auth', 'list']

Run it with kubectl create -f check-auth.yaml

When this runs, it will print logs indicating the Service Account it is using to authorize its actions.

Deploying to Cloud Run

Create a file, deploy-cloudrun.yaml:

apiVersion: tekton.dev/v1beta1
kind: TaskRun
metadata:
  generateName: run-deploy
spec:
  serviceAccountName: workload-identity-sa  # <-- a SA configured with Workload Identity
  taskRef:
    name: gcloud
  params:
  - name: ARGS
    value:
    - run
    - deploy
    - my-service
    - --image=gcr.io/my-project/my-image
    - --platform=PLATFORM
    - --region=REGION

Run it with kubectl create -f deploy-cloudrun.yaml

When this runs, it will deploy the specified image as a new Revision to the Cloud Run Service named my-service, running on the specified platform, in the specified region.

Creating a GCE Instance

Create a file, create-instance.yaml:

apiVersion: tekton.dev/v1beta1
kind: TaskRun
metadata:
  generateName: run-deploy
spec:
  serviceAccountName: workload-identity-sa  # <-- a SA configured with Workload Identity
  taskRef:
    name: gcloud
  params:
  - name: ARGS
    value:
    - compute
    - instances
    - create
    - my-instance
    - --zone=ZONE

Run it with kubect create -f create-instance.yaml

When this runs, it will create a new GCE VM instance in the specified zone.