configure-aws-credentials
configure-aws-credentials copied to clipboard
No OpenIDConnect provider found in your account
Had an problem crop up this morning trying to run an action using OIDC auth as described here and wanted to raise an issue in case anyone runs into the same thing:
Action fails with following error:
Error: No OpenIDConnect provider found in your account for https://token.actions.githubusercontent.com
I was able to change my IAM OIDC/role definition to change vstoken.
to token.
and then it authenticated successfully, but I can't seem to find a mention of this change anywhere from Github themselves.
See PR281 for my changes to update the example iam role template
I'm experiencing the same issue. Had to change the url to https://token.actions.githubusercontent.com but unlike you, my authentication step is failing...
@Nirrleybo did you also change the Condition
in the roles AssumeRolePolicyDocument
? It also needs to be changed to token.
, see my commit here.
Making that change in my role template and updating that stack fixed the issue for me.
@mitch-keenan yes sir I did. still no go...
This is the error that I'm getting:
Error: Credentials could not be loaded, please check your action inputs: Could not load credentials from any providers
My job config:
jobs:
plan:
runs-on: ubuntu-latest
name: terraform plan
permissions:
id-token: write
contents: read
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
steps:
- name: Checkout
uses: actions/checkout@v2
- name: Build Role Session Name
id: role-session-name
uses: ./.github/actions/build-role-session-name
- name: Configure AWS read-only credentials
uses: aws-actions/[email protected]
with:
aws-region: eu-west-1
role-to-assume: arn:aws:iam::XXXXXXXXXXXX:role/plan-role
role-duration-seconds: 1800
role-session-name: ${{ steps.role-session-name.outputs.ROLE_SESSION_NAME }}
...
Terraform config:
# READ Policy
# ------------------------------
data "aws_iam_policy_document" "gha_assume_role_policy_document_read" {
statement {
actions = ["sts:AssumeRoleWithWebIdentity"]
principals {
type = "Federated"
identifiers = [aws_iam_openid_connect_provider.githubOidc.arn]
}
condition {
test = "StringLike"
variable = "token.actions.githubusercontent.com:sub"
values = ["repo:${var.org}/${var.repo_name}:*"]
}
}
}
resource "aws_iam_role" "gha_role_plan" {
name = "gha_role_plan"
managed_policy_arns = ["arn:aws:iam::aws:policy/ReadOnlyAccess"]
assume_role_policy = data.aws_iam_policy_document.gha_assume_role_policy_document_read.json
}
BTW, this is working:
- name: Configure AWS
run: |
export AWS_ROLE_ARN=arn:aws:iam::XXXXXXXXXXXX:role/plan-role
export AWS_WEB_IDENTITY_TOKEN_FILE=/tmp/awscreds
export AWS_DEFAULT_REGION=eu-west-1
echo AWS_WEB_IDENTITY_TOKEN_FILE=$AWS_WEB_IDENTITY_TOKEN_FILE >> $GITHUB_ENV
echo AWS_ROLE_ARN=$AWS_ROLE_ARN >> $GITHUB_ENV
echo AWS_DEFAULT_REGION=$AWS_DEFAULT_REGION >> $GITHUB_ENV
curl -H "Authorization: bearer $ACTIONS_ID_TOKEN_REQUEST_TOKEN" "$ACTIONS_ID_TOKEN_REQUEST_URL" | jq -r '.value' > $AWS_WEB_IDENTITY_TOKEN_FILE
- run: aws sts get-caller-identity
Any thoughts?
@Nirrleybo I think you're running into this unrresolved issue
To fix that add these lines at the top level of your job config file:
permissions:
id-token: write
contents: read
and change your action version to
aws-actions/configure-aws-credentials@b8c74de753fbcb4868bf2011fb2e15826ce973af
Thanks @mitch-keenan for this - I've tried it and now I'm getting:
Error: Incorrect token audience
After changing the OIDC url, did you had to change the thumbprint number as well? This is my current setup:
# GitHub Federated Client
# ------------------------------
resource "aws_iam_openid_connect_provider" "githubOidc" {
url = "https://token.actions.githubusercontent.com"
client_id_list = [
"https://github.com/${var.org}/${var.repo_name}"
]
thumbprint_list = ["a031c46782e6e6c662c2c87c76da9aa62ccabd8e"]
tags = {
"Name" = "GitHub"
}
}
I'm looking into this now. GH is still actively developing this feature so there are breaking changes that are happening until they officially GA the capability.
@Nirrleybo I think the audience is sigstore
for now. GH released teh ability to set an arbitrary audience yesterday and I am working on adding that to the action now. When it's done, we will set the audience to sts.amazonaws.com
when redeeming the JWT for AWS credentials.
The issuer returned by a GET
request to https://vstoken.actions.githubusercontent.com/.well-known/openid-configuration
is https://token.actions.githubusercontent.com
. The OpenID configuration endpoint https://token.actions.githubusercontent.com/.well-known/openid-configuration
also returns exactly the same response.
I think it's likely GH changed the host described in the original roadmap issue and forgot to update it. As @richardhboyd mentioned, it's still in beta so some breaking changes are to be expected.
In the meantime, however, I'd suggest updating the documentation of this repo (e.g. the README and example CloudFormation template). Google already updated theirs.
People are generally using 'sigstore' for the default audience, rather than the repo name (as originally described in the roadmap document) and instead using the subject for the repository (because then you can do finer-level controls on a per-role basis instead of the OICD).
It's possible to use a different audience than sigstore if you pass it in the URL; at the moment, it's hard-coded to 'sigstore' here:
https://github.com/aws-actions/configure-aws-credentials/blob/9aaa1daa91b40ce855e24cd45fb39b2ca18aeaf1/index.js#L196
It would be good if that were a parameter you could pass to the job which defaults to sigstore, because then it permits an account's OICD parameter to use something other than the default.
@richardhboyd would you mind taking a look at #285 to allow the audience to be explicitly specified? I've tested this out on my AWS provider and it works as expected. You could then use this to encourage moving to an audience of sts.amazonaws.com and to set the provider up to use that instead -- the problem is, that if you have people who've already set up their OIDC providers to only expect 'sigstore' then changing the default in the code is going to break existing users (which is why #274).
However with #285 you can leave the unspecified default as sigstore
(either new or old way) but allow people to use sts.amazonaws.com
in their jobs/description.
I have a PR submitted to update the default audience to sts.amazonaws.com. Once that's landed we can rebase this PR for allowing customers to modify the audience.
Would it be worth doing it the other way around, and rebasing your change on top of this one? Then instead of changing the default (which will break existing clients) you could simply default it to 'sigstore' and then encourage (in documentation, getting started guides etc.) to explicitly put "audience: sts.amazonaws.com" instead?
The problem is you'll get people who've been using this work-in-progress who've set up a single OpenID connect provider assuming 'sigstore', and if you change the default without any way of modifying it -- and they're using master -- then they'll immediately start failing.
I've updated the answer at https://stackoverflow.com/questions/69243571/how-can-i-connect-github-actions-with-aws-deployments-without-using-a-secret-key/69243572#69243572 to show how to define an OpenID Connect provider which will accept both 'sigstore' and 'sts.amazonaws.com', along with a role that will trust either of them as well. Happy to submit a doc PR if you'd like me to expand the examples here?
We don't want the default to be sigstore because it poses a risk of causing a confused deputy problem. This change hasn't been officially released yet (in the v1 tag) so the only people who have taken a dependency on it are people who have explicitly set their action to either master
or pinned to a specific commit.
@Nirrleybo I think the audience is
sigstore
for now. GH released teh ability to set an arbitrary audience yesterday and I am working on adding that to the action now. When it's done, we will set the audience tosts.amazonaws.com
when redeeming the JWT for AWS credentials.
changing audience to sigstore
seemed to have done the trick.
If you are suddenly receiving an Incorrect token audience
error, this change has required the audience be changed from sigstore
to sts.amazonaws.com
(as previously commented).
This issue seems it was from before the feature became available. Closing out, ping if you feel this was in error.
⚠️Comment Visibility Warning⚠️
Comments on closed issues are hard for our team to see. If you need more assistance, please either tag a team member or open a new issue that references this one. If you wish to keep having a conversation with other community members under this issue feel free to do so.
@richardhboyd @mitch-keenan , I am using AWS Private cloud/VNET for OIDC. For me I tried all ways and trust json etc looks all good but still getting the same error, any other clue for me? Tried with v2 also but same error. Added in workflow this part also: permissions: id-token: write contents: read
aws-actions/configure-aws-credentials@v1 Error: No OpenIDConnect provider found in your account for https://token.actions.githubusercontent.com/
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::xxxxxxxx:oidc-provider/token.actions.githubusercontent.com"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringLike": {
"token.actions.githubusercontent.com:aud": "sts.amazonaws.com",
"token.actions.githubusercontent.com:sub": "repo:user/repo-name:*"
}
}
}
]
}
Do we have any other alternative GitHub action to try for AWS using OIDC ?
@newfunda Have you created an identity provider in your AWS account? See here