Idea for multi-level CLI access control

[Dridi Boukelmoune]

On Tue, Jun 27, 2023 at 9:24 AM Poul-Henning Kamp <phk at phk.freebsd.dk> wrote:
>
> --------
> Dridi Boukelmoune writes:
> > On Mon, Jun 26, 2023 at 6:39=E2=80=AFPM Poul-Henning Kamp <phk at phk.freebsd.=
> > dk> wrote:
> > >
>
> > Regarding the specific suggestion above, I don't think we would be
> > satisfied with this model. In the security barriers diagram [1] we
> > identified the following roles:
> >
> > - ADMIN
> > - OPER
> > - BACKEND
> > - ANON
>
> My idea was not meant as a replacement for any of those roles,
> it just an idea for how to implement CLI connections with
> different access levels - if we want to have that.

Same, my overview keeps the current roles and adds TENANT below ADMIN.

> > For CLI access, we would probably want a new role TENANT, managed by
> > ADMIN. Ideally, everything in the cache (VCL, contents, operations
> > like ban) would be virtually partitioned such that a tenant could not
> > directly affect the resources of other tenants.
>
> I think that is a bit beyond the scope of the current discussion, but
> it is certainly relevant to keep it in mind.
>
> > > * Varnishd should identify itself (-i/-n) in the 107 message so that the
> > >   client can pick which secret file to use if it has access to multiple.
> >
> > If each "account" (admin or tenant) has one dedicated secret,
> > this is probably not needed.
>
> I dont see the admin/tenant split eliminating the potential benefit
> of being able to hand out restricted CLI access secrets.

The whole idea is to partition the cache logically, so each tenant
sees a "restricted" set of resources. Commands like start and stop
would require admin privileges, so a "mere" tenant would not be able
use them. They would however be able to vcl.load and vcl.list, but
only see their VCLs, not other tenants'.

Instead of a tenant or a partition, let's call it a context and use a
familiar -Z option:

    # operate as ADMIN, regular CLI `auth ...` under the hood
    # secret found from VSM with varnish credentials
    # /etc/varnish/secret read with MGT credentials (same as today)
    $ varnishadm context.create -S /etc/varnish/example.com/secret example.com

    # operate as TENANT, performs `auth -Z example.com ...` under the hood
    # secret found from VSM with varnish credentials
    # /etc/varnish/example.com/secret read with TENANT credentials
    $ varnishadm -Z example.com vcl.load www /etc/varnish/example.com/main.vcl

That's one way you could interpret my previous email.

> As for CLI plain-text:  I would really love to find a good and mostly
> seamless way to use SSH for CLI access.

Another option could be mutual TLS once we bring HTTPS support to the cache.

We will discuss this internally and come back with a proposal.

Best,
Dridi