1258766 - Put Test Pilot /admin/ behind VPN

Status: RESOLVED WONTFIX

(Cloud Services :: Operations: Deployment Requests - DEPRECATED, task)

Description

[Wil Clouser [:clouserw]]

(sorry if this is the wrong component -- I'm not sure where this should go.)

We talked about putting Test Pilot's /admin/ behind VPN authentication and I wanted to file a bug to get that on the radar.  I think setting up a second instance of the site and pointing it to the same database would be the simplest way to do this.  We'd need to connect it to our normal deployment pipeline (meaning, when we deploy, they are both updated).

Comment 1

[Julien Vehent]

Let's not do SAML. Let's do plain LDAP from the admin panel to our local LDAP bridge (:mostlygeek has the details).
:wil - that's a code change. Can your team handle that?

Comment 2

[Wil Clouser [:clouserw]]

Is this asking for VPN (which requires LDAP) and then another authentication to LDAP from within the application, in addition to the firefox account?

If that's the case, can we just have the webserver do basic auth to LDAP on /admin/ ?

Comment 3

[Julien Vehent]

I think there are three items here:

1. The admin panel shouldn't be the same server as the public site to protect against a compromise of the public site. Ideally, we have different sets of database permissions to prevent the public site from writing into admin-level columns. 

2. Admins should authenticate with LDAP, not FxA, because we have no way of mapping an FxA account to an employee.

3. The VPN provides one LDAP lookup and does MFA, but does not forward the user identity to the admin panel. We need to know who is doing what in the admin, and that requires redoing ldap auth at that level.

Basic auth to LDAP on /admin/ might work (Benson was experimenting with that) but that only covers #3.

Makes sense?

Comment 4

[Wil Clouser [:clouserw]]

I'm saying we could spin up another server which is behind VPN and running the same versions of the code as production.  Then /admin/ on the public site redirects to the VPN server's /admin/ and the VPN server redirect's anything that isn't /admin/ to the public site.  (Input from Benson on if this is reasonable).  This fulfills #1 (-ish.  We could expand on this once it's in place).

The server also adds Basic Auth in front of /admin/.  This fulfills your #2.

I don't think #3 is a concern -- we still have the FxA account to provide identity to the admin panel.  It's possible that someone logs in with a valid LDAP account and then a different user's FxA account, but that seems like a "we have bigger problems" scenario.  If anything the FxA authentication is another F in the MFA.

Comment 5

[Julien Vehent]

Wouldn't that mean asking administrator to log through the vpn, then ldap then fxa?
If you're going to use fxa anyway, and maintain a list of accounts allowed to use the admin panel in a group, I think we can drop #2 and just do vpn+fxa.

Comment 6

[Wil Clouser [:clouserw]]

(In reply to Julien Vehent [:ulfr] from comment #5)
> Wouldn't that mean asking administrator to log through the vpn, then ldap
> then fxa?
> If you're going to use fxa anyway, and maintain a list of accounts allowed
> to use the admin panel in a group, I think we can drop #2 and just do
> vpn+fxa.

Yeah, it would be 3 logins.  I don't expect a ton of /admin/ traffic, so I didn't think it was a big deal. :)

If you're happy with out the extra LDAP auth, I am too.

Comment 7

[Julien Vehent]

Ok, so to summarize, we need to move /admin/ on a separate instance behind the vpn, and redirect the public /admin/ endpoint to the one behind the vpn. No LDAP, it's FxA all the way down with groups managed by the app.

Comment 8

[Cory Price [:ckprice] (bugmail disabled, NI me!)]

:mostlygeek - quickly checking in here to see if there's any other information you need for this bug.

Comment 9

[Benson Wong [:mostlygeek]]

I don't think I need any more information. 
Though the admin interface will move to https://testpilot-admin.prod.mozaws.net, which would only be accessible via the VPN.

Comment 10

[Julien Vehent]

Given the proposal to move testpilot to a static site, let's pause on this work indefinitely. If we decide that django is here to stay, we can reopen and resume work.