Problem with using assumed roles to deploy

I am struggling with how best to resolve a problem I’ve run into. Following AWS best practices, we have no named users in our accounts, and instead log in with a role that has permissions to assume other roles for each account we need access to.

So we use “gimme-aws-creds” (see to authenticate into the default role, and then run all aws commands with the “–profile” that we need for each account (in this case wf-web).

We have a ~/.aws/config file that has the profile for wf-web like:

[profile wf-web]
source_profile = cloud-admin
role_arn = arn:aws:iam::xxxxxxxxx:role/admin

and the gimme-aws-creds writes the temporary creds into the credentials file so that the assume role works.

The problem appears to be that when running sls, it tries to find the “wf-web” in the ~/.aws/credentails file instead of looking in the config as expected, so I get an error like:

RobWeaver:TrialAccountProvisionService robweaver$ sls deploy --stage=dev --aws-profile wf-web
Serverless: Packaging service...
Serverless: Excluding development dependencies...
Serverless: Creating Stack...
  Error --------------------------------------------------
  Profile wf-web does not exist
     For debugging logs, run again after setting the "SLS_DEBUG=*" environment variable.
  Get Support --------------------------------------------
  Your Environment Information -----------------------------
     OS:                     darwin
     Node Version:           10.0.0
     Serverless Version:     1.27.3

Have you tried:

source_profile = cloud-admin
role_arn = arn:aws:iam::xxxxxxxxx:role/admin

None of the profiles in my ~/.aws/credentials file have "profile " in front of the profile name.

The [profile wf-web] is in the config file not the credentials one, I will give that a try.

Still think this is a bug in the fact that the aws cli allows me to use the --profile, but the --aws-profile seems to be only looking in the credentials file.

Appears that copying the section to the ~/.aws/credentials file (removing the profile part) does work, so my guess is that the sls is not using both files the way the aws CLI does.

copying the source_profile bit into the credentials is my workaround.

Can we log this as a bug?

Bugs should be logged at

Opened new issue

1 Like