On Mar 7, 2011, at 9:31 AM, Markus Roberts wrote:
> I think we're in danger of falling into the "yes but your proposal for fixing
> the leaky faucet doesn't solve world hunger" rat hole, as we're so wont to do
> these days. :)
This is a good general concern; I don't think it applies here. We
So going back to the initial proposal that James made:
It occurs to me that the logical extension of a Dashboard RBAC system (or
perhaps even moving elements of the problem upstream) is for auth.conf to
recognize users or perhaps better "roles" as an authentication construct.
This seems like a ve
On Mar 7, 2011, at 8:22 AM, James Turnbull wrote:
> Depends whether they are the same thing but yes assuming we do store
> some concept of roles in the master then it should be the SoT.
James and I just talked about this, and we have some more questions. We agree
that the master should be the s
> I started to say that that would do it but then I got to thinking that
> it may conflict with the other resolution rules unless we specified
> precedence. A quick search of our documentation turned up no statement
> of how we resolve conflicts now, and in various forums we've made
> conflicting
J --
> It occurs to me that the logical extension of a Dashboard RBAC system
> > (or perhaps even moving elements of the problem upstream) is for
> > auth.conf to recognize users or perhaps better "roles" as an
> > authentication construct.
> >
> >
> > I like. There would be some
Markus Roberts wrote:
> J --
>
> It occurs to me that the logical extension of a Dashboard RBAC system
> (or perhaps even moving elements of the problem upstream) is for
> auth.conf to recognize users or perhaps better "roles" as an
> authentication construct.
>
>
> I like. Ther
On Sat, Mar 5, 2011 at 1:39 PM, Markus Roberts wrote:
> J --
>
>> It occurs to me that the logical extension of a Dashboard RBAC system
>> (or perhaps even moving elements of the problem upstream) is for
>> auth.conf to recognize users or perhaps better "roles" as an
>> authentication construct.
>
J --
It occurs to me that the logical extension of a Dashboard RBAC system
> (or perhaps even moving elements of the problem upstream) is for
> auth.conf to recognize users or perhaps better "roles" as an
> authentication construct.
>
I like. There would be some details that should be sorted out
On Mar 5, 2011, at 12:32 PM, James Turnbull wrote:
> Randall's request the other day about Dashboard RBAC prompted some
> thoughts about auth in Puppet too.
>
> Currently API access is controlled via auth.conf:
>
> # path /path/to/resource
> # [environment envlist]
> # [method methodlist]
> # [
Randall's request the other day about Dashboard RBAC prompted some
thoughts about auth in Puppet too.
Currently API access is controlled via auth.conf:
# path /path/to/resource
# [environment envlist]
# [method methodlist]
# [auth[enthicated] {yes|no|on|off|any}]
# allow [host|ip|*]
# deny [host|
10 matches
Mail list logo
