Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
guidoiaquinti opened this issue Nov 26, 2021 · 115 comments
Closed
Assignees
Labels
bug Something isn't working external oidc P1 Some scenario broken but workaround exists product enhancement New feature or request

Comments

@guidoiaquinti
Copy link

guidoiaquinti commented Nov 26, 2021

馃憢 Hi! I鈥檓 using the azure/login action for CD and I鈥檓 often getting an error when the job execution takes more than a couple of minutes from the initial login.

ERROR: AADSTS700024: Client assertion is not within its valid time range. Current time: 2021-11-26T09:44:41.0193003Z, expiry time of assertion 2021-11-26T09:31:56.0000000Z.

Is there a way to extend the validity of the token via a parameter? The aws-actions/configure-aws-credentials action does it via a role-duration-seconds flag:

The default session duration is 6 hours when using an IAM User to assume an IAM Role [..] . If you would like to adjust this you can pass a duration to role-duration-seconds, but the duration cannot exceed the maximum that was defined when the IAM Role was created.

ref: https://github.com/aws-actions/configure-aws-credentials/blob/master/README.md#assuming-a-role

Thank you! 馃檱

@guidoiaquinti guidoiaquinti added the need-to-triage Requires investigation label Nov 26, 2021
@BALAGA-GAYATRI BALAGA-GAYATRI added question The issue doesn't require a change to the product in order to be resolved. Most issues start as that and removed need-to-triage Requires investigation labels Nov 29, 2021
@BALAGA-GAYATRI
Copy link
Contributor

@kjyam98 @N-Usha @udayxhegde Is this Doable in Azure?

@udayxhegde
Copy link

@BALAGA-GAYATRI I am not sure I understand the question: what is Doable in Azure? The issue seems to be that the github token has expired when it is presented to Azure AD

@guidoiaquinti
Copy link
Author

guidoiaquinti commented Dec 3, 2021

@udayxhegde the problem I鈥檓 trying to solve is customise the expiration time of the token. This is useful if you plan to run operations on the Azure platform with timeframes longer than the standard validity.

Example:

  1. Provisioning of the AKS cluster
  2. deploy a stack
  3. execute e2e tests
  4. destruction of the AKS cluster

If the timeframe between steps 1 and 4 is longer than the maximum validity of the token, you will encounter an error similar to the one I posted above.

It would be useful to customise the token validity via azure/login. This is something that other cloud platforms already support.

Example:

    - name: Configure AWS Credentials
      uses: aws-actions/configure-aws-credentials@v1
      with:
        role-to-assume: arn:aws:iam::123456789100:role/my-github-actions-role
        role-duration-seconds: 3600

@BALAGA-GAYATRI
Copy link
Contributor

Hey @guidoiaquinti, This is currently not being implemented in OIDC login mechanism. If you want to leverage the auto refresh mechanism of token, you may use the SPN login by setting your deployment credentials using - https://github.com/Azure/login#configure-a-service-principal-with-a-secret
In this way you will not face token expiration issue.

@guidoiaquinti
Copy link
Author

Hey @guidoiaquinti, This is currently not being implemented in OIDC login mechanism. If you want to leverage the auto refresh mechanism of token, you may use the SPN login by setting your deployment credentials using - https://github.com/Azure/login#configure-a-service-principal-with-a-secret In this way you will not face token expiration issue.

Thank you for your reply Balaga 馃檱

Any plan to add this feature to the Azure roadmap? I'm trying to avoid generating and hardcoding long-term secrets if possible.

@BALAGA-GAYATRI
Copy link
Contributor

Yes @guidoiaquinti. The refresh token mechanism is yet to be implemented.

@BALAGA-GAYATRI BALAGA-GAYATRI added product enhancement New feature or request and removed question The issue doesn't require a change to the product in order to be resolved. Most issues start as that labels Dec 14, 2021
@guidoiaquinti
Copy link
Author

guidoiaquinti commented Dec 14, 2021 via email

@BALAGA-GAYATRI
Copy link
Contributor

BALAGA-GAYATRI commented Dec 14, 2021

Yes. But we can't commit to a specific timeline for this right now. We will keep you informed.

@github-actions
Copy link

This issue is idle because it has been open for 14 days with no activity.

@github-actions github-actions bot added the idle Inactive for 14 days label Dec 28, 2021
@kaverma kaverma added the oidc label Jan 18, 2022
@kjyam98 kjyam98 removed their assignment Jan 28, 2022
@kjyam98
Copy link

kjyam98 commented Jan 28, 2022

@BALAGA-GAYATRI please assign to udayxhegde

@github-actions github-actions bot removed the idle Inactive for 14 days label Jan 28, 2022
@udayxhegde
Copy link

@kjyam98, that is not the right assignment

@BALAGA-GAYATRI please assign to udayxhegde

@kjyam98 , @BALAGA-GAYATRI: what are you expecting by assigning to me? did you have a specific design in mind that you need my help?

@BALAGA-GAYATRI
Copy link
Contributor

@kjyam98, that is not the right assignment

@BALAGA-GAYATRI please assign to udayxhegde

@kjyam98 , @BALAGA-GAYATRI: what are you expecting by assigning to me? did you have a specific design in mind that you need my help?

@udayxhegde
Sorry for the confusion. This was already closed over email. We will be working with the CLI team for the changes required in CLI and in Action for the auto-refresh mechanism for addressing the same. Have assigned back the issue to my team.

@github-actions
Copy link

This issue is idle because it has been open for 14 days with no activity.

@github-actions github-actions bot added the idle Inactive for 14 days label Feb 14, 2022
@lpalerm
Copy link

lpalerm commented Apr 1, 2022

Can this be documented in the federated credentials setup steps? We are having the same issue.

@github-actions github-actions bot removed the idle Inactive for 14 days label Apr 1, 2022
@github-actions
Copy link

This issue is idle because it has been open for 14 days with no activity.

@github-actions github-actions bot added the idle Inactive for 14 days label Apr 15, 2022
@YanaXu
Copy link
Collaborator

YanaXu commented Apr 26, 2023

Hi @BartDecker ,

JFY, I also test with the action part as

      - name: "Test length of token"
        run: |
            Get-AzResourceGroup | Select -First 1
            Write-Host "Sleeping for ${{ matrix.sleep }} seconds.."
            Start-Sleep -Seconds ${{ matrix.sleep }}
            Write-Host "Sleep stop!"
            Get-AzResourceGroup | Select -First 1
        shell: pwsh

No Get-AzAccessToken in the workflow.
And the result is the same.
image

@YanaXu
Copy link
Collaborator

YanaXu commented Apr 26, 2023

$token = Get-AzAccessToken

Hi @YanaXu Yan Xu FTE

Thanks for testing but the test is not valid for the problem. Probably $token = Get-AzAccessToken gets a new token after getting the initial OICD token.

We can have a screen sharing session if yo want. Would be nice to get to the bottom of this as there is some confusion in this discussion every now and than.

See my earlier comments here: #180 (comment)

@BartDecker , It's better to share your workflow file and the related workflow output. If it's not OK to share, please ping me on teams, and we can schedule a meeting. You can find my teams account (mail) on GitHub profile. Thanks.

@BartDecker
Copy link

@YanaXu many thanks for the opportunity to reach out to you on teams.

I have retested and it indeed works as expected.

Some notes for others who run into the same problem:

  • It's not only the az version that belongs to the login step of your job which counts
  • we had several steps that can't use the latest azpwsh version but use azpwsh 7.5.0 These jobs will fail and actually need a re-login before they start.
  • Our 7.5.0 jobs take less than 5 mins which make a re-login work for these steps. It could be that the jobs would fail if it takes longer than 5 mins.

Tested with a workflow consisting out of multiple steps which use : azPSVersion: "latest" for the deployment steps and "AzVersion": "2.12.1" for the login step.

@matsest
Copy link

matsest commented Apr 27, 2023

@BartDecker: indeed works as expected.

Could you elaborate? It would also be helpful if you can share a full workflow definition, preferably with a link to a run as well.

It could be that the jobs would fail if it takes longer than 5 mins.

To me this still seems to be the main issue here.

@YanaXu
Copy link
Collaborator

YanaXu commented Apr 27, 2023

As I can see, there are 2 issues:

  • The token will be expired in 5 min.
    • This is the original issue, and it's fixed in Azure PowerShell v9.2 (released on 12/6/2022).
    • It's also the issue BartDecker mentioned.
  • The token will be expired after 50 min.

鉂椻潡鉂Here are the notes for all:
鉂椻潡鉂桺lease upgrade your Azure PowerShell Modules version to the latest! NOT only the Azure Login Action but ALL actions (if your action runs any Azure PowerShell Module), e.g., Azure PowerShell Action, PowerShell scripts to run Azure PowerShell, ...

@matsest , please kindly check my above question in this comment.

@github-actions
Copy link

This issue is idle because it has been open for 14 days with no activity.

@github-actions github-actions bot added the idle Inactive for 14 days label May 11, 2023
@dionhaefner
Copy link

Has anyone found a workaround for the tokens that expire after ~1h? I guess you could detect that case and run the login action again?

@github-actions github-actions bot removed the idle Inactive for 14 days label May 11, 2023
@BartDecker
Copy link

Has anyone found a workaround for the tokens that expire after ~1h? I guess you could detect that case and run the login action again?

Indeed just a re-login. We look at the average runtime of a workflow and put a re-login at the appropriate point in the workflow. Would be nice if the token time is configurable as part of the login action.

@dionhaefner
Copy link

I ended up just using a shell script login.sh for OIDC login (instead of the login action):

#!/bin/bash
set -e

# get JWT from GitHub's OIDC provider
# see https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#updating-your-actions-for-oidc
jwt_token=$(
    curl \
        -H "Authorization: bearer $ACTIONS_ID_TOKEN_REQUEST_TOKEN" \
        "$ACTIONS_ID_TOKEN_REQUEST_URL&audience=api://AzureADTokenExchange" \
        --silent \
    | jq -r ".value"
)

# perform OIDC token exchange
az login \
    --service-principal -u $AZURE_CLIENT_ID \
    --tenant $AZURE_TENANT_ID \
    --federated-token $jwt_token \
    -o none

az account set \
    --subscription $AZURE_SUBSCRIPTION_ID \
    -o none

Then you can keep track of time in long-running scripts and renew the token every 50 minutes or so.

@surajssd
Copy link

surajssd commented May 17, 2023

Hit this issue on Ubuntu based workflow. We login upfront, then try to do an image build (which runs for 10-15 mins), meanwhile the token is expired and Hashicorp packer fails because the token has expired. It was only valid for 5 mins.

image

Here is the log from that failed step:

...
peer-pod-ubuntu.azure-arm.ubuntu: output will be in this color.

==> peer-pod-ubuntu.azure-arm.ubuntu: Running builder ...
==> peer-pod-ubuntu.azure-arm.ubuntu: Getting tokens using Azure CLI
==> peer-pod-ubuntu.azure-arm.ubuntu: unable to get token from azure cli: Invoking Azure CLI failed with the following error: ERROR: AADSTS700024: Client assertion is not within its valid time range. Current time: 2023-05-17T01:01:18.0483732Z, assertion valid from 2023-05-17T00:45:33.0000000Z, expiry time of assertion 2023-05-17T00:50:33.0000000Z. Review the documentation at https://docs.microsoft.com/azure/active-directory/develop/active-directory-certificate-credentials .
==> peer-pod-ubuntu.azure-arm.ubuntu: Trace ID: 2b484d1e-c5db-483f-9502-c274b6715c00
==> peer-pod-ubuntu.azure-arm.ubuntu: Correlation ID: 97a5e8bf-8386-4f13-8db0-8cc9a18f4fad
==> peer-pod-ubuntu.azure-arm.ubuntu: Timestamp: 2023-05-17 01:01:18Z
==> peer-pod-ubuntu.azure-arm.ubuntu: Interactive authentication is needed. Please run:
==> peer-pod-ubuntu.azure-arm.ubuntu: az login
==> peer-pod-ubuntu.azure-arm.ubuntu:
Build 'peer-pod-ubuntu.azure-arm.ubuntu' errored after 1 second 393 milliseconds: Invoking Azure CLI failed with the following error: ERROR: AADSTS700024: Client assertion is not within its valid time range. Current time: 2023-05-17T01:01:18.0483732Z, assertion valid from 2023-05-17T00:45:33.0000000Z, expiry time of assertion 2023-05-17T00:50:33.0000000Z. Review the documentation at https://docs.microsoft.com/azure/active-directory/develop/active-directory-certificate-credentials .
Trace ID: 2b484d1e-c5db-483f-9502-c274b6715c00
Correlation ID: 97a5e8bf-8386-4f13-8db0-8cc9a18f4fad
Timestamp: 2023-05-17 01:01:18Z
Interactive authentication is needed. Please run:
az login


==> Wait completed after 1 second 393 milliseconds

==> Some builds didn't complete successfully and had errors:
--> peer-pod-ubuntu.azure-arm.ubuntu: Invoking Azure CLI failed with the following error: ERROR: AADSTS700024: Client assertion is not within its valid time range. Current time: 2023-05-17T01:01:18.0483732Z, assertion valid from 2023-05-17T00:45:33.0000000Z, expiry time of assertion 2023-05-17T00:50:33.0000000Z. Review the documentation at https://docs.microsoft.com/azure/active-directory/develop/active-directory-certificate-credentials .
Trace ID: 2b484d1e-c5db-483f-9502-c274b6715c00
Correlation ID: 97a5e8bf-8386-4f13-8db0-8cc9a18f4fad
Timestamp: 2023-05-17 01:01:18Z
Interactive authentication is needed. Please run:
az login


==> Builds finished but no artifacts were created.
make: *** [Makefile:25: podvm-c491ecd-amd64] Error 1
Error: Process completed with exit code 2.

The docs say that the expiry time is configurable. But they don't say how.

This expiration time is further configurable in Azure

@YanaXu
Copy link
Collaborator

YanaXu commented May 31, 2023

Hi @surajssd , have you checked my comment? Have you upgraded all Azure PowerShell versions, including the manually installed one or Azure PowerShell Action?

@surajssd
Copy link

surajssd commented Jun 9, 2023

@YanaXu not using Powershell. Only Ubuntu/Linux based actions.

@YanaXu
Copy link
Collaborator

YanaXu commented Jun 12, 2023

@surajssd , in this issue, we're talking about the Azure PowerShell login issue with OIDC with the service principle. If you do not use Azure PowerShell at all, we are meeting another issue. Let's see what's wrong in your case.
Could you share the workflow with me? You can mask the sensitive information, but let me know which actions and what general parameters you are using.

@mestrada-redstage
Copy link

I have this error when when the build take more that 10 min
image
runner: ubuntu-latest
and use manage identity for login into my AKS cluster

@YanaXu
Copy link
Collaborator

YanaXu commented Jun 29, 2023

@mestrada-redstage, can you share the workflow with us?

@mestrada-redstage
Copy link

@YanaXu This are the steps
steps:

  - name: Checkout
    uses: actions/checkout@v3

  - name: Set env branch short name
    run: echo "BRANCH_NAME=${TRIGGER_GITHUB_REF#refs/heads/}" >> $GITHUB_ENV

  # setup Docker buld action
  - name: Set up Docker Buildx
    id: buildx
    uses: docker/setup-buildx-action@v1

  - name: Login to DockerHub
    uses: docker/login-action@v2
    with:
      registry: ${{ secrets.ACR_URL }}
      username: ${{ secrets.ACR_LOGIN }}
      password: ${{ secrets.ACR_KEY }} 

  - name: Setup anvironemnt name
    run: |
     echo "ENV_STR=${BRANCH_NAME/development/dev}" >> $GITHUB_ENV
     cat $GITHUB_ENV

  - 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/use-kubelogin@v1
    with:
      kubelogin-version: 'v0.0.24'
      
  - uses: azure/setup-kubectl@v3
   
  - uses: azure/aks-set-context@v3
    with:
      resource-group: #########
      cluster-name: #######

  - name: build-deploy
    shell: bash
    run: |
      cd ${{ matrix.PROJECT_PATH }}
      chmod +x ../build.sh
      ACR_URL=${{ secrets.ACR_URL }} ACR_KEY=${{ secrets.ACR_KEY }} ACR_LOGIN=${{ secrets.ACR_LOGIN }} ../build.sh ${{ env.PROJECT_NAME }} ${{ env.TRIGGER_GITHUB_SHA }} ${{ github.event.inputs.destin }} ${{ env.PROJECT_NAME }} ${{ matrix.PROJECT_CONTEXT }}

@YanaXu
Copy link
Collaborator

YanaXu commented Jul 3, 2023

@mestrada-redstage ,

In this issue, we talked about Azure PowerShell login problem with OIDC.
But your workflow seems using Azure Cli.
I think you were talking about this step which failed after 10 min.

  - name: build-deploy
    shell: bash
    run: |
      cd ${{ matrix.PROJECT_PATH }}
      chmod +x ../build.sh
      ACR_URL=${{ secrets.ACR_URL }} ACR_KEY=${{ secrets.ACR_KEY }} ACR_LOGIN=${{ secrets.ACR_LOGIN }} ../build.sh ${{ env.PROJECT_NAME }} ${{ env.TRIGGER_GITHUB_SHA }} ${{ github.event.inputs.destin }} ${{ env.PROJECT_NAME }} ${{ matrix.PROJECT_CONTEXT }}

Could you re-run this workflow with debug mode and copy the workflow's output to us?
And if it's not sensitive, please provide the content of "build.sh" too.
Thanks.

@jbelien
Copy link

jbelien commented Aug 10, 2023

Also hitting the same issue.
Here is the log (with debug):

##[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

Azure/aks-set-context#101

@hansenms
Copy link

I just wanted to chime in here, we are experiencing the same problem that the client assertion expires after 5 minutes and az aks get-credentials is failing in the same way as described above. Other az commands work, so it is possible that the token is not refreshed for that command?

We use a script (along the lines of #180 (comment) by @dionhaefner) right in front of calls to az aks get-credentials in our pipelines to work around this.

@mcolussi-bigw
Copy link

Issue is occurring for us as well. We use null_resource terraform resources to run custom scripts that perform commands via az cli, the automated tests are failing because the token expires after 5 minutes, before the scripts execute.

Our current only work-around is to ensure the tests that run AZ cli commands run first before the token expires. 5 minutes is a very short time range to do anything useful.

@JamesDawson
Copy link

JamesDawson commented Sep 15, 2023

Are there any plans to support idTokens with a lifetime longer than 10 minutes? This constraint has sadly forced us back to using SP authentication with client secrets.

We have a scripted deployment process (i.e. runs as a single GitHub Actions step using azure/powershell@v1) that runs for longer than 10 minutes. It includes functionality towards the end that requires an access token from another service (i.e. a data plane operation), which fails as the idToken has expired.

As a tangible example of this scenario, consider using the Az.Synapse PowerShell module to make configuration changes to a Synapse Workspace that has just been provisioned by a preceding ARM deployment (lasting longer than 10 minutes).

UPDATE: When testing an equivalent repro with the recently announced preview of federated credentials for Azure DevOps, we do not see the same issue.

@YanaXu
Copy link
Collaborator

YanaXu commented Sep 19, 2023

Hi @mestrada-redstage , @jbelien, @hansenms, @mcolussi-bigw , could you open another issue and provide your workflow file and the debug log? Because this issue is about the Azure PowerShell and it's fixed in Azure PowerShell 9.2 as in comment. But in your description, it seems there are other issues in Azure CLI or even other actions. Please open a new issue for your case for better tracking.

@YanaXu
Copy link
Collaborator

YanaXu commented Sep 19, 2023

Are there any plans to support idTokens with a lifetime longer than 10 minutes? This constraint has sadly forced us back to using SP authentication with client secrets.

We have a scripted deployment process (i.e. runs as a single GitHub Actions step using azure/powershell@v1) that runs for longer than 10 minutes. It includes functionality towards the end that requires an access token from another service (i.e. a data plane operation), which fails as the idToken has expired.

As a tangible example of this scenario, consider using the Az.Synapse PowerShell module to make configuration changes to a Synapse Workspace that has just been provisioned by a preceding ARM deployment (lasting longer than 10 minutes).

UPDATE: When testing an equivalent repro with the recently announced preview of federated credentials for Azure DevOps, we do not see the same issue.

@JamesDawson , do you mean the toke generated by GitHub? I think it's out of the scope of this Action. Can you raise an issue for GitHub Action Core?

@YanaXu
Copy link
Collaborator

YanaXu commented Sep 19, 2023

I'll close this issue.

  • If you meet an Azure PowerShell token expiration issue, please refer to comment .
  • If you meet other token expiration issues, please open a new issue for it. Provide your workflow file and debug logs for further analysis.

@YanaXu YanaXu closed this as completed Sep 19, 2023
@jbelien
Copy link

jbelien commented Nov 14, 2023

Hi @mestrada-redstage , @jbelien, @hansenms, @mcolussi-bigw , could you open another issue and provide your workflow file and the debug log? Because this issue is about the Azure PowerShell and it's fixed in Azure PowerShell 9.2 as in comment. But in your description, it seems there are other issues in Azure CLI or even other actions. Please open a new issue for your case for better tracking.

Sure, I already opened an issue here: Azure/aks-set-context#101

@krukowskid
Copy link

krukowskid commented Nov 16, 2023

hey! I am still facing this issue when running dotnet tests in github runner.

Azure.Identity.CredentialUnavailableException : DefaultAzureCredential failed to retrieve a token from the included credentials. See the troubleshooting guide for more information. https://aka.ms/azsdk/net/identity/defaultazurecredential/troubleshoot
...
- Azure CLI authentication failed due to an unknown error. See the troubleshooting guide for more information. https://aka.ms/azsdk/net/identity/azclicredential/troubleshoot ERROR: AADSTS700024: Client assertion is not within its valid time range. Current time: 2023-10-31T11:53:04.4424859Z, assertion valid from 2023-10-31T11:39:49.0000000Z, expiry time of assertion 2023-10-31T11:44:49.0000000Z. Review the documentation at https://docs.microsoft.com/azure/active-directory/develop/active-directory-certificate-credentials . Trace ID: d64c537e-1d94-4274-9012-c0d7590f1c00 Correlation ID: 5c769bb7-e85a-4557-ba28-92f8eca1c4ff Timestamp: 2023-10-31 11:53:04Z
	Interactive authentication is needed. Please run:
	az login

I am using 1.4.6 action version and 1.10.4 of azure.identity package. Problem does not occur on integration tests where almost all of them are using token, but if I am running API/UI tests where I am using identity in one or two tests it looks like token is not being refreshed if its not used for 5minutes. Any ideas or workaround?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working external oidc P1 Some scenario broken but workaround exists product enhancement New feature or request
Projects
None yet
Development

No branches or pull requests