Home

Awesome

get-gke-credentials

This action configures authentication to a GKE cluster via a kubeconfig file that can be used with kubectl or other methods of interacting with the cluster.

Authentication is performed by generating a short-lived token (default behaviour) or via the GCP auth plugin present in kubectl which uses the service account keyfile path in GOOGLE_APPLICATION_CREDENTIALS.

This is not an officially supported Google product, and it is not covered by a Google Cloud support contract. To report bugs or request features in a Google Cloud product, please contact Google Cloud support.

Prerequisites

This action requires:

Usage

jobs:
  job_id:
    permissions:
      contents: 'read'
      id-token: 'write'

    steps:
    - id: 'auth'
      uses: 'google-github-actions/auth@v2'
      with:
        project_id: 'my-project'
        workload_identity_provider: 'projects/123456789/locations/global/workloadIdentityPools/my-pool/providers/my-provider'

    - id: 'get-credentials'
      uses: 'google-github-actions/get-gke-credentials@v2'
      with:
        cluster_name: 'my-cluster'
        location: 'us-central1-a'

    # The KUBECONFIG env var is automatically exported and picked up by kubectl.
    - id: 'get-pods'
      run: 'kubectl get pods'

Inputs

<!-- BEGIN_AUTOGEN_INPUTS --> <!-- END_AUTOGEN_INPUTS -->

Outputs

In addition to setting the $KUBECONFIG environment variable, this GitHub Action produces the following outputs:

<!-- BEGIN_AUTOGEN_OUTPUTS --> <!-- END_AUTOGEN_OUTPUTS -->

Authorization

There are a few ways to authenticate this action. A service account will be needed with at least the following roles:

If you are using the Connect Gateway, you must also have:

Via google-github-actions/auth

Use google-github-actions/auth to authenticate the action. You can use Workload Identity Federation or traditional Service Account Key JSON authentication. by specifying the credentials input. This Action supports both the recommended Workload Identity Federation based authentication and the traditional Service Account Key JSON based auth.

See usage for more details.

Authenticating via Workload Identity Federation

jobs:
  job_id:
    permissions:
      contents: 'read'
      id-token: 'write'

    steps:
    - id: 'auth'
      uses: 'google-github-actions/auth@v2'
      with:
        project_id: 'my-project'
        workload_identity_provider: 'projects/123456789/locations/global/workloadIdentityPools/my-pool/providers/my-provider'

    - id: 'get-credentials'
      uses: 'google-github-actions/get-gke-credentials@v2'
      with:
        cluster_name: 'my-cluster'
        location: 'us-central1-a'

Authenticating via Service Account Key JSON

jobs:
  job_id:
    steps:
    - id: 'auth'
      uses: 'google-github-actions/auth@v2'
      with:
        credentials_json: '${{ secrets.gcp_credentials }}'

    - id: 'get-credentials'
      uses: 'google-github-actions/get-gke-credentials@v2'
      with:
        cluster_name: 'my-cluster'
        location: 'us-central1-a'

Via Application Default Credentials

If you are hosting your own runners, and those runners are on Google Cloud, you can leverage the Application Default Credentials of the instance. This will authenticate requests as the service account attached to the instance. This only works using a custom runner hosted on GCP.

jobs:
  job_id:
    steps:
    - id: 'get-credentials'
      uses: 'google-github-actions/get-gke-credentials@v2'
      with:
        cluster_name: 'my-cluster'
        location: 'us-central1-a'

The action will automatically detect and use the Application Default Credentials.

With Connect gateway

You can utilize the Connect gateway feature of Fleets with this action to connect to clusters without direct network connectivity. This can be useful for connecting to private clusters from GitHub hosted runners.

jobs:
  job_id:
    steps:
    - id: 'get-credentials'
      uses: 'google-github-actions/get-gke-credentials@v2'
      with:
        cluster_name: 'my-private-cluster'
        location: 'us-central1-a'
        use_connect_gateway: 'true'

Follow the Connect gateway documentation for initial setup. Note: The Connect Agent service account must have the correct impersonation policy on the service account used to authenticate this action.