1548556 - Give SimonSapin read-only access to some parts of taskcluster aws account

Status: RESOLVED FIXED

(Taskcluster :: Operations and Service Requests, task)

Description

[Simon Sapin (:SimonSapin)]

Scenario:

While working on bug 1546777 I make a new AMI, configure it in the aws-provisioner/servo-win2016-staging worker type definition, and create a new task to try it. The task stays stuck in the Pending state, although the EC2 Resources page shows one instance running. This is fairly typical on the first try after messing with an AMI. generic-worker is probably not running because I got some detail of its configuration wrong, and the instance has a log file that explains what.

This AMI is configured to accept RDP connections and I have the administrator password. But I don’t know the instance’s IP address, so I can’t connect to it and see the log file. The Resources page has a link to the AWS console for each instance, but I don’t have access to that. At this point my options are:

• Stare at the code, try to guess what went wrong, and make changes blind. Building a new AMI takes ~15 minutes, so this gets tedious very quickly.

• Find a colleague who has access to the AWS console with the Taskcluster team’s account and is available on IRC, and bother them to get the instance IP address. Do this several times, since even with logs fixing the problem might take a few rounds of trial and error.

• Hacks hacks hacks to smuggle the IP address out of new instances (such as baking in the AMI a startup script that makes an HTTP request to a server where I have access to HTTP logs)

---

Could an IP address column be added next to Instance Id on the EC2 Resources pages of aws-provisioner? I don’t know if IP addresses are considered sensitive information, but this page is already limited to logged-in users with some appropriate scopes.

Alternatively, should everyone responsible for a worker type on aws-provisioner have access to the corresponding AWS console? Can we find an appropriately-limited set of AWS permissions, perhaps nothing but a read-only view of EC2 instances?

Comment 1

[Simon Sapin (:SimonSapin)]

Between the two proposed approaches I would prefer the former. When doing this type of work I might also need to use the AWS console with a Servo team account, and juggling two AWS accounts doesn’t sound fun.

Comment 2

[Brian Stack [:bstack]]

aws provisioner is EOL and not getting any updates. I think the easiest thing to do here would be to get you read-only access to some parts of the taskcluster aws account. Give me a bit to figure out what the proper level of access is to unblock you.

Comment 3

[Brian Stack [:bstack]]

I would like to give simonsapin a user with the group AmazonEC2ReadOnlyAccess. This gives the following permissions:

Does that make sense to you in this context, ajvb?

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "ec2:Describe*",
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": "elasticloadbalancing:Describe*",
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "cloudwatch:ListMetrics",
                "cloudwatch:GetMetricStatistics",
                "cloudwatch:Describe*"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": "autoscaling:Describe*",
            "Resource": "*"
        }
    ]
}

Comment 4

[AJ Bahnken [:ajvb] (she/her)]

:bstack - yep, could you also include perms for simon to set up MFA on his account?

Comment 5

[Simon Sapin (:SimonSapin)]

I was able to set up MFA on this new account, and use it to find the IP address of an instance and make progress on bug 1546777. Feel free to mark this bug as resolved when you’re happy with the permissions.

Comment 6

[Simon Sapin (:SimonSapin)]

Though it is unfortunate that this access given to me personally rather through some Taskcluster scope that we can give to everyone on the Servo team.

Comment 7

[Brian Stack [:bstack]]

We'll make sure to try to expose useful debug information in whatever worker-manager bits support this sort of work!