Comments inline. On Po, 2016-08-15 at 09:34 -0400, Todd Mancini wrote: > IMHO, it will be very difficult for most enterprise dev teams to get IT to > prop-up a DMZ-based service set up in less than 9 months, if ever. While this > approach will work for some, it seems to miss the original persona -- > enterprise devs who cannot use Ultrahook due to IT security concerns.
Although I understand it may take time to get DMZ-based service approved in some companies, this may seem to be a bit drawn to the worst case scenario. But noted! In that case, and before they can get this proxy service approved, we can still offer them to go through our public instance of this OSS service to start with. At this level, it will be almost comparable to what ultrahook provides, but the data will go through our service and network instead of ultrahook's, which will give our customers more confidence because they have a contract with us. And since this will be the same OSS they can move to running it on their own servers once it gets approved. As Andrew Block noted bellow, some of his customers already tried to solve this problem on their own. To me this would seem like much better solution then hacking it through e.g. Jenkins. (The only other solution for this would be to go back to pooling.) > These same IT departments will balk at the idea of running this little > forwarding service. The devs will somehow have to convince IT that it's > secure, and they'll likely give up after a 5th attempt to fill out the > requisite TPS form. Well, to the question of security; there are several areas: 1) Data/Network security - It will be most definitely better with OSS run on their own servers or at least by RH, who they have contract with, than by third party like ultrahook - I would say that this is the main point 2) Opening laptops/servers in internal network to connections from the Internet - The small security issue is there either by using this service, ultrahook or any other service. This is just how TCP and NAT works and you can't easily forbid it because it is a regular HTTP(s) initiated from client side. Users can always install this kind of app inside DMZ and admins won't even know about it. There is nothing to be changed here or to be feared more than usual. - OpenShift uses secure webhooks with secret 3) Security of running the server and client app itself - As with other microservices, server part can be easily solved by using VMs and/or containers. And since it will be OSS, you can easily verify what client and server does. (And build it from source if you want.) - Backed by RH IMHO, this will only add security, primarily in 1). Regards, Tomas > > > On Mon, Aug 15, 2016 at 9:23 AM, Andrew Lee Rubinger <[email protected]> > > wrote: > > > > > > > > On Mon, Aug 15, 2016 at 9:20 AM, Andrew Block <[email protected]> wrote: > > > > > > > > > > > > Andrew Block > > > Red Hat Consulting > > > 101 N. Wacker, Suite 150 > > > Chicago, IL 60606 > > > [email protected] | m. (716) 870-2408 > > > > > > > > > On August 15, 2016 at 9:06:17 AM, Andrew Lee Rubinger > > > > > > ([email protected]) wrote: > > > > > > > > > > > > > > > > On Mon, Aug 15, 2016 at 8:29 AM, Andrew Block > > > > > > > > <[email protected]> wrote: > > > > > Comments inline > > > > > > > > > > - Andy > > > > > > > > > > > > > > > Andrew Block > > > > > Red Hat Consulting > > > > > 101 N. Wacker, Suite 150 > > > > > Chicago, IL 60606 > > > > > [email protected] | m. (716) 870-2408 > > > > > > > > > > > > > > > On August 15, 2016 at 1:26:27 AM, Andrew Lee Rubinger > > > > > > > > > > ([email protected]) wrote: > > > > > > +1 from me; it solves a user need in line with the end-to-end > > > > > > experience we're looking to provide. > > > > > > > > > > > > If some group is already working on a similar feature we'd like to > > > > > > know before we take it on. > > > > > > > > > > > > S, > > > > > > ALR > > > > > > > > > > > > > > > > > > On Fri, Aug 12, 2016 at 9:36 AM, Tomas Nozicka > > > > > > > > > > > > <[email protected]> wrote: > > > > > > > > [email protected] > > > > > > > > > > > > > > > > On Pá, 2016-08-05 at 22:23 +0200, Tomáš Nožička wrote: > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > I am working on pipelines for OpenShift and Catapult, and we > > > > > > > > > are trying > > > > > > > > > to setup full CI/CD experience for users on their laptops. > > > > > > > > > > > > > > > > > > One thing we have encountered is the need for hooks > > > > > > > > > forwarding behind > > > > > > > > > NAT to user's laptop. I am aware that OpenShift is promoting > > > > > > > > > ultrahook.com for this use case [1] which is quite fine for > > > > > > > > >OSS and > > > > > > > > > public projects, but definitely not for enterprise. > > > > > > > > > > > > > > > > > > Ultrahook is not secure as a solution because customer data > > > > > > > > > necessarily > > > > > > > > > leaks to a third party provider in this model. (Ultrahook > > > > > > > > > also returns > > > > > > > > > 500 for some hooks, there are availability issues, client is > > > > > > > > > a ruby > > > > > > > > > gem, ...) > > > > > > > > > > > > > > > > > > This issue is not limited to end users and their laptops, but > > > > > > > > > it's > > > > > > > > > relevant even when customers want to run OpenShift servers > > > > > > > > > behind VPN > > > > > > > > > or otherwise not accessible to receive webhooks from GitHub > > > > > > > > > (or > > > > > > > > > similar). > > > > > > > > > > > > > > > > > > > > > > > > > > > > I have always suggested integrating with OpenShift using the API or > > > > > CLI tool instead of utilizing web hooks. To me, the current > > > > > functionality does not seem to fit into an enterprise story. > > > > > > > > > > > > > Can you expand on this bit? > > > > > > > > For the use case of a customer with servers sitting behind a VPN and > > > > not publicly-addressable to receive a webhook call directly, what does > > > > an appropriate solution look like to you? > > > One customer put logic in their external API gateway tool to process the > > > web hook and forward it on to the internal OpenShift instances. The other > > > placed a server out in the DMZ that could be reached externally and > > > processed the request to the internal instance. In both cases, they were > > > using the secured web hooks from GitHub [1] to restrict access. > > > > > The "server in the DMZ" approach is in line with what I'd been thinking; we > > provide publicly-addressable slim server able to receive a webhook event > > and proxy it, keeping tight security by only exposing the webhook listener > > endpoint. > > > > > - Andy > > > > > > [1] - https://developer.github.com/webhooks/securing/ > > > > > > > > > > > > S, > > > > ALR > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > We are thinking about writing such software (OSS) > > > > > > > > > > > ourselves, so > > > > > > > > > > > customers can run it on their own servers, depending on > > > > > > > > > > > their needs. > > > > > > > > > > > But I wanted to check first if, by any chance, someone > > > > > > > > > > > from OpenShift > > > > > > > > > > > isn't already working on that? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > What are your thoughts on this? > > > > > > > > > > > > > > > > > > > > > > > > > > > > A few of my customers toyed around with the notion of creating an > > > > > application to proxy that GitHub/Git server would invoke that was > > > > > publicly accessible that would proxy to their backend instances. In > > > > > the end, most of them just used Jenkins or a CI tool to act as a > > > > > proxy and have that invoke OpenShift. Though +1 for having a tool > > > > > that could provide that proxy like functionality. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > > Tomas > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > I am thinking about writing the service and > > > > > > > > > > > > > > > client in Go, particularly > > > > > > > > > > > > > > > because client will be easy to install (with no > > > > > > > > > > > > > > > dependencies) and Go > > > > > > > > > > > > > > > has great support for manipulating HTTP(2). Also, > > > > > > > > > > > > > > > I've fallen for Go > > > > > > > > > > > > > > > :) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > This would be also a great project for us to try > > > > > > > > > > > > > > > real CI/CD development > > > > > > > > > > > > > > > with pipelines builds. > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [1] - > > > > > > > > > > > > > > > https://blog.openshift.com/using-github-hooks-with-your-local-ope > > > > > > > > > > > > > > > nshift-environment/ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Red Hat Developer Programs Architecture > > > > > > @ALRubinger > > > > > > > > > > > > > > > > > > > > > -- > > > > Red Hat Developer Programs Architecture > > > > @ALRubinger > > > > > > > > > > > -- > > Red Hat Developer Programs Architecture > > @ALRubinger > > >
_______________________________________________ dev mailing list [email protected] http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
