Keycloak submission to CNCF #406
Comments
|
+1 for this |
|
+1 | Yes, Keycloak certainly belongs to CNCF. |
|
+1, I am using Keycloak for the past one year. I would like to see Keycloak as part of CNCF 👍 |
|
+1 |
|
+1 |
|
+1 |
1 similar comment
|
+1 |
|
+1 I would really like to see Keycloak as part of CNCF. |
|
+1 |
|
Keycloak deserves to be a CNCF project. +1 |
|
I wrote about integrating Kubernetes deployed applications with Keycloak thru It provides a seamless integration with a sidecar container handling access to the web app. Keycloak is a perfect fit for CNCF ecosystem. |
bdaw
changed the title
|
+1 |
1 similar comment
|
+1 |
|
+1 Since the last attempt, the keycloak-operator has started been and helps integrate Keycloak much more closely with Kubernetes. Using k8s objects for driving the config of Realms and Clients is much easier to deal with and cloud native. |
|
+1 |
|
+1 for U.S Air Force. |
|
+1 |
|
We're using Keycloak in our production k8s cluster successfully. Scaling keycloak with HPA thanks to kube_ping is a piece of cake. |
|
+1 |
|
+1 we uses Keycloak as an IdP serving biz critical capabilities, deeply impressed by the out of box production ready! |
|
+1 We're using Keycloak deployed in k8s in production for 6 months . So far, so good. |
|
+1 Cool |
|
+1 Super Supportive! We (Government of British Columbia) have been using KeyCloak in production for about 2years. It solved a major pain point for developers working with the various government identity providers. CNCF all the way. |
|
+1 this is fantastic.. |
|
+1 |
1 similar comment
|
+1 |
|
+1 Very much look forward to that! |
|
We have been using Keycloak (RedHat SSO) for at least a couple of years if not longer, at Fresenius Medical Care North America IT Group. It's been very helpful for us to offer OAuth JWT based authentication to our applications as a facade to our legacy Access Management and Identify Management systems in the back end. I would like to see Keycload pick up more support, so that it can keep up or exceed industry leading solution. |
|
+1 |
|
+1 |
|
Love KeyCloak to be part of CNCF |
|
+1 |
|
+1 Backbase use Keycloak at the heart of our IAM solution for many Banks, Credit Unions and other FIs globally, and normally deploys it on Kubernetes in a cloud-based environment. The community around Keycloak is also well established, friendly, active and helpful, and we are proud to have contributed back to Keycloak. The Keycloak core team are open to contribution and have a mature process for managing this. We think Keycloak is a great fit for the CNCF and is an important and mature part of the open source IAM space. |
|
We use Keycloak in Cisco IT. It is the main component of the CIAM implementation we have. We chose Keycloak because of its vibrant and helpful community. |
|
+1 |
|
+1.great project.pls add it |
|
+1 |
|
+1 We at Zalando (CNCF End User Supporter) are using Keycloak across some departments, with lots of extensions to support our cases. We deploy it via Kubernetes, and we see that having Keycloak joining CNCF would be a great step for the project, which could leverage being close to all the graduated systems from CNCF, receiving support and resources from the experts that manage to accomplish those graduations. |
|
+1 |
|
Everyone, please refrain from “+1”-style throwaway comments. They are noise, not signal. |
|
I would also love to see Keycloak as part of CNCF. We have been using Keycloak, with Redhat SSO, for three years in a large project and It has server us very well, mainly due to its extreme flexibility for integrations and customizations. |
|
Hi All, Thank you very much for your support, we really appreciate it . I have consolidated the endorsement and websites in the pull request for TOC, but if I have missed anything, please let me know. I am happy to include it in pull request. See comments here here: #405 |
|
+1 Keycloak definitely deserves a place in CNCF! |
|
+1 |
|
Complementing my previous post, in our keycloak installation we have about 42 million users. About 350 clients distributed in 4 realms that serve both company employees and costumers. |
|
@bdaw I would like to see Keycloak having a more inclusive ecosystem if they will become part of CNCF. Personally, I am not a Java programmer and the interactions from us have been quite disappointing on how they run the project. Take this project as an example: https://github.com/ccouzens/keycloak-openapi The person have to parse JavaDoc/HTML in order to generate OpenAPI specification. I would argue that OpenAPI is the spec that most people agreed on for documenting APIs, but I may be wrong, most likely I am. I created an issue related to this: https://issues.redhat.com/browse/KEYCLOAK-14041 and was closed without further interaction or any explanation other than "Use Java, or deal with it". Which interesting enough packages like https://github.com/keycloak/keycloak-nodejs-admin-client#not-yet-supported are outdated or missing features even when they themselves maintain it, this could be automated for some languages using code-gen like many other projects do so more people from different ecosystems could take advantages. Same with having some control over the login experience and other interfaces. Projects like Ory allow you to have more control over the system, for example: Once again, I created some thread about it since we are interested in having more granular control over the webserver: https://keycloak.discourse.group/t/custom-web-server-for-ui-pages/2499/12 Same experience: "Use Keycloak/Java, or deal with it". Worth saying that I am not the only one who struggles with this or wants this. Maybe since I am not part of Java stack, and I come from a different background I am the problem, but regardless I see the constants theme of "Use Java/Keycloak or deal with it". A little bit of inclusiveness is appreciated if you are gonna be part of a community where most people are dealing with interoperability between multiple languages and ecosystems. Sometimes it just takes a small effort to be there; some people already did the work for Keycloak but you rejected. I love the project, and I would like to see Keycloak continue improving and creating a more welcoming experience from a more dissevered ecosystem so we'all learn from the strength of each other. I hope you take this as constructive criticism. |
|
@yordis We do plan OpenAPI specifications both for Admin API and Account API. I'm sorry that this isn't available yet as it should have been a long time ago. With regards to control over the login experience I'm not sure what you are after as you haven't mentioned anywhere what you are specifically trying to do. Login pages can be heavily modified through FreeMarker templates and CSS through custom themes, all without any need for Java. Delegating to an external web server would not make any sense to me to be honest as there's simply too many pages/flows that would have to be replicated. It would be too much work and would be out of the vision of Keycloak which is aiming to be more like a ready to use service than a framework. Comparing to Hydra doesn't make all that much sense as basically what it does is just delegate the whole authentication step to an external app. You can already do this with Keycloak through identity brokering (with a standard federation protocol rather than a custom proprietary one). The only thing in Keycloak today that requires Java knowledge is heavily customising Keycloak through custom providers. Here we already support JavaScript in a number of places, but do plan in the future to support remote interfaces like REST/gRPC to enable extending Keycloak using any language as well as through a simpler versioned API. |
|
Looks like the sig-security assessment was completed for this? See here. I'm just trying to inch this forward as a user of the toolset. |
|
+1 |
|
+1. how do we get this moving along again? The keycloak-operator, with associated CRD's, has been really nice for deploying and managing keycloaks/realms in a cloud native way. |
|
Closing in favor of #463 |
and others
PR: #405
SIG Security Assesment Request: cncf/tag-security#372
The text was updated successfully, but these errors were encountered: