I sent the following proposal out, and the resulting discussion is linked below:


I'd like to add the chromeos.bot service account to the chromeos.int.bot editors list.

This would give the chromeos.bot service account access to everything internal. In general, this is what we've always done with "chromeos.bot@gmail.com", but would be a bit more comprehensive.

This is driven by the desire to start using service accounts for authentication from GCE bots, instead of the chromeos.bot@gmail.com .boto file. This makes GCE instances that much more self-managing, and so is a generally good thing.

I'm just afraid that I'll open up more than I intend to an external builder.

I can just add the account to bucket after bucket as needed, but there are risks that this won't always work because bucket level ACL changes don't always apply at the file level (GS ACLs are a bit weird).



This solution was discussed here:

https://groups.google.com/a/google.com/forum/?utm_medium=email&utm_source=footer#!msg/chromeos-infra-discuss/N5H4vY8G3gM/zEBDvsA4AwAJ

I'm attempting the rambi-release (cros254-c2) without a .boto file.

We saw more failures last night. Switching back to .boto until I can sort them out.

https://uberchromegw.corp.google.com/i/chromeos/builders/rambi-release/builds/635

This issue is a little different now, since we are using ccompute and managing GCE instances with puppet.

Now that IAM is in place, it would be easy to correctly grant the correct permissions to the service account.

But... on reflection, we don't want to have two different accounts to manage, so not fixing until after we can get rid of our physical builders.