Closed dnaphas-vri closed 1 year ago
getProviderArn
to VerticalRelevance/aws-github-oidc, or to this repo.got1
command available via npx
by publishing it as a package on GitHub.containsGitHubProvider
, in this repo, using the pattern established with this repo's ts
package and setty.getProviderArn
in infra/bin
, so that I can supply it to the RoleStack.infra/bin
, so that I can supply them to the RoleStack. Use the same environment variable names that GitHub Actions uses.subject
to the RoleStack in infra/bin
.When I add the Conditions to the Role that my Provider will assume, similar to these:
"Condition": {
"StringEquals": {
"token.actions.githubusercontent.com:aud": "sts.amazonaws.com",
"token.actions.githubusercontent.com:sub": "repo:octo-org/octo-repo:ref:refs/heads/octo-branch"
}
}
I can determine the org (octo-org
) and the repo octo-repo
from the environment variables available to GitHub Actions. They won't need to be manually updated in each repo. They will always be for the current org, and the current repo. The filter (refs/heads/octo-branch
) can vary based on whether it's the main deployment action or a feature branch deployment. I may be able to determine the current branch and the default branch for the repo using Git commands and GitHub Actions variables.
Do I need to make sure that the role exists when they deploy the app stack? I think not. I think Rolename or equivalent consistent logic (maybe stackname("role") plus querying the output) will make sure that I can use the same name when I deploy it and when I refer to it in the Action (same repo). I need to revisit the process of having one step in my Action where I figure the role name and one step (the Marketplace OIDC Action, configure-credentials or whatever) where I specify it.
Should the role stack be in a separate app in the same repo?
One role per repo (org and repo name), right? Not one per branch? It would be annoying to have to run a CLI command to deploy the role once once for every branch.
A role per branch is fine, actually.
Not sure what to do about this.
Error: Not authorized to perform sts:AssumeRoleWithWebIdentity
"An unknown error occurred"
{
"eventVersion": "1.08",
"userIdentity": {
"type": "WebIdentityUser",
"principalId": "arn:aws:iam::105379901447:oidc-provider/token.actions.githubusercontent.com:sts.amazonaws.com:repo:VerticalRelevance/cabana:ref:refs/heads/master",
"userName": "repo:VerticalRelevance/cabana:ref:refs/heads/master",
"identityProvider": "arn:aws:iam::105379901447:oidc-provider/token.actions.githubusercontent.com"
},
"eventTime": "2023-08-09T17:58:17Z",
"eventSource": "sts.amazonaws.com",
"eventName": "AssumeRoleWithWebIdentity",
"awsRegion": "us-west-2",
"sourceIPAddress": "40.75.123.241",
"userAgent": "aws-sdk-nodejs/2.1396.0 linux/v16.16.0 configure-aws-credentials-for-github-actions promise",
"errorCode": "AccessDenied",
"errorMessage": "An unknown error occurred",
"requestParameters": {
"roleArn": "arn:aws:iam::105379901447:role/sVcmas-bbd933-role-GitHubRoleECD51173-89CYB55967ID",
"roleSessionName": "GitHubActions",
"durationSeconds": 3600
},
"responseElements": null,
"requestID": "5d1f77eb-b21e-4728-9eb2-76321690ddc4",
"eventID": "cad771e1-5ea0-495b-85a8-8dd6da571b19",
"readOnly": true,
"resources": [
{
"accountId": "105379901447",
"type": "AWS::IAM::Role",
"ARN": "arn:aws:iam::105379901447:role/sVcmas-bbd933-role-GitHubRoleECD51173-89CYB55967ID"
}
],
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "105379901447",
"eventCategory": "Management",
"tlsDetails": {
"tlsVersion": "TLSv1.2",
"cipherSuite": "ECDHE-RSA-AES128-GCM-SHA256",
"clientProvidedHostHeader": "sts.us-west-2.amazonaws.com"
}
}
I fixed the above by changing my condition on the aud
claim from sts.amazon.com
to sts.amazonaws.com
.
I think I need to do this. I need to figure out the role name in one step, then write it to a GITHUB_ENV file so I can use it in the configure-credentials step.
Update: Based on this example, GITHUB_ENV might not work, since I need to use the value in with
, not run
.
I could just have people deploy the role stack from the CLI, and save like PROD_ROLE
, TEST_ROLE
, DEV_ROLE
(per-branch basis) in Secrets or variables. At least we wouldn't be committing ARNs to the source.
Resources deployed, closing.
Use https://github.com/VerticalRelevance/aws-github-oidc to ensure that an OIDC Provider is present in the account.