- 新しい順
- 投票が多い順
- コメントが多い順
Hi @meoporter,
There are 2 concepts here:
-
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. -
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?
- 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
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.
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
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
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.
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.