Jenkins amplification

Mon Feb 3 18:48:26 UTC 2020

On Mon, Feb 3, 2020 at 1:35 PM Christopher Morrow
<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.