3 ms·
Imagine you have an application like GitHub Enterprise or Phabricator, something that has a web interface and SSH for git access. You might trust SSH, but do yo
by antoncohen 8y ago
Imagine you have an application like GitHub Enterprise or Phabricator, something that has a web interface and SSH for git access. You might trust SSH, but do you trust the web stack to not have vulnerabilities?
I don't know about you, but I don't trust running third party apps, I won't publicly expose them. Instead I put them behind authenticating proxies, like Cloudflare Access[1], Google Identity-Aware Proxy[2], Bitly oauth2_proxy[3], and Buzzfeed SSO[4]. With an authenticating proxy an attacker can't even hit the web application until authenticating, so they can't exploit a vulnerability in the web application. They will have to pop the auth proxy first, which have less surface area, and then pop the web application.
Applications that combine HTTP and SSH complicate things because the typical HTTP proxy won't proxy your SSH (git) connections, and the web authentication flow doesn't work with SSH.
Cloudflare Access provides the auth proxy, cloudflared does the web authentication flow for a command line app and passes SSH traffic through Cloudflare Access.
[1] https://www.cloudflare.com/products/cloudflare-access/ https://www.cloudflare.com/products/cloudflare-access/
[2] https://cloud.google.com/iap/ https://cloud.google.com/iap/
[3] https://github.com/bitly/oauth2_proxy https://github.com/bitly/oauth2_proxy
[4] https://github.com/buzzfeed/sso https://github.com/buzzfeed/sso
- otterley 8y agoCan you explain why this setup is better than LDAP/Ansible/Chef (to provision user accounts) + ssh keys/CA-generated certificates for ssh authentication? This setup is well known in the art and isn't rife with reported vulnerabilities. The value of using a web flow to authenticate isn't clear to me because you have to provision user accounts on Unix systems anyway to have reasonable accountability.