Good people ~ Role-based access will be one of the next big features in Dashboard. If this is something that would help you, will you tell me the minimum features that you would consider useful? That is, the features without which RBAC would be useless to you. I''m sure there''ll be disagreement; right now I''m just gathering requirements. Once we have feedback from multiple channels we''ll work on prioritizing and creating a roadmap. Thanks! r -- Randall Hansen; Director of User Experience; randall@puppetlabs.com -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Hi Randal, Very high level but I would like to see the following: • to be able to create roles such as viewer, editor, administrator • these roles be ldap groups • to be able class or group hosts and assign them to a group of admins to watch - while excluding their ability to see certain hosts. • being able to link a host or hostgroup to a report or report group? (where depending on ''importance'' of the host or group you could send alerts when changes occur or changes fail - but for other host just report normally). Thanks, Den On 03/03/2011, at 3:02, Randall Hansen <randall@puppetlabs.com> wrote:> Good people ~ > > Role-based access will be one of the next big features in Dashboard. If this is something that would help you, will you tell me the minimum features that you would consider useful? That is, the features without which RBAC would be useless to you. > > I''m sure there''ll be disagreement; right now I''m just gathering requirements. Once we have feedback from multiple channels we''ll work on prioritizing and creating a roadmap. > > Thanks! > > r > > -- > Randall Hansen; Director of User Experience; randall@puppetlabs.com > > -- > You received this message because you are subscribed to the Google Groups "Puppet Users" group. > To post to this group, send email to puppet-users@googlegroups.com. > To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. >-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On 3/2/2011 2:02 PM, Randall Hansen wrote:> Good people ~ > > Role-based access will be one of the next big features in Dashboard. If this > is something that would help you, will you tell me the minimum features that > you would consider useful? That is, the features without which RBAC would be > useless to you.One general feature I''ve missed in other RBAC style systems is the ability to use external authentication either with or without external authorization. The reason why, is that centralized password management may or may not fall in the same organizational unit as management of a particular puppet server. So for example, let''s say that dashboard is configured to use LDAP auth. In a place where all of IT is one big happy family, the same LDAP server might also return a list of roles to assign to a given user. In a more fragmented organization, however, whoever runs the central LDAP server may be unable or unwilling to delegate out control of the Dashboard role attributes to the puppet administrators, or possibly even to create the attributes in the first place. In this scenario, it would be far more useful to simply use LDAP to verify usernames and passwords, and then consult internal records to assign a list of roles. Not that I''ve pounded my head against products that didn''t support this kind of split, or anything. -- Frank Sweetser fs at wpi.edu | For every problem, there is a solution that WPI Senior Network Engineer | is simple, elegant, and wrong. - HL Mencken GPG fingerprint = 6174 1257 129E 0D21 D8D4 E8A3 8E39 29E3 E2E8 8CEC -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Beyond what Den pointed out, I would like to see either native (or good instructions) support for authenticating with X.509 PKI certificates. You would need to be able to specify: - The trusted CA chains - The CRL/OCSP/SCVP connections - What attribute/regex contains the username of the user - An internal username mapping back to the role of the user (which should be built in) This should be authoritative and passwords should be optional. Less important, but still nice, would be configuration instructions for Kerberos with GSSAPI. Also, if pulling from LDAP, I would like to avoid custom schemas if at all possible. It can be *really* hard to get Enterprise-type folks to add schemas to their servers. Thanks! Trevor On Wed, Mar 2, 2011 at 2:02 PM, Randall Hansen <randall@puppetlabs.com> wrote:> Good people ~ > > Role-based access will be one of the next big features in Dashboard. If this is something that would help you, will you tell me the minimum features that you would consider useful? That is, the features without which RBAC would be useless to you. > > I''m sure there''ll be disagreement; right now I''m just gathering requirements. Once we have feedback from multiple channels we''ll work on prioritizing and creating a roadmap. > > Thanks! > > r > > -- > Randall Hansen; Director of User Experience; randall@puppetlabs.com > > -- > You received this message because you are subscribed to the Google Groups "Puppet Users" group. > To post to this group, send email to puppet-users@googlegroups.com. > To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. > >-- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 tvaughan@onyxpoint.com -- This account not approved for unencrypted proprietary information -- -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Randall, sorry for the offtopic response, but our team needs a "write" API before RBAC. WIthout it Dashboard is a non-starter in our shop. As for your RBAC question, I envision a time when, through dashboard, you will be able to handle complex provisioning workflows, being able to give people execution, view and write access to all workflows, nodes, classes, variables and tasks. Also to be able to separately manage GUI access vs API access, while not critical, might be useful. I imagine a group of operators who can mix and match classes to make new node types through the UI, but can''t access the underlying code. (or some who can). Notification control would probably be something useful to RBAC. -Brian On Wed, Mar 2, 2011 at 2:02 PM, Randall Hansen <randall@puppetlabs.com>wrote:> Good people ~ > > Role-based access will be one of the next big features in Dashboard. If > this is something that would help you, will you tell me the minimum features > that you would consider useful? That is, the features without which RBAC > would be useless to you. > > I''m sure there''ll be disagreement; right now I''m just gathering > requirements. Once we have feedback from multiple channels we''ll work on > prioritizing and creating a roadmap. > > Thanks! > > r > > -- > Randall Hansen; Director of User Experience; randall@puppetlabs.com > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To post to this group, send email to puppet-users@googlegroups.com. > To unsubscribe from this group, send email to > puppet-users+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. > >-- <http://aws.amazon.com/solutions/solution-providers/brandorr/> -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Mar 2, 2011, at 3:51 PM, Frank Sweetser wrote:> In this scenario, it would be far more useful to simply use LDAP to verify usernames and passwords, and then consult internal records to assign a list of roles.This is a great use case, Frank. What do you mean by "internal records" in this context? Dashboard itself? Or another service at your site? r -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On 3/2/2011 7:42 PM, Randall Hansen wrote:> On Mar 2, 2011, at 3:51 PM, Frank Sweetser wrote: > >> In this scenario, it would be far more useful to simply use LDAP to verify >> usernames and passwords, and then consult internal records to assign a list >> of roles. > > This is a great use case, Frank. What do you mean by "internal records" in > this context? Dashboard itself? Or another service at your site?Originally I was thinking of within Dashboard, though of course some sites might find it more useful to have it in some other service. Use a central RADIUS server for authentication, and then a departmental LDAP server for role assignment, or a few records within Dashboard for small sites (here, for example, we''d only have three or four Dashboard users to manage). In the more flexible products I''ve used, you basically define a list of AAA servers, which can typically be RADIUS, LDAP or something internal to the application (obviously other things like an RSA token would also be applicable). You then get to pick a server for authentication, and one for authorization, independently of each other. That way, sites can easily set things up however works best for them, usually based on political boundaries as much as technical ones. -- Frank Sweetser fs at wpi.edu | For every problem, there is a solution that WPI Senior Network Engineer | is simple, elegant, and wrong. - HL Mencken GPG fingerprint = 6174 1257 129E 0D21 D8D4 E8A3 8E39 29E3 E2E8 8CEC -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Agreed on keeping auth and auth separately pluggable concerns. RADIUS and LDAP are also what I would like for authentication. We''d probably be OK with even an internal authorization system, since that''s what our other management apps use. -- O On Mar 2, 2011, at 5:01 PM, Frank Sweetser <fs@WPI.EDU> wrote:> On 3/2/2011 7:42 PM, Randall Hansen wrote: >> On Mar 2, 2011, at 3:51 PM, Frank Sweetser wrote: >> >>> In this scenario, it would be far more useful to simply use LDAP to verify >>> usernames and passwords, and then consult internal records to assign a list >>> of roles. >> >> This is a great use case, Frank. What do you mean by "internal records" in >> this context? Dashboard itself? Or another service at your site? > > Originally I was thinking of within Dashboard, though of course some sites might find it more useful to have it in some other service. Use a central RADIUS server for authentication, and then a departmental LDAP server for role assignment, or a few records within Dashboard for small sites (here, for example, we''d only have three or four Dashboard users to manage). > > In the more flexible products I''ve used, you basically define a list of AAA servers, which can typically be RADIUS, LDAP or something internal to the application (obviously other things like an RSA token would also be applicable). You then get to pick a server for authentication, and one for authorization, independently of each other. That way, sites can easily set things up however works best for them, usually based on political boundaries as much as technical ones. > > -- > Frank Sweetser fs at wpi.edu | For every problem, there is a solution that > WPI Senior Network Engineer | is simple, elegant, and wrong. - HL Mencken > GPG fingerprint = 6174 1257 129E 0D21 D8D4 E8A3 8E39 29E3 E2E8 8CEC > > -- > You received this message because you are subscribed to the Google Groups "Puppet Users" group. > To post to this group, send email to puppet-users@googlegroups.com. > To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. >-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On 2 March 2011 23:59, Trevor Vaughan <tvaughan@onyxpoint.com> wrote:> Beyond what Den pointed out, I would like to see either native (or > good instructions) support for authenticating with X.509 PKI > certificates. > > You would need to be able to specify: > > - The trusted CA chains > - The CRL/OCSP/SCVP connections > - What attribute/regex contains the username of the user > - An internal username mapping back to the role of the user (which > should be built in) > > This should be authoritative and passwords should be optional. > > Less important, but still nice, would be configuration instructions > for Kerberos with GSSAPI. > > Also, if pulling from LDAP, I would like to avoid custom schemas if at > all possible. It can be *really* hard to get Enterprise-type folks to > add schemas to their servers. >+1 for me for Kerberos authentication, AD integration would be a big bonus for my clients too. Jim :) -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Denmat wrote:> Very high level but I would like to see the following: > • to be able to create roles such as viewer, editor, administrator > • these roles be ldap groupsDen, will you tell me more about roles being LDAP groups? To my perception that could mean: * Manually creating a role in Dashboard and associating it with an LDAP group, * Importing groups from LDAP to then manipulate as roles in Dashboard, * LDAP groups being read-only in Dashboard and represented as roles, * something else I''ve not considered. Thank you, r -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Hi Randal, I think that about covers my thoughts too. The idea being I already have a qa- team group in ldap populated with some QA staff members. I would want then to have ''view'' access to say a web host group which might be a dashboard or ldap group of nodes. DBA ldap group would access the db nodes and web servers. For my admin team I would like whatever features that can alter the hosts or reports on all the hosts. Does that clarify? Cheers On 05/03/2011, at 7:23, Randall Hansen <randall@puppetlabs.com> wrote:> Denmat wrote: > >> Very high level but I would like to see the following: >> • to be able to create roles such as viewer, editor, administrator >> • these roles be ldap groups > > Den, will you tell me more about roles being LDAP groups? To my perception that could mean: > > * Manually creating a role in Dashboard and associating it with an LDAP group, > * Importing groups from LDAP to then manipulate as roles in Dashboard, > * LDAP groups being read-only in Dashboard and represented as roles, > * something else I''ve not considered. > > Thank you, > > r > > -- > You received this message because you are subscribed to the Google Groups "Puppet Users" group. > To post to this group, send email to puppet-users@googlegroups.com. > To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. >-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On 3 March 2011 06:02, Randall Hansen <randall@puppetlabs.com> wrote:> Role-based access will be one of the next big features in Dashboard. If > this is something that would help you, will you tell me the minimum features > that you would consider useful? That is, the features without which RBAC > would be useless to you. > > Everything everyone else has said plus audit logging of actions taken bythe user, and ways to report on that (even a "last x changes" on the node view) John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Mar 7, 2011, at 3:39 PM, John Warburton wrote:> Everything everyone else has said plus audit logging of actions taken by the user, and ways to report on that (even a "last x changes" on the node view)Yes, absolutely. RBAC is incomplete without good auditing. r -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On 03/07/2011 06:19 PM, Randall Hansen wrote:> On Mar 7, 2011, at 3:39 PM, John Warburton wrote: > >> Everything everyone else has said plus audit logging of actions taken by the user, and ways to report on that (even a "last x changes" on the node view) > Yes, absolutely. RBAC is incomplete without good auditing. > > r > >Ditto to all this. Our QSA will be a happier person... and that makes us all happy! Dave -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.