Thanks to everyone who attended our webinar Running a Production Jenkins Instance: Setting Up Role-based Access Control on Thursday! Check out the webinar recording if you did not get a chance to attend live and are interested in advanced access control for your Jenkins installation. We also have a list of archived webinars on a variety of topics Jenkins and cloud.
Several questions came it at the end of the talk, so I am repeating them here for those of you who missed the live event, and adding a few links and details.
Q: What is the difference between Job/Read and Job/Discover permissions?
Most of the time you will only be interested in Read, which grants general ability to see a project (or folder): its status, list of builds, artifacts (unless you use -Dhudson.security.ArtifactsPermission=true !), and so on. Discover is implied by Read, but the interesting bit is when Read is denied, in which case the job would disappear from view. If Discover is also denied, then the user cannot even tell that a job of this name exists: Jenkins will just serve a 404 Not Found, as if there were a typo in the URL. But if Discover is granted, then the user will be informed that there is such a job that they simply are not permitted access. (An anonymous user will be prompted to log in.) So granting Discover is a bit less secure, but more friendly.
Q: What is the best way to use permissions with folders?
Once you have grouped one or permissions into a Role, you can create a Group on a folder and grant it that Role. This is additive permissions : the user has any permission at top level (or the parent folder), plus more. Or you can use the Filter feature in the RBAC plugin to subtract permissions from a folder.
Q: Is there any difference between the RBAC being demonstrated here in Jenkins Enterprise, and the RBAC in hosted Jenkins on CloudBees DEV@cloud?
No, it is the same plugin, though your DEV@cloud account might be running a different version (you can update it if you wish). One difference: to avoid catastrophic security leaks from a service on the public network, DEV@cloud Jenkins instances by default forbid any anonymous access even if your RBAC configuration would allow it. Anonymous Access to DEV@cloud Jenkins discusses how to override this.
Q: Talk a bit about the command line and permissions.
The Jenkins CLI is great for scripting access to Jenkins. Once you log in to the CLI, either using your API token or an SSH private key, the command runs in the context of your user account, just like anything done in the web UI. So for example, you can only start a build from the CLI if you have Job/Build permission. Similarly, if you are using the REST API to script Jenkins, your permissions are determined by the usual Jenkins security model, including RBAC.
Q: Are there best practices in using the RBAC plugin?
RBAC is designed to support a variety of usage models, but you may want to deny all permissions to anonymous users, and grant authenticated users at most Overall/Read permission. Then you can define roles and create groups to selectively add permissions to particular folders, which is generally simpler and safer than trying to filter permissions out. Just remember that to “see” some object such as a project, a user must have read permission on all containing objects (Jenkins and any parent folders): permissions are checked iteratively.
Q: Was your presentation just applicable to Jenkins Enterprise or can some features be found in open-source Jenkins also?
The RBAC plugin, which defines an advanced authorization strategy for Jenkins and which was the main topic for this webinar, is only available to Jenkins Enterprise licensees. (You can run it on top of any version of Jenkins you like, so long as you have a valid license.) Open-source Jenkins bundles some less powerful authorization strategies, and there are some alternative strategies available as open-source plugins in the update center. The security realm plugins, which authenticate you against e.g. LDAP, are open source.
Jesse Glick
Elite Architect and Engineer
CloudBees, Inc.
cloudbees.com
Prior to CloudBees, Jesse worked at a tiny company in Prague, making a Java IDE called NetBeans and weathering acquisitions by Sun and Oracle. He worked on the IDE's core module system and plugin tooling, and the project system including Ant and Maven integrations. He contributed to the extensive build system and the migrations from StarTeam to (open source) CVS to Mercurial. Along the way, he became an Ant, Maven and Mercurial committer, and of course...Jenkins. Jesse was one of the early Jenkins committers, developing the IDE integration. He co-authored an O'Reilly book on the NetBeans platform and has spoken on related topics.