File auth backend should not be in cleartext

[ewolinetz]

Currently, file auth uses base64 encoded files. We should be able to encrypt these files instead of using clear text.

[jcantrill]

Can you be more specific where the encryption is needed. I believe its pretty standard for the username/password to be received as base64 encoded. Additionally, I would expect the file to be mounted as a secret which is already base64 encoded and behind other Openshift security measures. Is there a usercase we are missing to address a customer or security need?

[richm]

I guess I'm wondering why we need this password backend at all. We should either use the searchguard password auth backend, or do the auth in the oauth-proxy. Passwords are typically stored as base64 encoded hashes e.g. sha512, then base64 encode the sha512 value. A base64 encoded password is virtually cleartext.

[jcantrill]

This backend only exists because the default SG version is unable to handle Openshift service accounts which are in the form of system:serviceaccount:namespace:name or something to that effect. Requests are generally encoded with the username/password as 'username:password'. The default implementation splits on the first ':' which does not work for service accounts

This only exists for metrics because the oauth-proxy did not pass bearer token; I believe it has since been modified to do just that which would allow the SA used to the proxy to make it all the way through to ES.

I would suggest that we probably would be better spending our efforts making an acutal oauth backend which could resolve some of the hackyness that exists now and/or fix the metrics parts to rely on the SA