The access_new_install is currently installed on the puppet and salt masters. That works for almost everything, but not for Labs hardware -- Labs boxes have ssh blocked from production. There's no real consensus about how this should be handled.
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| Revert "TEMPORARY HACK: Add access_new_install to iron" | operations/puppet | production | +1 -1 |
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | Andrew | T139971 access_new_install role vs. Labs vs. the future | |||
| Resolved | Andrew | T139967 Don't forget to clean the new_install key off of iron |
Change 298385 had a related patch set uploaded (by Andrew Bogott):
Revert "TEMPORARY HACK: Add access_new_install to iron"
Change 298385 merged by Andrew Bogott:
Revert "TEMPORARY HACK: Add access_new_install to iron"
All of the below is my understanding of things, and it could be wrong!
Our historical install process is we used to install a root password via the installer, and then we just installed the root key list (I may not be right on that one) and now we install a new_install key.
This key is only placed onto the system until its first puppet run. The initial puppet run will remove the system's new_install key, as it populates the system with all its defined users (including setting the production root password and sudo/root authorized keys.
I don't see a huge issue with having an ssh hole poked into firewalls/configurations if its ONLY to allow ssh to/from palladium. The labs hosts now have it to iron, which was due to it being a operations bastion. This could somehow be an issue with palladium also hosting our private repositories, since palladium is an internal host and this *could* allow VMs to access.
Can it be set so while the virtual machine servers and labs-support-vlans can reach palladium, that the actual VMs within them cannot?
If so, that would seem to alleviate some potential concern.
I dislike the idea of placing the new_install key on MORE servers. Right now it is a potential security compromise vector, albeit a very short lived one. Placing the private key onto more systems just widens that vector.
We should also look at rotating the new_install key again. It never hurts to cycle these things.