Hey Sylvain (et al), I'm aware the number of options requires some prioritization and time / effort is often the resource we lack. If y'all ever need some direction or assistance if it's technical or just trying to see if we make a suitable solution for your use case feel free to let me know.
> But we found issues (we weren't able to disable part of deployments, > specifically the jobs, and so it wasn't working for example) and so we > weren't able to make it work. This is possible though it maybe needs to be more prominent in our docs. To opt out of data-plane injection into a particular Pod, you need to annotate it with kuma.io/sidecar-injection = disabled Reading through the linked presentations there's a good deal of overlap in your use cases / requirements and Kuma. One benefit of Kuma being built on top of Envoy is in the future it would be an option to swap it out but per your point would require effort / time which folks need to have first. In the proposed “cloud native” security presentation is any of that touching MSB? MSB being on openresty would mean transitioning the logic to Kong plugins a piece of functionality at a time seems quite appealing and mutually beneficial to both of us. Regards, Colin Hutchinson Kong On Wed, Apr 29, 2020 at 12:23 PM <[email protected]> wrote: > > Hello Colin, > > In OOM (yes I know, we have a lot of projects in ONAP) which is the installer > project, we have worked on Service Mesh for ONAP and evaluated (among others) > kuma (see > https://wiki.lfnetworking.org/pages/viewpage.action?pageId=25364127&preview=/25364127/28738580/OOM%20Service%20Mesh%20Prague.pptx) > . > > But we found issues (we weren't able to disable part of deployments, > specifically the jobs, and so it wasn't working for example) and so we > weren't able to make it work. > > We have decided to start a PoC with ISTIO/keycloak (see here > https://wiki.onap.org/pages/viewpage.action?pageId=79203136&preview=/79203136/81407491/ONAP-CN-AAA.pptx > and here also https://wiki.onap.org/display/DW/ONAP+Security+Model if you > want to see where we want to go) for the reason given in the service mesh > slidedeck but I would love to have an "agnostic" solution (at least in medium > term) where people can use the service mesh implementation he wants (as long > as it fulfills some requirements). But we don't have resources for now. > > On ingress side, we now supports nginx (Krzysztof in CC made a status but > couldn't find the slides sorry), and we're looking on how to add more options > but to be honest we're again not enough :/ > > Regards, > Sylvain > > ________________________________ > ________________________________ > De : [email protected] [[email protected]] de la part de > [email protected] [[email protected]] > Envoyé : mercredi 29 avril 2020 15:44 > À : Tal Liron; [email protected] > Objet : Re: [onap-discuss] [msb] Kong 1.0 released > > Hi Folks, > > It seems we at Kong came to the same conclusion (Kong may be beneficial to > ONAP) but I seem to have approached this problem from the wrong direction. > > Being unfamiliar with ONAP at first I attended an ExtAPI meeting to pitch > Kong as being a project that would be mutually beneficial to become utilized > by ONAP ( > > I think if you have the bandwidth watching the ARC meeting recording would be > beneficial. One thing that was touched on within that meeting is our Kuma > mesh which is built on top of Envoy and integrates with Kong. I think it'd be > great to have a meeting to see if we could collaborate on if adopting Kong > would be of benefit. > > Sincerely, > > Colin Hutchinson > > Kong > > > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu > ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete > this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#21321): https://lists.onap.org/g/onap-discuss/message/21321 Mute This Topic: https://lists.onap.org/mt/26443378/21656 Group Owner: [email protected] Unsubscribe: https://lists.onap.org/g/onap-discuss/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
