Idea for multi-level CLI access control

[Poul-Henning Kamp]

--------
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.

> 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.

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

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.