Deploy Cabana's assets to an AWS account with OIDC authentication, no saved credentials

[dnaphas-vri]

Use https://github.com/VerticalRelevance/aws-github-oidc to ensure that an OIDC Provider is present in the account.

[douglasnaphas]

TODO

• Get an AWS org to test in. https://dsns-a.awsapps.com/start for now.
• Make a Cabana OU and account in the test org.
• Deploy the Provider from VerticalRelevance/aws-github-oidc to the test account.
• Set up whatever resource(s) complement the OIDC Provider in this repo.
  • Add getProviderArn to VerticalRelevance/aws-github-oidc, or to this repo.
  • Make VerticalRelevance/aws-github-oidc's got1 command available via npx by publishing it as a package on GitHub. Consume VerticalRelevance/aws-github-oidc's library function(s), including 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.
  • Check for org, repo, and filter (branch) in infra/bin, so that I can supply them to the RoleStack. Use the same environment variable names that GitHub Actions uses.
  • Supply the Provider ARN and the subject to the RoleStack in infra/bin.
• Try to get aws-actions/configure-aws-credentials to take a dynamically determined role name
• Remove unnecessary changes here, to aws-github-oidc, and to setty, that were added when I was trying to get TypeScript importing to work.
• Output the account that the role is in from the Action (the role is secret)

[douglasnaphas]

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.

[douglasnaphas]

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.

[douglasnaphas]

A role per branch is fine, actually.

[douglasnaphas]

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"
    }
}

[douglasnaphas]

I fixed the above by changing my condition on the aud claim from sts.amazon.com to sts.amazonaws.com.

[douglasnaphas]

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.

[douglasnaphas]

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.

[douglasnaphas]

Resources deployed, closing.