Page MenuHomePhabricator

"Opsonly" bastion?
Closed, ResolvedPublic


We currently have iron as the "ops-only" bastion. I'm not sure why! I've inquired a number of times and I don't remember ever hearing a satisfactory answer.

I personally don't use it, relying on the other bastions instead. I have never have done so. I guess it did make some sense when people used SSH agent forwarding (I never did that) but nowadays that's blocked across the fleet. I tend to use the local-to-the-DC bastion, as a) I get annoyed by the lag introduced by crossing the atlantic twice when I'm operating on esams machines, b) I need to have a workflow to deal with network-level issues (packet loss and outages) and relying only on iron is a bad idea for that.

So… is there any reason to keep having it as a distinct box? I am aware we have the password store there but now that's also gpg-encrypted, so we can use any other server, ops-specific (e.g. puppetmaster) or even the public bastion(s).

Event Timeline

faidon created this task.Oct 8 2015, 8:55 AM
faidon raised the priority of this task from to Medium.
faidon updated the task description. (Show Details)
faidon added a project: acl*sre-team.
faidon added subscribers: faidon, RobH, MoritzMuehlenhoff, mark.
Restricted Application added subscribers: Matanya, Aklapper. · View Herald TranscriptOct 8 2015, 8:55 AM

I was wondering the same, and I think we can let it go.

It would however be useful to have it around for a while as the initial test system for 2FA. Once that is established on all bastions I think we can let it go.

Dzahn added a comment.Oct 8 2015, 3:58 PM

Same here, the only reason i knew was agent forwarding and preventing that our keys get stolen. And since we don't allow that anymore i have been wondering the same thing. Especially related to all the discussions about bastion hosts and groups that have access to them. We had to introduce a separate role for ops-only bastions so that we could at least treat the other regular bastions the same and give access to admin groups in a role rather than host-based.

So yea, let's get rid of it (and if not it would mean have one in codfw as well).

Dzahn added a comment.Oct 8 2015, 3:58 PM
This comment was removed by Dzahn.
chasemp added a subscriber: chasemp.Oct 8 2015, 4:02 PM

I also have no attachment to iron

We need to migrate the pwstore from iron to palladium. Since we already keep the private repo there, this seems to be an in scope use of palladium.

Does this sound reasonable? Since @MoritzMuehlenhoff is the maintainer of said pwstore, I'll assign this to him for his review.

@MoritzMuehlenhoff: If we can migrate this, let us know. Once it is migrated and the 2fa testing you are doing on iron is done via T116750, we should be able to reclaim this box.

(Please assign back to me when ready for reclaiming.)

Dzahn added a comment.Dec 22 2015, 1:51 AM

@RobH we should also copy the /home directories over and merge files into the home dirs on bast1001 and/or give people a heads-up so they can copy it themselves.

RobH added a comment.Dec 22 2015, 1:52 AM

I think we can just tell folks to make their own copies, as its opsen/roots only on iron in the first place.

either we get rid of it or we have to upgrade it in T125025

Dzahn added a comment.Dec 20 2017, 7:39 PM

Nowadays iron is used for testing experimental 2fa authentication.

Seperately we want to reinstall it because the hardware needs to be replaced soon.

Thoughts on how to move forward? Are we getting a replacement for the yubikey test setup? Could it be virtual?

Dzahn added a comment.Dec 21 2017, 8:09 PM

Talked to Moritz, iron can go away soonish and won't need a replacement.

RobH added a comment.Dec 21 2017, 9:43 PM

Well, I sometimes use it for a root mgmt screen session when remotely testing hardware, but I suppose I can just as easily use the puppetmaster for that!

Krinkle removed a subscriber: Krinkle.Dec 22 2017, 6:40 PM
MoritzMuehlenhoff closed this task as Resolved.Aug 23 2019, 8:12 AM

I'm closing this task in favour of T220505