[auth/netapi/salt-api] trust X-Remote-User in salt-api

[arthurzenika]

Add a way to get an unauthenticated token when we've set
the salt-api to trust a frontal to be doing the authentication
(related to #24793)

This PullRequest is still work in progress, do not merge as is.

This initial code serves as discussion material for #24793, I'm not sure about the consequences of mk_unauth_token on the rest of the architecture.

[whiteinge]

How does Salt verify that the token getting passed in is valid?

Will you please enumerate, from start to finish, all the steps necessary for an example Kerberos authentication?

[whiteinge]

@arthurlogilab I am closing this pull request only while we discuss further and flesh out the full idea and implementation. This keeps the list of pull requests small and prevents an accidental merge. Please keep your branch available and keep pushing changes to it. Once this is ready we will reopen this pull request in order to merge it.

[arthurzenika]

@whiteinge salt does not get to see the kerberos token in this scenario. It trusts the frontal to do that check.

Let me try to describe the sequence flow :

pepper->kerberos: ask kerberos token salt.example.org
kerberos->pepper: give kerberos token for salt.example.org
pepper-> apache: http with negotiate and kerberos token
apache->kerberos: check kerberos token for salt.example.org and user
kerberos->apache: OK the access for that krb token for salt.example.org and user
apache->saltapi: proxy request with X-Remote-User added to the HTTP headers
Note right of saltapi: check saltapi configuration for trust_remote_user=True
saltapi->saltmaster: ask for salt token with no authentication
Note right of saltmaster: check saltapi configuration for trust_remote_user=True
saltmaster->saltapi: send back salt token
saltapi->apache: send back salt token
apache->pepper: send back HTTP response

diagram generated with https://bramp.github.io/js-sequence-diagrams/

[arthurzenika]

Following discussion with @douardda we're going to try out another approach that does not require to introduce a mk_unauth_token which might be a security hole.

We're thinking about a sharesecret.py auth mecanism where the apache (or nginx) front would after authenticating the user add a shared secret to the headers that would authenticate the user. That shared secret would be in the apache configuration and the cherrypi config. Thus, no mention of keberos (or other auth mecanism) on the salt-api/salt-master side.

wip.

[whiteinge]

@arthurlogilab thanks for much for the detailed explanation! That really helps me see the full picture.

When Apache asks salt-api for the "no authentication" Salt token, is there any additional validation checks at that step? Is there any user-specific checks done? My question is whether Salt is configured to blindly trust anything that comes in from Apache and is that done as a single user or can Apache do that in-between for multiple user accounts (with varying permissions, for example).

[douardda]

@whiteinge yes the idea is the backend (salt-api) trust the web frontend (apache or nginx, might also be a wsgi middleware) since this later is responsible for authenticating the user. In such a setup, the backend (salt-api) must NOT be accessible by any other host than the frontend.

If we want to secure a bit the frontend/backend communication, we can add a shared secret verification (a simple hashed password for example).

It's a rather common configuration (see for example the pyramid's RemoteUserAuthenticationPolicy in which the authentication is granted according to the presence of a wsgi environment variable (which may be set by a wshi middleware, or be one of the request's HTTP header).

For our internal applications, we are using the SPNEGO nginx module with the following configuration:

location / {
  auth_gss_keytab /etc/nginx/krb5.keytab;
  auth_gss on;
  proxy_set_header X-Remote-User $remote_user;
  auth_gss_allow_basic_fallback off;
}

In the case of salt-api, wa are also thinking of a setup in which we use the nginx's auth_request directive to handle the login process using a kerberos based user authentication to ask salt-api to generate an authentication token, then let salt-api work as usual (with this auth token only, no more kerberos auth processing).

David