-
Notifications
You must be signed in to change notification settings - Fork 292
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’ll 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
Comments
@kjyam98 @N-Usha @udayxhegde Is this Doable in Azure? |
@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 |
@udayxhegde the problem I’m 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:
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 Example:
|
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 |
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. |
Yes @guidoiaquinti. The refresh token mechanism is yet to be implemented. |
I understand but is there any plan to implement it?
…On Tue, 14 Dec 2021 at 09:51, Balaga Gayatri ***@***.***> wrote:
Yes @guidoiaquinti <https://github.com/guidoiaquinti>. The refresh token
mechanism is yet to be implemented.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#180 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AA6Z3GLBB73XKGBKYRE4XC3UQ4AS3ANCNFSM5I2JEVKQ>
.
|
Yes. But we can't commit to a specific timeline for this right now. We will keep you informed. |
This issue is idle because it has been open for 14 days with no activity. |
@BALAGA-GAYATRI please assign to udayxhegde |
@kjyam98, that is not the right assignment
@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 |
This issue is idle because it has been open for 14 days with no activity. |
Can this be documented in the federated credentials setup steps? We are having the same issue. |
This issue is idle because it has been open for 14 days with no activity. |
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. |
I ended up just using a shell script #!/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. |
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. 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.
|
@YanaXu not using Powershell. Only Ubuntu/Linux based actions. |
@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. |
@mestrada-redstage, can you share the workflow with us? |
@YanaXu This are the steps
|
In this issue, we talked about Azure PowerShell login problem with OIDC. - 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? |
Also hitting the same issue.
|
I just wanted to chime in here, we are experiencing the same problem that the client assertion expires after 5 minutes and We use a script (along the lines of #180 (comment) by @dionhaefner) right in front of calls to |
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. |
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 As a tangible example of this scenario, consider using the UPDATE: When testing an equivalent repro with the recently announced preview of federated credentials for Azure DevOps, we do not see the same issue. |
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. |
@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? |
I'll close this issue.
|
Sure, I already opened an issue here: Azure/aks-set-context#101 |
hey! I am still facing this issue when running dotnet tests in github runner.
I am using |
Any update on this case? This is driving me mad creating Enterprise Applications for our deployments. New-AzADApplication_CreateExpanded: /home/runner/.local/share/powershell/Modules/Az.Resources/6.12.1/MSGraph.Autorest/custom/New-AzADApplication.ps1:698 |
Hi @krukowskid and @jantorep , it's a closed issue. We may miss comments from a closed issue. Please check my comment for this issue. And If your issue is not solved, it means it's a new issue. Please open a new issue then, provide your workflow file, debug log for further analysis. Thanks. |
Utmost respect for the maddest lad @dionhaefner for this comment #180 (comment) Which allowed me to work around this issue in terraform with the following: data "azurerm_client_config" "current" {
}
data "external" "login" {
program = ["bash", "${path.module}/scripts/refresh.sh"]
query = {
client_id = data.azurerm_client_config.current.client_id
tenant_id = data.azurerm_client_config.current.tenant_id
subscription_id = data.azurerm_client_config.current.subscription_id
}
} #!/bin/bash
set -e
eval "$(jq -r '@sh "AZURE_CLIENT_ID=\(.client_id) AZURE_TENANT_ID=\(.tenant_id) AZURE_SUBSCRIPTION_ID=\(.subscription_id)"')"
if [[ "$ACTIONS_ID_TOKEN_REQUEST_TOKEN" == "" ]] || [[ "$ACTIONS_ID_TOKEN_REQUEST_URL" == "" ]]
then
# This is ok, we're probably running locally
jq -n '{}'
exit 0
fi
# 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 "$ACTIONS_ID_TOKEN_REQUEST_URL&audience=api://AzureADTokenExchange" \
-H "Authorization: bearer $ACTIONS_ID_TOKEN_REQUEST_TOKEN" \
--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
jq -n '{}' This allows me to refresh the token in the middle of a long terraform apply in a few places where I need to bust out into a module "auth_refresh" {
source = "../../helpers/azure_auth_refresh"
}
resource "null_resource" "redirect_uris" {
// ...
} |
👋 Hi! I’m using the
azure/login
action for CD and I’m often getting an error when the job execution takes more than a couple of minutes from the initial login.Is there a way to extend the validity of the token via a parameter? The
aws-actions/configure-aws-credentials
action does it via arole-duration-seconds
flag:Thank you! 🙇
The text was updated successfully, but these errors were encountered: