Gamelift Fleet Instance does not have permission to assumeRole on a gamelift-principal Role anymore.

1

Hi! I'm currently running a secondary process on gamelift instances to help with server log gathering. This process needs some AWS permissions, which it acquires by doing an assumeRole on the fleet's InstanceRole. This instanceRole is setup with the following trust policy :

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": [
                    "gamelift.amazonaws.com"
                ]
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

I haven't been monitoring that logging process very closely, and recently discovered that it wasn't able to assume this role anymore. I've been trying to specify the gamelift region, to no avail. The only way I was able to re-assume the role from the instance was to get the instance's role through get-caller-identity (after ssm-ing on the instance), and adding this auto-generated role to the trust policy by hand.

Here's the error that happens when attempting to assume-role from the gamelift fleet:

sh-4.2$ aws sts assume-role --role-arn=arn:aws:iam::<accountId1>:role/the-role-i-want-to-assume --role-session-name=testassumesession
An error occurred (AccessDenied) when calling the AssumeRole operation: User: arn:aws:sts::<accountId2>:assumed-role/DevAppStack-58eee978-59ae-42a0-9a8-AppInstanceRole-EDM3O84AF9S0/i-09dbb0c0bde30b348 is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::<accountId1>:role/the-role-i-want-to-assume

I'm kind of in the dark about what the default "assumed-role" we see here really is: I presume it's a default AWS account that represents gamelift, but I'm not too sure about it ?

Any ideas why the assumeRole doesn't work anymore, or ideas of things to try out ? Thanks !

3 Answers
1

Hi! It totally makes sense, but what if the caller is not a game server but a "sidecar" process running on the instance for example for log gathering purposes?

I assumed, looking at the Server SDK interactions that it was only meant for processes that are hosting game sessions.

answered 9 months ago
  • You need to make the API call from your server process that uses the ServerSDK in order to get the credentials; however, any process on your box can use those credentials, you just need to provide it from your main server process

  • "you just need to provide it from your main server process" What does this line mean? How do you provide credentials retrieved from GetFleetRoleCredentials to cloudwatch agent from the main process? Do we need to set environment variables? What if you have chosen to run 50 concurrent processes?

  • Hey juego-studios,

    The implementation details would be up to your discretion. If you've set your fleet's runtime configuration to 50 concurrent processes, this means you will have up to 50 main server processes running on the instance, all of which have the option to call GetFleetRoleCredentials.

    If I did not answer your question, feel free to clarify as I must have misunderstood.

1

Hello,

When running an SDK 5 fleet, you should call the ServerSDKAPI GetFleetRoleCredentials() and use those credentials to assume your role.

Regards,

AWS
answered 9 months ago
-3

Hello there,

Your trust policy shows that the service "gamelift.amazonaws.com " is the only allowed principal that can assume the target role.

According to the access denied error, the role DevAppStack-58eee978-59ae-42a0-9a8-AppInstanceRole does not have the sufficient permissions to assume the next role.

There are 2 requirements to assume a role successfully, the instance role needs the sts:AssumeRole permissions and the ARN of the instance role needs to be explicitly defined in trust policy of the role that is being assumed. [1]

To resolve your issue, I suggest confirming that the trust policy of the role that is being assumed to include the ARN of the instance role DevAppStack-58eee978-59ae-42a0-9a8-AppInstanceRole as an additional principal for role assumption. Furthermore, evaluate that your instance role has the sts:AssumeRole permissions attached.

Sample trust policy: arn:aws:iam::Account-ID:role/the-role-i-want-to-assume:

{ "Version": "2008-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::Account-ID:role/DevAppStack-58eee978-59ae-42a0-9a8-AppInstanceRole-EDM3O84AF9S0" }, "Action": "sts:AssumeRole" } ] }

Sample IAM policy for Instance role: arn:aws:iam::Account-ID:role/DevAppStack-58eee978-59ae-42a0-9a8-AppInstanceRole-EDM3O84AF9S0:

{ "Action": "sts:AssumeRole", "Resource": "arn:aws:iam::Account-ID:role/the-role-i-want-to-assume", "Effect": "Allow" }

N.B. Please ensure that the ARN's in the sample trust policy is replaced with the correct ARN for your instance role i.e. with the correct account number, etc.



If further assistance is required to troubleshoot a specific error received, may I recommend opening an Internal Ticket with AWS Support for further assistance

References: [1] https://repost.aws/knowledge-center/iam-assume-role-cli

Yalka
answered 9 months 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