azure / aks-set-context

GitHub Action for setting context (retrieving Kubeconfig) before interacting with Kubernetes cluster

Azure Kubernetes Service set context

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

You must run Azure/login before this action.

Action inputs

Action inputs	Description
resource-group (Required)	Resource group containing the AKS cluster
cluster-name (Required)	Name of the AKS cluster
subscription	Subscription tied to AKS cluster
admin	Get cluster admin credentials. Values: true or false
use-kubelogin	Allows non-admin users to use the Action via kubelogin

Example

OIDC Authentication (recommended)

- uses: azure/login@v1
  with:
     client-id: ${{ secrets.AZURE_CLIENT_ID }}
     tenant-id: ${{ secrets.AZURE_TENANT_ID }}
     subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}

- uses: azure/aks-set-context@v3
  with:
     resource-group: '<resource group name>'
     cluster-name: '<cluster name>'

Service Principal Authentication

- uses: azure/login@v1
  with:
     creds: ${{ secrets.AZURE_CREDENTIALS }}

- uses: azure/aks-set-context@v3
  with:
     resource-group: '<resource group name>'
     cluster-name: '<cluster name>'

Kubelogin

kubelogin is at the core of the non-admin user scenario. For more information on kubelogin, refer to the documentation here.

To run this Action as a non-admin user, you must first install kubelogin. To set up kubelogin, you may use the action azure/use-kubelogin:

- name: Set up kubelogin for non-interactive login
  uses: azure/use-kubelogin@v1
  with:
     kubelogin-version: 'v0.0.24'

Non-Admin User Example

If you are executing this Action as a non-admin user, you need to toggle the optional use-kubelogin Action input to true for it to work.

- uses: azure/login@v1
  with:
     client-id: ${{ secrets.AZURE_CLIENT_ID }}
     tenant-id: ${{ secrets.AZURE_TENANT_ID }}
     subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}

- uses: azure/aks-set-context@v3
  with:
     resource-group: '<resource group name>'
     cluster-name: '<cluster name>'
     admin: 'false'
     use-kubelogin: 'true'

- uses: azure/login@v1
  with:
     creds: ${{ secrets.AZURE_CREDENTIALS }}

- uses: azure/aks-set-context@v3
  with:
     resource-group: '<resource group name>'
     cluster-name: '<cluster name>'
     admin: 'false'
     use-kubelogin: 'true'

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 [email protected] with any additional questions or comments.

Support

aks-set-context is an open source project that is not covered by the Microsoft Azure support policy. Please search open issues here, and if your issue isn't already represented please open a new one. The project maintainers will respond to the best of their abilities.

aks-set-context's Issues

panic: no Auth Provider found for name "azure"

I get this error when I switched over from using v1 to v2. I am using "Service Principal Authentication" and the same credentials as before.

kubeconfig file shows error while deploying to aks using actions

While running a workflow used to deploy to azure kubernetes setting the context and then deploying to aks using k8-deploy action gives below error-
Error->
##[error]YAMLException: incomplete explicit mapping pair; a key node is missed; or followed by a non-tabulated empty line at line 1, column 85:
... able. This is insecure. Location: /home/runner/work/_temp/kubeco ...

Have attached workflow steps used and detailed logs of action run
Workflow file used->workflowfile.txt

Detailed logs->logs.txt

Bug: ERROR: AADSTS700024: Client assertion is not within its valid time range.

What happened?

Sometimes, I get the following error message:

ERROR: AADSTS700024: Client assertion is not within its valid time range

It doesn't happen all the time, in my case it only happens on 1 of the 4 environments.
Re-running the GitHub Actions workflow doesn't fix it.
I run a similar GitHub Actions workflow on 15 repositories and 4 environments and the same error happens on 3 repositories and 1 single environment (always the same).

Version

• I am using the latest version

Runner

self-hosted

Relevant log output

##[debug]Evaluating condition for step: 'Get K8s context'
##[debug]Evaluating: success()
##[debug]Evaluating success:
##[debug]=> true
##[debug]Result: true
##[debug]Starting: Get K8s context
##[debug]Loading inputs
##[debug]Evaluating: vars.AZURE_RESOURCE_GROUP
##[debug]Evaluating Index:
##[debug]..Evaluating vars:
##[debug]..=> Object
##[debug]..Evaluating String:
##[debug]..=> 'AZURE_RESOURCE_GROUP'
##[debug]=> 'rg-***'
##[debug]Result: 'rg-***'
##[debug]Evaluating: vars.AKS_CLUSTER_NAME
##[debug]Evaluating Index:
##[debug]..Evaluating vars:
##[debug]..=> Object
##[debug]..Evaluating String:
##[debug]..=> 'AKS_CLUSTER_NAME'
##[debug]=> 'aks-***'
##[debug]Result: 'aks-***'
##[debug]Loading env
Run azure/aks-set-context@v3
  with:
    resource-group: rg-***
    cluster-name: aks-***
    admin: false
    use-kubelogin: true
  env:
    CONTAINER_NAME: ***
    AZURE_HTTP_USER_AGENT: 
    AZUREPS_HOST_ENVIRONMENT: 
##[debug]Writing kubeconfig to /home/runner-admin/actions-runner/_work/_temp/kubeconfig_1691671866005
/usr/bin/az aks get-credentials --resource-group rg-*** --name aks-*** -f /home/runner-admin/actions-runner/_work/_temp/kubeconfig_1691671866005
ERROR: AADSTS700024: Client assertion is not within its valid time range. Current time: 2023-08-10T12:51:06.6841503Z, assertion valid from 2023-08-09T15:06:56.0000000Z, expiry time of assertion 2023-08-09T15:11:56.0000000Z. Review the documentation at https://docs.microsoft.com/azure/active-directory/develop/active-directory-certificate-credentials .
Trace ID: 070e96fc-76e1-46a8-88f7-055a0d489900
Correlation ID: 2ce46b3e-5dcf-42ed-a497-33231a9dc308
Timestamp: 2023-08-10 12:51:06Z
Interactive authentication is needed. Please run:
az login
Error: Error: The process '/usr/bin/az' failed with exit code 1
##[debug]Node Action run completed with exit code 1
##[debug]AZURE_HTTP_USER_AGENT='GitHubActions/azure/aks-set-context(6ff0b0b4611939515451a12aa8fec15e3dd86d30d7e8c0569dd2ded2113f8931; 5809746149)'
##[debug]AZUREPS_HOST_ENVIRONMENT='GitHubActions/azure/aks-set-context(6ff0b0b4611939515451a12aa8fec15e3dd86d30d7e8c0569dd2ded2113f8931; 5809746149)'
##[debug]AZURE_HTTP_USER_AGENT=''
##[debug]AZUREPS_HOST_ENVIRONMENT=''
##[debug]Finishing: Get K8s context

Instructions to generate the `creds` use deprecated CLI option '--sdk-auth'

az ad sp create-for-rbac --sdk-auth

Option '--sdk-auth' has been deprecated and will be removed in a future release.
In a future release, this command will NOT create a 'Contributor' role assignment by default. If needed, use the --role argument > to explicitly create a role assignment.
Creating 'Contributor' role assignment under scope '/subscriptions/[sub-id]'
The output includes credentials that you must protect. Be sure that you do not include these credentials in your code or check the credentials into your source control. For more information, see https://aka.ms/azadsp-cli
'name' property in the output is deprecated and will be removed in the future. Use 'appId' instead.

KUBECONFIG variable set while actions-hub/kubectl uses KUBE_CONFIG

This azure/aks-set-context seems to set an environment variable called KUBECONFIG while a presumably common downstream action, actions-hub/kubectl expects an environment variable called KUBE-CONFIG. It would be great if this action could change the name of it's variable, or make two.

Upgrading from v1 to v3 error

I've been using v1 in my github actions with no problems but started to get a warning from github that node 12 was deprecated and I should update this action. So I tried to move to v3 but can not get it to work so I can run kubectl command successfully.

The v1 set up was:

   - uses: azure/aks-set-context@v1
        with:
          creds: "${{ secrets.CREDENTIALS }}"
          cluster-name: ${{ secrets.CLUSTER_NAME }}
          resource-group: ${{ secrets.RESOURCE_GROUP }}

the v3 set up - I've tried all combinations of admin and use-kubelogin for example:

      - name: Azure Login
        uses: azure/login@v1
        with:
          creds: "${{ secrets.CREDENTIALS }}"

      - name: Azure kubelogin
        run: |
          curl -LO https://github.com/Azure/kubelogin/releases/download/v0.0.9/kubelogin-linux-amd64.zip
          sudo unzip -j kubelogin-linux-amd64.zip -d /usr/local/bin
          rm -f kubelogin-linux-amd64.zip
          kubelogin --version
      
     - uses: azure/aks-set-context@v3
          with:
            cluster-name: ${{ secrets.CLUSTER_NAME }}
            resource-group: ${{ secrets.RESOURCE_GROUP }}
            admin: "false"
            use-kubelogin: "true"

With these there is no error during login or via the aks-set-context but I get the error

Error from server (Forbidden): pods "my-pod-0" is forbidden: User "xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" cannot get resource "pods" in API group "" in the namespace "my-namespace": User does not have access to the resource in Azure. Update role assignment to allow access.

This user does have access - supported by the fact it works in the v1 case.

I'm not sure the problem lies with this action? but if not do you know why this could happen?

use-kubelogin option does not work properly

Setting use-kubelogin does indeed executes kubelogin, but it seems to modify wrong kubeconfig file.

Run azure/[email protected]
  with:
    cluster-name: xxx
    resource-group: xxx
    admin: false
    use-kubelogin: true
/usr/bin/az aks get-credentials --resource-group xxx --name xxx -f /home/runner/work/_temp/kubeconfig_1654654112792
WARNING: Merged "xxx" as current context in /home/runner/work/_temp/kubeconfig_1654654112792
/usr/local/bin/kubelogin convert-kubeconfig -l azurecli

Yet subsequent actions do not see updated kubeconfig. For instance,

Run azure/[email protected]
Deploying manifests
/usr/local/bin/kubectl apply -f /tmp/baked-template-1654654116421.yaml --insecure-skip-tls-verify --namespace xxx
WARNING: the azure auth plugin is deprecated in v1.22+, unavailable in v1.25+; use https://github.com/Azure/kubelogin instead.
...

At the same time running /usr/local/bin/kubelogin convert-kubeconfig -l azurecli manually as a separate step after aks-set-context has finished executing seems to work fine.

After looking at the source code I suspect the problem is that kubelogin is executed before $KUBECONFIG environment variable has been exported. As such it does not "see" the right file to kubeloginify.

Allow specifying of subscription to utilize in the action

We are using "Service Principal Authentication" so don't have a way of specifying the subscription. So looks like this (
#41 ) is rebroken in v2.

Documentation refers to wrong attributes names

The home documentation for this github action refers to wrong attribute names.

As stated in action metadata the corect atributes should be resource-group instead resourceGroupName and cluster-name instead clusterName.

Cannot get cluster admin credentials

in GA worlflow using that:

steps:
- uses: azure/login@v1
with:
creds: ${{ inputs.aks_sp_secret }}

- name: get AKS context
  id: dep_kube
  uses: azure/[email protected]
  with:
    cluster-name: ${{ inputs.cluster_name }}
    resource-group: ${{ inputs.resource_group }}
    admin: true

but as result receive: Warning: Unexpected input(s) 'admin', valid inputs are ['resource-group', 'cluster-name']

Done setting cloud: "azurecloud"
Login successful.
Warning: Unexpected input(s) 'admin', valid inputs are ['resource-group', 'cluster-name']

BadGatewayConnection when using the action

Expected Behavior

The action should pass successfully and the workflow should start using the K8S context i choose as its Kubernetes context.

Actual Behavior

The actions hangs for few minutes and then fails with the message:

##[error]{"error":{"code":"BadGatewayConnection","message":"The network connectivity issue encountered for 'Microsoft.ContainerService'; cannot fulfill the request."}}
##[error]Node run failed with exit code 1

Steps to Reproduce the Problem

1. Use aks-set-context action as follows:

# Set the target AKS cluster
- name: Set k8s context
  uses: Azure/aks-set-context@v1
  with:
    creds: "${{ env.azure_service_principal }}"
    resource-group: abcd-qa
    cluster-name: abcd-qa-k8s

2. Trigger the workflow.

Notes

1. The same workflow worked just minutes before this issue began to occur - same workflow with exactly the same YAML and exactly the same credentials etc.
   Nothing was changed neither in the workflow nor the environment!
2. I tried recreating a service principal using az ad sp create-for-rbac --sdk-auth and changed the workflow to use that, it didn't help.

Support for AzureChinaCloud

Hi, I am currently trying to get this action to work with an AKS instance in AzureChinaCloud. This action fails with "ExpiredServicePrincipal", although I am able to login via AZ CLI and fetch the aks credentials with "az aks get-credentials", so I wonder if this ExpiredServicePrincipal error is actually because I didn't specify using AzureChinaCloud in this action, and it couldn't find my subscription or service principal in the global cloud.

with:
creds: ***
cluster-name: [cluster_group_name]
resource-group: [resource_group_name]
Error: ExpiredServicePrincipal

README.md uses incorrect variable names

From the source code, resourceGroupName should actually be resource-group,
while clusterName should actually be cluster-name

Feature Request: enable conditional --public-fqdn parameter

Feature request

It would be great, if the command took into account the --public-fqdn parameter, while logging into the cluster. As stated in the Azure CLI documentation:

--public-fqdn
Get private cluster credential with server address to be public fqdn.
default value: False

It could be just a bool in the actions yaml to enable this :)

Undocumented access requirements

I have created a service principal, and added it to a group that is administrators in the AKS cluster (using AAD RBAC).

Still, it requires some additional access to log in:

Error: ***"error":***"code":"AuthorizationFailed","message":"The client 'XXXX' with object id 'XXXXXX' does not have authorization to perform action 'Microsoft.ContainerService/managedClusters/accessProfiles/listCredential/action' over scope '/subscriptions/XXXXX/resourceGroups/XXXX/providers/Microsoft.ContainerService/managedClusters/XXXX/accessProfiles/clusterAdmin' or the scope is invalid. If access was recently granted, please refresh your credentials."***

It would be nice if the required access was documented, or maybe I am doing something wrong here?

The required action listCredential, I am not sure about that. :-)

Action should cleanup kubeconfig from runner in post run

Cleanup generated kubeconfig from runner by default or leave config by flag

Feature Request: Add option to retry failed operations

Feature request

We're using this action in a highly concurrent setup, and from time to time we get errors like these on some of the runs:

Run azure/aks-set-context@v[3]
  with:
    cluster-name: <cluster-name>
    resource-group: <resource-group>
    admin: false
    use-kubelogin: true
  env:
    AZURE_HTTP_USER_AGENT: 
    AZUREPS_HOST_ENVIRONMENT: 
/usr/bin/az aks get-credentials --resource-group <resource-group> --name <cluster-name> -f /home/runner/work/_temp/kubeconfig_1679069
ERROR: ('Connection aborted.', RemoteDisconnected('Remote end closed connection without response'))
Error: Error: The process '/usr/bin/az' failed with exit code 1

I'm guessing it's because of temporary issues because of the many concurrent connections, and we'd probably see fewer errors if any failed azure cli commands can be retried.

My suggestion is adding the following input parameters, and use them to retry failing azure cli commands:

   retries:
      description: 'Number of times to retry setting the context'
      default: 0
      required: false
   retry-delay:
      description: 'Time to wait (in ms) between retries'
      default: 0
      required: false

We're currently running a fork with this is implemented, but I would prefer to clean it up and create a proper PR if you're interested?

Can't execute kubectl without oauth device prompt after running this

I have the following:

      - uses: azure/login@v1
        with:
          creds: ${{ secrets.BETA_AZURE_CREDENTIALS }}
      - uses: azure/[email protected]
      - uses: azure/[email protected]
        with:
          resource-group: ${{ secrets.BETA_RESOURCE_GROUP }}
          cluster-name: ${{ secrets.BETA_AKS_CLUSTER }}
      - run: kubectl -n pltfrmd set image deployments/account account=${{ secrets.BETA_ACR_SERVER }}/account:${{ github.sha }} 

From everything I've read, the implication is that after using aks-set-context you can then run kubectl commands. But when I run this, I get a prompt to open a web browser with a code in the action logs. I've verified all of the variables are set correctly, but no joy. Please provide documentation on how we'd use this to execute a kubectl command reliably.

Allow specifying of subscription to utilize in the action

For situations where there are multiple subscriptions that the given login has access to, there is no way to specify the subscription to use, allowing an optional subscription_id or subscription_name input on the action would allow the subscription to be specified without having to switch to it as a 2nd step in workflows that utilize this action.

Hard coded URLs in login.ts

Can we please fix the hard coded URLs liek the following ? They will have issues when we move to more generic cloud support.
const managementEndpointUrl = 'https://management.azure.com/'

Unable to use AAD Cluster with non-admin users

Hello,

We are trying to use this action with a Service Principle that only has access to a single namespace in our AKS cluster, but we're getting these errors:

Run azure/aks-set-context@v1
Error: ***"error":***"code":"AuthorizationFailed","message":"The client 'xxxx' with object id 'xxxx' does not have authorization to perform action 'Microsoft.ContainerService/managedClusters/accessProfiles/listCredential/action' over scope '/subscriptions/xxxx/resourceGroups/xxxx/providers/Microsoft.ContainerService/managedClusters/xxxx/accessProfiles/clusterAdmin' or the scope is invalid. If access was recently granted, please refresh your credentials."***

I can see in the code that the clusterAdmin role is hardcoded. Is there a way to make this configurable? Or is there an alternative action we can use to log in to AKS?

getAzureAccessToken uses hardcoded resource endpoint

aks-set-context/src/login.ts

Line 18 in 0f85070

resource: 'https://management.azure.com',

Should read from 'resourceManagerEndpointUrl' in config