[HN Gopher] A detailed guide to SSO on Kubernetes
       ___________________________________________________________________
        
       A detailed guide to SSO on Kubernetes
        
       Author : talkingquickly
       Score  : 58 points
       Date   : 2021-04-06 08:55 UTC (14 hours ago)
        
 (HTM) web link (www.talkingquickly.co.uk)
 (TXT) w3m dump (www.talkingquickly.co.uk)
        
       | gsjjsjsbsb wrote:
       | Does anybody have a good, comprehensive guide to Keycloak? I
       | looked at it a while back and it seemed like a giant web UI with
       | a million poorly documented knobs, but I keep seeing people who
       | claim to be using it. I've used Auth0, Okta, Dex, and ORY and
       | none of them seemed quite as incomprehensible
        
         | streetcat1 wrote:
         | I think that keycloak is based on JBoss, which is GPL? Hence I
         | am not sure that you want it for commercial projects. But I
         | might be wrong.
        
           | nurgasemetey wrote:
           | There are many commercial projects using Keycloak as I know.
           | Are they in danger?
        
             | jeroenhd wrote:
             | Edit: Keycloak is licensed with the Apache 2.0 license, so
             | none of this is relevant for Keycloak.
             | 
             | GPL is only a problem if you import or change the source
             | code. If you just run it in the backend, as a service,
             | you're most likely fine.
             | 
             | If you customise Keycloak through code, you're probably in
             | GPL violation territory. With the customisability of
             | Keycloak, I doubt that this is something many projects will
             | ever run into.
        
               | pricechild wrote:
               | I don't think this is true.
               | 
               | The GPL allows you to copy & modify code for your own
               | desires very generously.
               | 
               | The limitations you fear apply _if_ you distribute the
               | code (in source or other forms) or modifications
               | yourself.
        
               | jeroenhd wrote:
               | That's true; assuming you run the software on your own
               | premises, GPL won't hurt you at all. If you sell premium
               | software packages to be run over at your clients'
               | hardware this can be a problem, though.
               | 
               | However, after looking into Keycloak more closely, the
               | software seems to be licensed with the Apache 2 license,
               | so none of this is a concern.
        
           | jabiko wrote:
           | Keycloak is licensed under Apache 2.0
        
         | candiddevmike wrote:
         | Keycloak is designed to be super flexible and support almost
         | every combination of auth methods out there. A lot of companies
         | don't need this kind of complexity though, which is where
         | something like Dex may be more appropriate--it's quite a bit
         | simpler.
        
         | rad_gruchalski wrote:
         | The thing with Keycloak is: when you know what you are looking
         | for, it's all self descriptive. Server administration
         | documentation is awesome:
         | https://www.keycloak.org/docs/latest/server_admin/index.html
         | 
         | I've written more about Authorization Services:
         | https://gruchalski.com/posts/2020-09-05-introduction-to-keyc...
         | 
         | And can recommend these resources:
         | https://www.janua.fr/tag/technical-blog/
        
       | cpdean wrote:
       | I read the headline, "A detailed guide to SSO on Kubernetes", as
       | "A detailed guide to Single-Stage to Orbit on Kerbalnetes" and
       | was thoroughly disappointed after clicking.
        
       | varispeed wrote:
       | My dream is to one day create an SSO solution for companies. I've
       | been doing research for a time being, but I am worried that I
       | wouldn't find any clients, because who would trust an SSO created
       | by one guy in his basement? I think the first step to overcome
       | that would be having a completely Open Source solution, but how
       | to avoid other companies grabbing it and selling as their own? Or
       | do you think it is better to develop it anyway and then worry
       | about customers later?
        
         | saberdancer wrote:
         | There is already Keycloak and various vendor solutions. I feel
         | you'll struggle to break through.
        
         | herodoturtle wrote:
         | > because who would trust an SSO created by one guy in his
         | basement?
         | 
         | If you think you've got a good idea and a unique proposition -
         | and your technical skills are up to scratch - then don't worry
         | about starting out from your basement.
         | 
         | Have a look at Thawte Consulting - a certificate authority
         | founded by Mark Shuttleworth in his parents' garage - which he
         | later sold to Verisign for $575 million dollars:
         | 
         | https://en.wikipedia.org/wiki/Thawte
         | 
         | Starting a "high trust" business from one's basement is
         | perfectly fine.
         | 
         | That being said, a far more important point is testing /
         | validating the existence of an actual market for your product.
         | 
         | Whether you build your solution out of your basement or a
         | lavish penthouse office is irrelevant.
         | 
         | The best and brightest team working out of swank office space
         | will still fail if the market for their product doesn't exist.
         | 
         | Hope that helps :-)
        
         | martin-adams wrote:
         | Personally, I think the answer has to come from your customers.
         | If the pain you're solving is great enough that they want it,
         | but the only showstopper is future-proofing, then you might be
         | able to work with them to find a solution.
         | 
         | It might be a case that you deploy into their infrastructure
         | and give them a licence to use the source code should you shut
         | down.
        
         | Hitton wrote:
         | >because who would trust an SSO created by one guy in his
         | basement
         | 
         | You don't have to tell everyone that you are one person company
         | operating from basement. Why not use phrases like "our
         | company", "our clients", have different email addresses like
         | support@, sales@, hr@ subtly insinuating there are more of you,
         | use picture from photobank when listing address of your
         | company's headquarters(basement) etc.. You won't be first nor
         | last person doing this.
         | 
         | And Open Source/Proprietary doesn't need to be either/or
         | problem. You can dual license it as AGPL/Proprietary and make
         | contributors sign CLA.
        
         | 3np wrote:
         | The current business players in the space all range across the
         | spectrum of closed blackbox Saas (Auth0) to open core / open
         | source (HC Boundary, arguably)
         | 
         | Before you can answer that - how do you differentiate from the
         | existing competition? What's your target customer?
        
         | 1cvmask wrote:
         | What will be different to other solutions?
        
         | znpy wrote:
         | Keep dreaming!
         | 
         | In the meantime people are already offering managed keycloak
         | instances as a service.
        
         | candiddevmike wrote:
         | Would love to hear more about this, I've got a couple of design
         | diagrams and thoughts on my "ideal SSO setup". My contact info
         | is in my profile.
        
         | traverseda wrote:
         | The smaller scale homelab/selfhosting people really need a
         | better solution. I think open source developers do as well.
         | 
         | What we really need is a small easy to set up solution that
         | provides a clear way for us to integrate our app into it.
         | 
         | My ideal would be something that
         | 
         | * Supports ldap and OIDC
         | 
         | * Can be deployed to docker using one compose file
         | 
         | * Only needs to support hundreds of users (keep it simple, easy
         | to deploy, and able to run on a raspberry pi)
         | 
         | * Provides basic user management, I want to be able to put
         | users into groups and (if the app supports it) use those groups
         | for in-app ACL.
         | 
         | If that service worked well in my homelab (a single-pc docker
         | swarm that runs a few private web services like jellyfin) I'd
         | very likely end up deploying it on my employers infrastructure.
         | My employer is a small business with maybe ~30 users.
         | 
         | I'm not sure how to convert something like that into sales
         | though. Still, starting with an open-source solution that
         | solves problems for the little guys often has a "trickle up"
         | effect.
         | 
         | Right now I'm looking towards
         | https://github.com/sonicnkt/glauth-ui/ to solve that problem,
         | but it's definitely not anywhere near there yet.
        
           | znpy wrote:
           | Uhm, keycloak does all the things you name and more.
           | 
           | I have it in production at work. Three instances, clustered
           | (infinispan), running in docker containers orchestrated by
           | kubernetes.
           | 
           | Each instance (pod) is upper-limited to 2gb ram (or 3, can't
           | recall the details now).
           | 
           | It works very well and very reliably, serving about 750 users
           | (as in, real people).
           | 
           | If you have 2GB to spare and a physical core, you can run
           | keycloak with no problems at all.
           | 
           | After all, it all depends on the amount of traffic. Little
           | traffic = little cpu load.
           | 
           | Don't dismiss keycloak because it's written in Java... Quite
           | the contrary, you can tune the JVM to work with little memory
           | (-Xms -Xmx iirc).
           | 
           | Ten years ago it was very common to see tips and tricks to
           | make grails web apps work on as little as 64mb of ram on chap
           | VPSes.
        
             | traverseda wrote:
             | Can you provide an example docker compose to deploy
             | keycloak+ldap in docker (not kubernetes)?
        
               | red0point wrote:
               | I googled that for you, first result:
               | 
               | https://github.com/ivangfr/springboot-keycloak-
               | openldap/blob...
        
               | traverseda wrote:
               | Okaaay, now I have a keycloak server and an ldap server
               | running. I guess my next step is to shell in to the ldap
               | host, wget https://github.com/ivangfr/springboot-
               | keycloak-openldap/blob..., edit it to my needs, look up
               | how to generate openldap password hashes, go back in to
               | keycloak, and try to configure that to talk to my ldap
               | server.
               | 
               | So now I need to look up the default values for
               | 
               | Vendor, Username LDAP attribute, RDN LDAP attribute, UUID
               | LDAP attribute, User Object Classes, Connection URL,
               | Users DN, Custom User LDAP Filter, Search Scope, Bind
               | Type, Bind DN, Bind Credential
               | 
               | If I knew what vendor openldap was considered setting the
               | Vendor would fill a bunch of of those in. Well let's try
               | following through this this random blog post and hope it
               | works: https://geek-
               | cookbook.funkypenguin.co.nz/recipes/keycloak/au...
               | 
               | Compare that to the experience of deploying say,
               | wordpress. And hey look, it already comes with an
               | authentication backed!
               | 
               | Sure, you can build something that does more or less the
               | same thing but you have to do a fair bit of work to get
               | to that point. Realistically if you haven't done it
               | before, and if you don't have any ldap experience, you're
               | looking at a solid couple of hours to get that set up.
               | 
               | And it's still apparently going to use 100s of MB of ram.
               | 
               | Where as wordpress goes up in a few minutes, handles user
               | account but uses less ram, I don't really need to do any
               | extra work, and I'm confident it's going to work.
               | 
               | I'm not looking to build a skill, I'm looking to just
               | have an auth server I can use and that I can link my own
               | apps against easily.
        
           | red0point wrote:
           | I think Keycloak ticks all those boxed rather nicely. While
           | it does support more than a few hundred users, I doubt that
           | this will be a serious issue.
           | 
           | Perhaps you could enlighten us with a few key differentiators
           | of your ideal solution to other common ones?
        
             | traverseda wrote:
             | Wait, does keycloak have an integrated LDAP server?
        
               | red0point wrote:
               | No. You can use any LDAP server as a backing store for
               | your users.
        
       | halfmatthalfcat wrote:
       | I've leveraged nginx-ingress's OAuth annotations to great
       | success: https://kubernetes.github.io/ingress-
       | nginx/examples/auth/oau...
        
         | talkingquickly wrote:
         | Yup agree, that's exactly what's being used here, along with
         | some tweaks to make it easier to do things like passing the
         | auth JWT's back to the underlying app etc
        
       ___________________________________________________________________
       (page generated 2021-04-06 23:01 UTC)