Kubernetes set context

This action can be used to set cluster context before other actions like azure/k8s-deploy and azure/k8s-create-secret. It should also be used before kubectl commands (in script) are run subsequently in the workflow.

It is a requirement to use azure/login in your workflow before using this action when using the service-account or service-principal methods.

There are three approaches for specifying the deployment target:

• Kubeconfig file provided as input to the action
• Service account approach where the secret associated with the service account is provided as input to the action
• Service principal approach (only applicable for arc cluster) where service principal provided with 'creds' is used as input to action

In all these approaches it is recommended to store these contents (kubeconfig file content or secret content) in a secret.

Refer to the action metadata file for details about inputs. Note that different inputs are required for different method and cluster types. Use the below examples as a reference.

Example usage

Kubeconfig approach

- uses: azure/k8s-set-context@v5
  with:
     method: kubeconfig
     kubeconfig: <your kubeconfig>
     context: <context name> # current-context from kubeconfig is used as default

Please note that the input requires the contents of the kubeconfig file, and not its path.

Following are the ways to fetch kubeconfig file onto your local development machine so that the same can be used in the action input shown above.

Azure Kubernetes Service cluster

az aks get-credentials --name
                       --resource-group
                       [--admin]
                       [--file]
                       [--overwrite-existing]
                       [--subscription]

Further details can be found in az aks get-credentials documentation.

Generic Kubernetes cluster

Please refer to documentation on fetching kubeconfig for any generic K8s cluster

Service account approach

- uses: azure/k8s-set-context@v5
  with:
     method: service-account
     k8s-url: <URL of the cluster's API server>
     k8s-secret: <secret associated with the service account>

For fetching Server URL, execute the following command on your shell:

kubectl config view --minify -o 'jsonpath={.clusters[0].cluster.server}'

For fetching Secret object required to connect and authenticate with the cluster, the following sequence of commands need to be run:

kubectl get serviceAccounts <service-account-name> -n <namespace> -o 'jsonpath={.secrets[*].name}'

kubectl get secret <service-account-secret-name> -n <namespace> -o yaml

Service account approach for arc cluster

- uses: azure/k8s-set-context@v5
  with:
     method: service-account
     cluster-type: arc
     cluster-name: <cluster-name>
     resource-group: <resource-group>
     token: '${{ secrets.SA_TOKEN }}'

Service principal approach for arc cluster

- uses: azure/k8s-set-context@v5
  with:
     method: service-principal
     cluster-type: arc
     cluster-name: <cluster-name>
     resource-group: <resource-group>

Development

This repository enforces a 7-day dependency freshness ("bake") period: newly published npm packages are not adopted until they have been available for at least 7 days, giving the ecosystem time to catch broken or malicious releases.

• Dependabot uses a 7-day cooldown and opens PRs on the 1st and 15th of each month, grouping minor/patch updates into a single PR. Major updates are still raised individually so they get their own review.
• .npmrc sets min-release-age=7 (days), which applies the same rule to local npm install. This requires npm >= 11.10.0; the version bundled with Node 24 (this action's runtime) satisfies that. On older npm the setting is ignored, so Dependabot's cooldown remains the authoritative control.

Security exception: to adopt an urgent patch that is less than 7 days old, install it once with the age check disabled:

npm install <pkg> --min-release-age=0

Contributing

This project welcomes contributions and suggestions. Most contributions require you to agree to a Contributor License Agreement (CLA) declaring that you have the right to, and actually do, grant us the rights to use your contribution. For details, visit https://cla.opensource.microsoft.com.

When you submit a pull request, a CLA bot will automatically determine whether you need to provide a CLA and decorate the PR appropriately (e.g., status check, comment). Simply follow the instructions provided by the bot. You will only need to do this once across all repos using our CLA.

This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact opencode@microsoft.com with any additional questions or comments.