"Credentials could not be loaded" issue

[chenrui333]

It looks like it happens more often than before. Not quite sure what would be the workaround solution for it.

[strongishllama]

I'm getting the same issue, and it always seems whenever I re-run the jobs manually the issue goes away.

[callum-tait-pbx]

Having the same problem here, any news of an official workaround? Re-running the job doesn't fix it for me. This is a major issue for us. Raised on the SDK too to hopefully get a better idea about when this error could potentially be triggered.

EDIT

So I assume this error means the SDK failed to find credentials on any of the credential sources listed in this link in the order provided (I assume the SDKs are consisnt with this regardless of language)
https://docs.aws.amazon.com/sdk-for-java/v1/developer-guide/credentials.html

EDIT

Context, we are using this action on an EKS cluster with IRSA, the role is successfully bootstraps and the $AWS_WEB_IDENTITY_TOKEN_FILE env variable is present on the pod:
AWS_WEB_IDENTITY_TOKEN_FILE: /var/run/secrets/eks.amazonaws.com/serviceaccount/token

[paragbhingre]

Thank you for reporting this issue, we have started to take a look into it. We will update you as soon as we find a solution/workaround for this issue.

[callum-tait-pbx]

😳😳😳 this occured for me due to workflows being assigned to incorrect runners due to a misconfiguration on our side. Workflows were being assigned to some Mac minis instead of our Linux machines.

Apologies!!!!!!!! Please ignore my comments 😳.

[lharress]

We were having this issue as well, it may be related to the Github secrets and read-only token changes. There is more details in this article.

Basically Github secrets are no longer visible to pull requests coming from forks, in addition the GITHUB_TOKEN is read only. There are settings to turn those permissions back on but it depends on individual circumstances for the risks. In our case Dependabot is considered a "fork" and you can now provide secrets just for Dependabot.

[piradeepk]

@chenrui333 thanks for reaching out, I had a couple questions that would help us to debug your issue.

Are you able to get it to succeed at any point, or is it consistantly failing all the time? Also, based on the previous comment, are you using a fork which has Github Secrets defined in the parent repo, or does your repo itself have the secrets defined? Which Secrets do you have defined (I'm just looking for the Secret Keys, not the actual secret values)?

[strongishllama]

@piradeepk It sounds like my issue (and likely @chenrui333's too) has to do with the changes @lharress mentioned. If anyone else having the same issue and is wondering how to add secrets to Dependabot, check out this GitHub blog post.

[paragbhingre]

@chenrui333 are you still facing this issue? Is it intermittent or continuously occurring?

[johnpeb]

@paragbhingre this is happening for me for 100% (or almost 100%) of the builds triggered by dependabot PRs but never happens for builds I trigger through a push/UI. Also if I re-run failed dependabot PR build this doesn't happen either.

[piradeepk]

@johnpeb it sounds like this comment/article may be the issue that's impacting you. If you could try suggestions in this article, and let us know if you're still having issues.

[johnpeb]

Thanks. I spent too long searching how to configure this - here's where it is:

[paragbhingre]

Looks like this issue is occurring because of changes mentioned in this article. Closing this issue for now. Feel free to reopen if required.

[chenrui333]

I am gonna check the above suggestions, yes, this is only happened for me with dependabot PRs.

[marcus-vw]

I had the same Problem, see #202

My problem was caused by a Dependabot changed.
All Dependabot Pull Requests are now handled like they were from forks which means you can't access any secrets. This will apply to all actions inside a workflow.

dependabot/dependabot-core#3253 helped my to solve my problem. Hopefully it will spare some time for somebody having the same issue.

[martinschaef]

I get this error message when I do a pull request from a fork:
https://github.com/awslabs/smithy/runs/4418821072?check_suite_focus=true
The role has a trust relationship with awslabs/* (e.g., here is an example where it works) and with martinschaef/*(here is an example where it works), but on the Pull Request between the repos is seems to always fail:
example 1, example 2.

[richardhboyd]

Was the role set up to use OIDC? Can you share that configuration?

[martinschaef]

The role was set up using this stack: https://github.com/aws-samples/aws-codeguru-reviewer-cicd-cdk-sample
and the trust relationship looks as follows:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::048169001733:oidc-provider/token.actions.githubusercontent.com"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringLike": {
          "token.actions.githubusercontent.com:sub": [
            "repo:aws/*:*",
            "repo:awslabs/*:*",
            "repo:aws-samples/*:*",
            "repo:martinschaef/*:*"
          ]
        }
      }
    }
  ]
}