Is GitHub the only authentication?

I set up an instance of Rancher, got it working, really like it. Looking forward to putting it in front of the Ops team later this week to early next.

But is there no authentication other than github? That would be a real showstopper with this team. A production environment running in our own data centre with sensitive data… no way they will agree to let authentication go outside. We would handle LDAP, although we would be perfectly fine with user/pass with a local user database (which is simplest).

Is there no easy way to secure it for enterprise environments?

We are working on LDAP/AD support right now. The only other option today is GitHub Enterprise, which you could run on-premise.

I love GitHub, use it extensively, but for the right projects. I think GitHub is fabulous for your development, and your cycle, and even your deploy. But that cycle is not production. Production is what you get once you have done all of those and deployed… and Rancher is built to manage those servers and containers, so depending on an external service is a really tough sell, except in GitHub-centric environments.

I understand, and this is why we’re adding LDAP. But we started with Github because:

  • Most people don’t want to maintain an extra source of truth, passwords, etc for users and group membership just for Rancher.
  • Most dev & ops types have GitHub accounts already.
  • A lot of them already use it to manage their code and have teams defined.
  • Smaller companies, startups, and individuals testing Rancher don’t have LDAP servers.
  • Bigger companies often have GitHub Enterprise on-premise instead, configured to support LDAP, SAML, or whatever else they use internally. So we get integration into their auth for free if they use GHE.

Not trying to change your mind or anything, but FYI on the way it works:

  • We are using OAuth to GitHub to get user and team/org membership info and associating those to accounts and environments in Rancher.
  • It does not give GitHub any control over Rancher (other than not being able to login if they are down/unresponsive).
  • It does not give Rancher any control over your GitHub account (we request read-only access to the minimal basic user profile and team info).
  • It does not give us (Rancher Labs, the company) any info about you.
  • It does not mean your rancher/server has to be exposed to the inbound public internet.

I get what you are saying. IMHO this is one of those cases where Docker’s development-side roots come through, even when trying to do something operations.

Authenticating against GitHub is fine in one of two cases:

  1. You are doing something development - after all, GH is part of your dev cycle
  2. You are in an extremely small team

The moment those are not true - you have multiple teams with separate responsibilities, e.g. development and ops, let alone you are working in the operational space - relying on GitHub to manage your internal production operations, not development or new deployments, makes many people very nervous and completely breaks their actual flows and processes.

How would I tell an ops team of 5 people to go set up github (or bitbucket or …) accounts so they can manage their operational environment? They would laugh me out of the room. The developers? They would love it. But the ops? Never.

So, yeah, LDAP works for a team that has enterprise infrastructure and authentication, but that makes the initial setup and integration curve much higher. I am setting up a basic structure for a team, let them choose among multiple orchestrators… and I have no easy way to just get them going. I am not going to get them github accounts (for production use or for testing), nor would they agree, and setting up an LDAP server just for this is kind of crazy.

You are not the only person to ask for local auth. As part of the LDAP feature we are developing, we have also created an Identity API that we can use to plug any type of backend auth system without any major code refactoring. We will add local auth fairly soon, most likely in a couple of weeks. I’ve added a feature bug to track this and added it to our next milestone so we can talk about it and get it started as soon as possible.

https://github.com/rancher/rancher/issues/1687

2 Likes

Got it. Rancher really is quite impressive… but sometimes it is the simplest things that it needs.

would be awesome to get an authentication service based on jwt just like they did with the docker registry:

that way, anyone could implement their own system: no more complain.

I was not overly enamoured of the auth token based system for the docker registry, but maybe because I was just expecting something simpler.

Is there an open-source “runs in an image” auth server that works for it? Hmm, you know, if an auth token server could serve both rancher and a registry (and other things) and be easy to run (in docker), well, that would be interesting

I’ll use https://github.com/SUSE/Portus for the authentication of my private registry. This could be patched if needed to work with rancher.

You got Portus to work? I found its documentation to be terrible. Sure, it has a compose file for the whole thing in dev mode, but getting its two containers (web & db) set up an initialized is a pain. I didn’t want to read the source code to figure it out.

I was looking at going with https://github.com/cesanta/docker_auth despite its mixing auth/auth and config file, and despite its rigid model, just to get something that works easily.

Where do we stand on either LDAP/AD or local auth? I can live with either, but I would say this is the major thing holding up a team looking to deploy in both IT and Production.

LDAP is in yesterday’s 0.34 release.

I highly recommend going to to the Announcements section of our Forums, http://forums.rancher.com/c/announcements and setting it to “Watching” so that you will be automatically notified of new releases which include summaries of the release notes.

1 Like

Good idea, thanks. I did it.