VerticalRelevance / cabana

An application for managing pools of AWS accounts.
Apache License 2.0
0 stars 0 forks source link

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

Closed dnaphas-vri closed 1 year ago

dnaphas-vri commented 1 year ago

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

douglasnaphas commented 1 year ago

TODO

douglasnaphas commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

A role per branch is fine, actually.

douglasnaphas commented 1 year ago

Not sure what to do about this.

Error: Not authorized to perform sts:AssumeRoleWithWebIdentity

"An unknown error occurred"

Screenshot 2023-08-09 at 2 14 03 PM

Screenshot 2023-08-09 at 2 11 39 PM Screenshot 2023-08-09 at 2 11 52 PM Screenshot 2023-08-09 at 2 12 19 PM

{
    "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 commented 1 year ago

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

douglasnaphas commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

Resources deployed, closing.