How would i assume a role?

[samsen1]

We want to be able to deploy serverless via our self hosted runners using Github Actions. Our runners run in one account and we want to be able to deploy to other accounts (e.g. dev, staging and prod). Each environment reside in their own AWS account. As a test, i created a role/policy in our dev account but I'm encountering an error that shows the following:

User: arn:aws:sts::<ACCOUNT_ID_GH_RUNNERS>:assumed-role/<ROLE>/c382a7d48148456baecac78556315651 is not authorized to perform: cloudformation:DescribeStacks on resource: arn:aws:cloudformation:us-east-1:<ACCOUNT_ID_GH_RUNNERS>:stack/service-name-dev/*

As noted above, it's trying to create the resources within the account where the Github Runners are located and not in the intended environment (dev). I can't for the life of me figure out how to make it use the role I specify. See below

service: serverless-alert-notifier

plugins:
  - serverless-plugin-datadog
provider:
  name: aws
  runtime: nodejs12.x
  stage: ${opt:stage, self:custom.defaultStage}
  iam:  
    role: arn:aws:iam::<ACCOUNT_ID_DEV>:role/<ROLE_TOASSUME>

[pgrzesik]

Hello @samsen1 - the iam.role setting is for setting the role that will be used by your deployed Lambda functions. If you want to use different role during actual deployment, you should be using provider.iam.deploymentRole.

[pgrzesik]

What is the role that is listed in the error message though? Is that the role that is assigned to the runner?

[samsen1]

Yes it is. The role i listed within the deploymentRole is the one I want serverless to assume. Our other CI/CD jobs work fine when we can assume a role, i'm looking for the same functionality with serverless.

[samsen1]

The role we assign the runners has one of these policies.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "",
            "Effect": "Allow",
            "Action": [
                "iam:PassRole",
                "iam:GetRole"
            ],
            "Resource": "*"
        },
        {
            "Sid": "",
            "Effect": "Allow",
            "Action": [
                "sts:AssumeRole",
                "sts:TagSession"
            ],
            "Resource": "arn:aws:iam::*:role/github-actions-assume-role"
        }
    ]
}

As stated, i pin this role arn:aws:iam::<ACCOUNT_ID_DEV>:role/github-actions-assume-role to deploymentRole but no dice.

[pgrzesik]

Hey @samsen1 - I did some digging and I've noticed that the role will be used, but only during actual stack update/create operations, but not when calling SDK directly e.g. when checking the stack existence or resolving variables, which might be confusing and cause potentially nasty bugs if that's what is expected. I'll bring it up internally and see what we could do with that - in the meantime, the workaround for you would be to assume the role via AWS CLI and exporting the access/secret keys as a part of your Github Actions job

[pgrzesik]

Hey @samsen1 - thanks for the patience on this one. We've discussed that a bit and will make some clarification in the docs on how the deploymentRole is applied - the naming might be a bit misleading there, but it's intention is to only be passed to be assumed by CloudFormation.

In order to override the credentials for all operations, you should configure the AWS credentials - either via env vars or via credentials configuration. To see how to configure role, you can check out this - https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-role.html. In your case probably using default profile with specified role would be the best

[serverlesspolska]

Hey @pgrzesik,

Do you know if this issue was fixed?

Also, in the whole documentation, there is only a single place where provider.iam.deploymentRoleis shown:
https://www.serverless.com/framework/docs/providers/aws/guide/serverless.yml#iam-permissions

Docs search on the page does not find it :-(

[pgrzesik]

Hey @serverlesspolska 👋 I'm not 100% sure, but I'm afraid it was not fixed :(

[pide2000]

It's not fixed and that makes things unnecessarily inconvinient.