Hello!
I'd like to spend time now and then working on PAWS. I'm not sure what access this entails exactly, but I'd like the minimal set possible.
I helped create PAWS and had cloudadmin until recently.
This would be great: @yuvipanda has been super helpful during Wikimedia Hackathon 2021 on improving the capabilities we have on PAWS and how we might publish standalone apps better to the community. Hope we can make this a priority.
I'm pretty sure that this request from the inventor of PAWS would be hard to say no to.
@yuvipanda do you remember if you signed the volunteer NDA when you were off-boarding from your tenure as a Foundation employee?
Quay.io access to the repo is also a thing we should provide if there is interest by @yuvipanda
Yeah, so far I can primarily think of GitHub and quay.io access. And SSH / kubectl as well?
If you get the paws.admin group you would have kubectl with cluster admin using kubectl --as yuvipanda --as-group system:masters or helm --kube-as blah ---kube-as-group which also works with the kubectl sudo and helm sudo plugins, which can be nice, etc. Obviously root on a control plane node has a kubeconfig as well.
So that would be:
I believe technically, we are supposed to just kind of let this age for a week? https://wikitech.wikimedia.org/wiki/Help:Access_policies
PAWS falls under a similar access model as Toolforge because of the ability to manage other users. Does anyone disagree?
I could see it argued either way really. One point of view would be that per the direct wording on Help:Access_policies, PAWS is a "Normal" projects whose influence does not extend outside their own VMs. Another POV would be that PAWS is very similar to Toolforge in the breadth of end users and potential for them to have stored "secret" information within the environment. Yet another POV would be that Yuvi is the founder of the project and a founder returning after a wiki break is normal and low risk no matter how sensitive the project's contents may be. ¯\_ (ツ)_/¯
I can say that I would have JFDI adding Yuvi the second this ticket was filed but I wanted to make sure that @Bstorm had a chance to consider the implications and make sure we didn't break the world by accident. :)
So this has been open for over a week without any objections, I think we can consider this as successful whether or not Help:Access policies applies on PAWS (for the record, I was granted projectadmin / paws.admin without waiting for a week, so this could use some clarification in the policy). The list in T283443#7108018 is missing GitHub merge access. Yuvi already has projectadmin and is in paws.admin, could you check if you already have other access mentioned in T283443#7108018 (or GitHub access not in that)?
Yay, awesome. I can ssh in now - thanks @Majavah!
I tried to do some kubectl stuff, but
$ kubectl get node Error from server (Forbidden): nodes is forbidden: User "yuvipanda" cannot list resource "nodes" in API group "" at the cluster scope
Is that an extra permission?
I think nodes are missing from the view clusterrole, so you will need to impersonate the cluster admin account for that (kubectl get node --as admin --as-group system:masters).
@yuvipanda we changed a lot related to admin for the cluster and most of it is here https://wikitech.wikimedia.org/wiki/PAWS/Admin
The fact that it needs both the secrets.yaml and the production.yaml is probably the biggest helm change. Just FYI since the old pages are still around for historical info. You can use the kubectl plugin of kubectl-sudo to type the --as and --as-group (the --as can be anything, so you can use your name...the group has clusteradmin). You can also use the helm plugin that does the same thing in your user account if you prefer to type things like "helm sudo" instead of "helm --kube-as yuvipanda --kube-as-group system:masters", for instance. I haven't started doing that yet, but I might :) I made an alias in toolsbeta.
root on a control plane node also works, of course.