Jenkins amplification

Mon Feb 3 19:30:19 UTC 2020

On Mon, Feb 3, 2020 at 12:50 PM Christopher Morrow <morrowc.lists at gmail.com>
wrote:

> On Mon, Feb 3, 2020 at 1:35 PM Christopher Morrow
Matt Harris|CIO
816-256-5446|Direct
Looking for something?
Helpdesk Portal|Email Support|Billing Portal
We build and deliver innovative IT solutions.

> <morrowc.lists at gmail.com> wrote:
> >
> > On Mon, Feb 3, 2020 at 1:26 PM William Herrin <bill at herrin.us> wrote:
> > >
> > > On Mon, Feb 3, 2020 at 10:24 AM Christopher Morrow
> > > <morrowc.lists at gmail.com> wrote:
> > > > On Mon, Feb 3, 2020 at 11:45 AM Harald Koch <chk at pobox.com> wrote:
> > > > > Jenkins, like a zillion other developer-oriented tools, should
> never be deployed Internet-facing.
> > > > > Reflection attacks inside an enterprise are handled by HR. :)
> > > >
> > > > good golly, so glad everyone's enterprise is a hard candy version of
> same.
> > > > no need for these remote workers, or discontiguous offices, or
> > > > 'internet centric workforces'.
> > >
> > > VPN.
> >
> > I love it when my home network gets full access to the corporate network!
>
> Sorry, to be a little less flippant and a bit more productive:
>   "I don't think every remote endpoint needs full access (or even some
> compromise based on how well you can/can't scale your VPN box's
> policies) access to the internal network. I think you don't even want
> to provide this access based on some loose ideas about 'ip address'
> and 'vpn identity'."
>
> Ideally you'd be able to authenticate and authorize and even
> account(!) based on a real user-id + passwd + token (2fa thing).
> Somethign akin to this:
>   https://cloud.google.com/beyondcorp/
>
> maybe using the googz work directly isn't your cup-o-joe(jane?) but...
> the idea itself is the point I was aiming for.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20200203/7a30f908/attachment.html>