As the author of the request my consent is implicit, but I will make it explicit as well. @Krenair has been a great contributor to the larger Cloud-Services operations over the years and I look forward to having him help us with even larger and more sensitive tasks.

Adding SRE-Access-Requests tag as well because I'm not 100% certain if the NDA needed is just L2 or if the Cobblestone process is required.

I appreciate the thoughtfulness that went into this assessment, this has my signoff.

In T218448#5028665, @bd808 wrote:

Adding SRE-Access-Requests tag as well because I'm not 100% certain if the NDA needed is just L2 or if the Cobblestone process is required.

The NDAs listed in Cobblestone are all linked to either NDA-level access to LDAP or to SSH access to the production and given that neither applies here, I think L2 is sufficient here.

Removing SRE-Access-Requests tag. Consensus from off task inquiries is that L2 is all that is needed at this time.

Ok, I've signed L2.

May I ask to clarify what "Cloud-wide root" means? Maybe it is clear for everyone, but not to me. For example, would someone with those privileges have root access to wikireplicas toolsdb (which is on vms, but it is part of cloud support, at least logically)?

Sorry, I mean toolsdb, not wikireplicas.

I'm not familiar with wikireplicas on VMs (I was under the impression that the DB replicas were on physical hardware without any virtualisation, but maybe that changed or you're referring to something else?) but I'll try to answer the question.
Edit: I see the question is now about toolsdb which I have even less idea about. Hopefully this comment still helps understand.
In my case it'll be the ability to control the new WMCS central puppetmaster (and also other things in the same project, known as cloudinfra) which I intend to try to set up and which will be inside the labs realm, it inherently gives you root access to all VMs which use that puppetmaster (so basically everything in the 'labs'/.wmflabs realm - OpenStack VMs).
If you're talking about OpenStack VMs then it would include that. If you're talking about something like a Ganeti VM in the production realm using production puppetmasters and under .wmnet (just happening to be intended to provide a support service to labs - I'm not actually sure if we have any of these but hypothetically speaking), I expect not.
"Cloud-wide root" could also mean things like one's key being in the modules/passwords/templates/root-authorized-keys.erb file in labs/private.git. With root on the puppetmaster you'd be able to add your key there (maybe not in git itself but certainly in the version of the file VMs pull down) yourself so they may as well be categorised as the same thing for these purposes.
Edit: Also this would likely include cumin access over all cloud instances.

In T218448#5044466, @jcrespo wrote:

May I ask to clarify what "Cloud-wide root" means? Maybe it is clear for everyone, but not to me. For example, would someone with those privileges have root access to wikireplicas toolsdb (which is on vms, but it is part of cloud support, at least logically)?

Sorry, I mean toolsdb, not wikireplicas.

"cloud wide root" is functionally "full root on all Cloud VPS instances". This does include the ToolsDB instances now that they have been moved from bare metal to virtual instances. Giving @Krenair elevated rights in "support" instances, specifically in the near term the instances which will be the future puppetmasters for all Cloud VPS instances, is exactly the point of this access request.

I can confirm that @Krenair has signed L2.

fyi @jcrespo, access levels (in particular 'cloud-wide root') are defined in the policy document here: https://wikitech.wikimedia.org/wiki/Help:Access_policies

Mentioned in SAL (#wikimedia-cloud) [2019-03-26T17:21:39Z] <andrewbogott> adding Krenair as projectadmin as per T218448

I've added @Krenair to the 'cloudinfra' project so that he can start working on puppetmasters. We may add him to the cloud root keys as well, as needed.