GreenGrass is not authorized to assume the Service Role

0

Hello,

I am trying to follow the official Greengrass setup guide on Raspberry Pi.

Everything seems to have installed fine so far. I used a permanent user id and access key to run the gg-device-setup-latest.sh script, and then set up a systemd script that runs the core daemon on start.

I have opened up the TCP ports 8883, 8443 and 443 on the Pi, just in case, as well as a port to SSH into it.

I am able to use the AWS CLI on another machine to run aws greengrass get-service-role-for-account, to verify that the Greengrass role is activated on the account. I manually attached it to the created Greengrass group on the AWS web console, and it has the AWSGreengrassResourceAccessRolePolicy policy in it.

But.. every time I have attempted to click deploy in the web console, I see this printed: "GreenGrass is not authorized to assume the Service Role associated with this account". I tried rebooting the Pi, but that did not help. Made sure the Greengrass group is in us-east-1, which is where the CLI told me the service role was associated.

No idea how to get past this.

Thank you.

asked 4 years ago1271 views
5 Answers
0
Accepted Answer

Hi @meoporter,

There are 2 concepts here:

  1. Greengrass Service Role
    This is the role you grant AWS Greengrass to assume to access resources in your AWS account. It allows Greengrass group deployments to succeed. Service role association is done at the account level per region.

  2. Greengrass Group Role
    This is the role you associate for each of your Greengrass group. It is used and assumed by lambdas within that group to access other AWS services. This association is done at the group level.

The error "Greengrass is not authorized to assume the service role" indicates that your Greengrass Service Role might not be correctly configured. Can you try and confirm the following?

  1. With AWS CLI, run the following:
aws greengrass get-service-role-for-account --region <YOUR_REGION>

Check if you have associated a service role for your account in that region. If yes, you should be able to see something like "arn:aws:iam::<ACCOUNT_ID>:role/service-role/<ROLE_NAME>". Note down the role arn/name.
2. With AWS CLI, run the following:

aws iam get-role --role-name <ROLE_NAME> --region <YOUR_REGION>

You should be able to see an output similar to the following:

{
    "Role": {
        "Path": "/",
        "RoleName": "ROLE_NAME",
        "RoleId": "ROLE_ID",
        "Arn": "arn:aws:iam::<ACCOUNT>:role/<ROLE_NAME>",
        "CreateDate": "2019-12-27T18:38:54Z",
        "AssumeRolePolicyDocument": {
            "Version": "2012-10-17",
            "Statement": [
                {
                    "Effect": "Allow",
                    "Principal": {
                        "Service": "greengrass.amazonaws.com"  <--- Check here
                    },
                    "Action": "sts:AssumeRole"
                }
            ]
        },
        "MaxSessionDuration": 3600
    }
}

Verify if the statement allows Greengrass service principal to assume role.

Thanks,
Liusu

answered 4 years ago
  • Hi.

    In my case, I pass both steps you recommended above, yet unable to progress and still have:

    com.aws.greengrass.tes.CredentialRequestHandler: Error in retrieving AwsCredentials from TES. {iotCredentialsPath=/role-aliases/GreengrassV2TokenExchangeRoleAlias/credentials, credentialData=TES responded with status code: 400. Caching response. {"message":"Unable to assume the role, or the role to assume does not exist"}}

    The role as well as the alias exists in role-aliase of IoT Core menu, as well as role in IAM menu.

0

Hello,

As an update, I had previously been trying with or without having a Role attached to the Greengrass group in us-east-1.. could not get past this error.

Then, I switched to us-west-2, and downloaded new certs and a new config.json to the Pi. And WITHOUT having a Role attached, and it DID successfully deploy in the web console!

Neither of these behaviors is making much sense to me. I do not understand why us-east-1 was having issues with the Role, or why us-west-2 could deploy without a Role.

Thank you.

answered 4 years ago
0

Hi meoporter,

The service role is region specific. The console tries to be helpful and create it for you if it doesn't exist.
See: https://docs.aws.amazon.com/greengrass/latest/developerguide/service-role.html#manage-service-role-console

You can also see the error in the Troubleshooting guide.
https://docs.aws.amazon.com/greengrass/latest/developerguide/gg-troubleshooting.html

If you have any questions or if the problem persists, please let us know.
Thanks,
KR-AWS

AWS
KR-AWS
answered 4 years ago
0

Hi KR-AWS,

Yes the attachment of the role appears to be region specific. The roles themselves appear under global IAM console.

However, in us-east-1, for the Greengrass group I created, with or without a role attached, the deployment fails.

In us-west-2, setting up a Greengrass group without any role attached, I was able to get this Greengrass group to deploy.

This does not make any sense.

Thank you

answered 4 years ago
0

Hi LiusuZ,

I had thought Greengrass Group Role controlled the Deploy functionality. Thank you for clarifying that it is independent.

I must have had an old or non-existent role associated with my account in the us-east-1 region. Once I started over, creating the role, and then associated it with the region again, overwriting the earlier association.. Deploy worked.

Thank you for your detailed reply.

answered 4 years ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions