-------- Dridi Boukelmoune writes: > On Mon, Jun 26, 2023 at 6:39=E2=80=AFPM Poul-Henning Kamp <phk@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 p...@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. _______________________________________________ varnish-dev mailing list varnish-dev@varnish-cache.org https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev
