Thank you to everyone who joined us on our webinar, the recording is now available.
Below are several of the questions we received during the webinar Q&A:
Q: How do you admin the groups? Manually or is this there LDAP involved?
A: You can decide if you want to create internal Jenkins users/groups or import users and groups from your LDAP server. In this case you can use the LDAP Jenkins plugin to import them but you still need to manage them manually using Jenkins. Each external group has to match an internal Jenkins group so that you can assign a role to it. Roles are defined in Jenkins regardless the origin of users and groups (internal or external).
Q: Is there any setting for views, instead folders? Are the RBAC settings available for views?
A: In short, yes. The RBAC plugin supports setting group definitions over the following objects:
Q: Are folders the only way to associate multiple Jenkins jobs with the same group?
A: The standard way in which you should associate multiple Jenkins jobs with the same group is through folders. However, remember that you can also create groups at job level.
Q: If we convert from the open source ‘role-based strategy’ plugin to this role-based plugin, will it translate the roles automatically to the new plugin?
A: Roles are not converted automatically, so you will need to set-up your new rules with the RBAC plugin.
Q: Who do we contact for more questions?A: You can contact us in the public mail firstname.lastname@example.org.
Q: How do you create those folders in Jenkins? Is this part of RBAC plugin, too?
A: Folders are created using the Folder plugin. The Folder plugin allows users to create new “jobs” of the type “folder.” The Role-Based Access Control plugin then integrates with this plugin by allowing administrators to set folder-level security roles and let child folders inherit parent folders’ roles.
Q: Is there a permission that allows a user see the test console steps (the bash cmds that are executed)?
A: You can define a role to only have read permission for a job configuration. In this way, users with that role will only be able to read the bash commands used in the job.
Q: Do you provide any sort of API to work with these security settings programmatically?
A: At this time, there is not any API to work with these security settings.
Q: Are there any security issues that one needs to take into consideration?
A: When configuring permissions for roles, be aware of the implications of allowing users of different teams or projects to have access to all of the jobs in a Jenkins instance. This open setup can occur when a role is granted overall read/execute/configure permissions.
While an administrative role would obviously require such overall access, consider limiting further assignment of those permissions to only trusted groups, like team/division leads.
Such an open setup would allow users with overall permissions to see information that you might rather restrict from them - like access to any secret projects, workspaces, credentials or scripts.
Overall configure permissions would also allow users to modify any setting on the Jenkins master.
Follow Valentina on Twitter.
Félix Belzunce is a solutions architect for CloudBees based in Europe. He focuses on continuous delivery. Read more about him on his Meet the Bees blog post and follow him on Twitter.
As a solutions architect, Tracy’s main focus is reaching out to CloudBees customers on the continuous delivery cloud platform and showing them how to use the platform to its fullest potential. Read her Meet the Bees blog post and follow her on Twitter.