search

simonsobs-uk / data-centre

This tracks the issues in the baseline design of the SO:UK Data Centre at Blackett
https://souk-data-centre.readthedocs.io
BSD 3-Clause "New" or "Revised" License
2 stars 1 forks source link

passwordless and sudo power combined seems dangerous #11

Closed ickc closed 11 months ago

ickc commented 1 year ago

@rwf14f, currently we use ssh key to authenticate and get into the login node. And we're granted sudo (wheel group) in #9. Consider the following scenario:

  1. downloaded a script, containing
...
sudo do_something_harmful
...
  1. and we run this script.

If there's password, then the password authentication needed will alarm the user something fishy may be going on. So the existence of password would provide an extra layer of protection.

rwf14f commented 1 year ago

That's why I'm not too happy about giving you sudo access. I can add a password if you send me a salted / sha512 encoded hash (or better put it in a file on the login node and let me know where it is).

ickc commented 1 year ago

But the problem isn't really about sudo access (i.e. in the wheel group there), it is a combination of passwordless setup and puppet orchestration.

I think enforcing ssh key is a good idea, but I think having password has its use too. Even for people who has no sudo access, if they rsync something into vm77 from a new machine (previously not "registered" via authorized_keys) then it would fallback to password, but since there's no password it would fails. (I admit that this probably is not a common scenario for existing Blackett users but I can't say the same for SO collaborators...)

And then puppet is in the way in the case that people have sudo and is passwordless too. I tried setting my own password but it would soon be overwritten by puppet.

I think orchestration is essential in these situations, and I recognize that the current orchestration works well with existing setup (say people submitting jobs through dirac-ui), but since we already agreed that SO:UK has different sorts of requirements (which e.g. leads to we access to login nodes and directly dealing with HTCondor instead). I think it is a bundled deal to accommodate the necessary changes required in orchestration as well.

Ideally, user would be able to select their own shell, change their own password, update their own authorized_keys, etc. But if such interface does not exist and we don't want to change the orchestration too much, and also given that in the last meetings we mentioned we expect O(10) users only, may be manually overriding is easier, by the people who has permission/privilege.

However, back to this issue, I think no. of users with sudo power would be very limited (mostly me and @shaikhhasib and possibly @DanielBThomas) so the amount of manual work probably is small.

rwf14f commented 1 year ago

Please remember that this is a testbed to test what's needed and whether this is technically possible, ie if we can get your mpi jobs running on the cluster. Changes will have to be made to get this into production (eg the postgresql database should not be running on the login node, but a different VM instead). sudo access will be strictly limited in production. As discussed in the meeting, local user accounts are fine for the testbed and the few users who test it, but we'll need an alternative to support larger number of users in production (eg a central authentication server, which can support both, ssh keys, passwords, password policies to enforce strong passwords). If you want to try password authentication, and sudo that requires a password then we can do this. You just have to provide me with a hashed password string (ie mkpasswd -t sha-512). You just won't be able to change your password yourself on the testbed.

ickc commented 1 year ago

@rwf14f, I already sent the hashed password to you through email (which is a link to a file on vm77.) For obvious reasons I don't want to mention that here.

Regarding supporting more users, we can discuss it in details later, including on the architecture on how it is setup.

But more users will land on the testbed obviously for wider collaborators to test. We're well aware of the fact that it is a testbed, and I hope you're aware of that too so that we can understand in the interim something someone not too happy about may happen. Again it is not an intrinsic issue about having sudo access, especially when we're doing it on the testbed. And I understand that it is tricky business because I didn't know about the current issue between the time #9 is resolved to #11 is opened.

Thanks for your understanding.

ickc commented 11 months ago

Resolved in private exchange of emails.