solo-io / gloo

The Feature-rich, Kubernetes-native, Next-Generation API Gateway Built on Envoy
https://docs.solo.io/
Apache License 2.0
4.07k stars 437 forks source link

Gateway Authentication? #139

Closed mavencode01 closed 5 years ago

mavencode01 commented 6 years ago

Any plans to support gateway authentication before proxying to upstream microservices

yuval-k commented 6 years ago

@mavencode01 Can you provide some more contexts? I'm assuming you mean authenticating end-users. What way do you currently do Auth? OIDC? Something in-house?

mavencode01 commented 6 years ago

Yes, currently using Kong with just Basic Auth. We want to migrate to OAuth2 or OIDC. Is this a feature plan?

ilackarms commented 6 years ago

cc @ilevine

yuval-k commented 6 years ago

Envoy has support for JWT (which is is needed for OIDC) and we plan to add support for it and basic auth in gloo shortly.

scher200 commented 6 years ago

That sounds awesome!

scher200 commented 6 years ago

any idea when we can expect this? @yuval-k

ilevine commented 5 years ago

we have support for OIDC, JWT, Basic Auth and gloo-e: https://gloo.solo.io/enterprise/authentication/ closing as answered. please re-open if needed.

ghost commented 4 years ago

All auth stuff is Enterprise?

ichtestemalwieder commented 4 years ago

I was evaluating API Gateways and Gloo looks promising. But all the Authentication Features seem to be Enterprise Edition? This makes Gloo worthless for every usecase. Auth "Termination" is the main usecase for every Gateway....

Does Gloo support custom plugins/extensions to implement this?

This should at least be documented somewhere, how these Authentication methods are supposed to be implemented in the OSS edition, otherwise all people interested will leave the site and start using something else. Thanks.

@ilevine: I know you have to make a living too. Here are some thoughts regarding OSS vs EE monetaization strategies:

Firstly: Even though technical advances, IT becomes more and more complex: With Cloud-Native => Microservices, everything becomes a Distributed System. Small companies or Non-Profits (I represent) will no longer be able to host their own Infrastrucutre as things simply get too complex. The future is some kind of Serverless or PAAS or even SAAS. But we all know, in a world that is ruled by economies of scale and no "locality-limitations", first-copy-costs, we will end up with lots of monopolies. These monopoliles (like AWS) just build their own (API-Gateway). If gloo (and this also applies to other Open-Core OSS) is not an extremly easy to use and fully featured software, small organizations will simply go the SAAS/AWS route. We simply do not have the time/money operate complex and expensive infrastructure. So Open Corse simply leads to the fact that current monopolies will simply get even worse. I strongly believe in, that releasing full featured OSS leads in effect to more revenue by having a larger userbase that eventually will start to grow and use support offerings and shift userbases from AWS/Monopolies into the hand of companies like gloo (due to support contracts/consulting...).

Secondly: Istio will become the global standard in services meshes. And even though maybe currently there is no good in/egress in the sense of a fully fledged API-Gateway for istio, this is only a matter of time. API-Gateways and Services Meshes simply have to many features in common. And it does not make sense as user spending two times the training/learning, support-contracts on two different vendors, for something so similar. So in the neartime, someonw will release official extensions to make Isitio become a real API-Gateway. And that could be gloo, as stated above, also OSS is ruled by "one winner takes it all" on the longterm and gloo could be the one. Being released fully featured and shipped as an extension of Istio, gloo would be used by "millions" of users. And this userbase could then be sold support contracts and consulting for istio and gloo as a whole. In the end making more money as the current "gloo open core", and soon someone else taking the chance to relase the official Istio API-Gatway, making gloo useless. Maybe redhat is a good example (as far as I know they hardly had any exclusive commercial features. At least the OSS offerings were all greatly useable and never lacked and important features.) For me JWT and Rate Limiting, Observability... is just too important to not have that feature. (It might be that seems some of these features can be installed manually, but I have not found any docs how to do this. If no easy to find docs are available, then is non present.)
So I (and most others) will (have to) use something else most likely AWS, waiting some time untill a fully fledged easy to use OSS offering is released, maybe like redhat openshift/okd, that includes everything, that makes it usable also for smaller organizations, or at least a fully fleged Isto with API-Gateway features.

Update: q.e.d. => A super comparison of Ingress/Service-Mesh/Gateways => See the table at the botton: https://medium.com/flant-com/comparing-ingress-controllers-for-kubernetes-9b397483b46b => In the End Istio already has more features than gloo and all other OSS API-Gateways. (And will for shure get better every day)

ghost commented 4 years ago

@ichtestemalwieder they don't give af