On Wed, Feb 12, 2020 at 12:50 PM Chris Kilding <chris+jenk...@chriskilding.com> wrote: > I have encountered the following solutions which seem relevant, but I know > very little about them: > > - Cloudbees RBAC plugin (commercial)
https://docs.cloudbees.com/docs/admin-resources/latest/plugins/rbac a.k.a. `nectar-rbac` > - Role Strategy Plugin Also allows roles to be defined and then mapped to groups of users. At a high level, the main difference in design (as I understand it) is that `role-strategy` centralizes configuration at the system level, using pattern matching rules to make access control decisions; whereas `nectar-rbac` is oriented towards folder-level configuration (usually adding, but potentially also suppressing, permissions from the parent) and supports delegating further decisions to a folder-level administrator. More commonly used than either of these is the old `matrix-auth`, which also got folder-level support a few years back, and has a simpler configuration system (no concept of roles or synthetic groups). > - Jenkins permissions system A pretty complicated topic, as I am sure the JEP-223 developers will tell you! Very broadly, there is a `SecurityRealm` which defines authenticated users (subjects); a set of `Permission`s which define general operations (verbs); various `AccessControlled` objects such as `Job`s; and an `AuthorizationStrategy` which is a factory for `ACL`s, effectively granting or denying access to a given subject-verb-object triplet. https://jenkins.io/doc/developer/security/ gives a brief overview. We need more depth. > thoughts on how we might add concepts of folders and credentials to them As noted, folders are already well integrated with access control, and the authorization plugins can support plugin-contributed permissions. There are a couple of permissions already defined in the `credentials` plugin but I have never fully understood how they are intended to be used in context and I suspect few administrators have managed to set this up meaningfully. There is generally a lack of a clear notion in Jenkins of how builds, as opposed to directly user-initiated actions, should be authenticated and authorized, and in particular how this ought to interact with stored credentials. The `authorize-project` plugin offers one approach but it is not a good UX. The overall goal of the JEP draft—to decouple access control decisions about credential use from the physical storage layer—makes sense for at least some cases. I am not convinced it is the most natural way to consume Kubernetes credentials, since K8s has a native RBAC system and the `kubernetes` plugin can interact with namespaces and service accounts, though the existing `kubernetes-credentials-provider` basically treats K8s `Secret`s as a monolithic store (it assumes the Jenkins master process has permission to read them all) so you do no worse by using Jenkins ACL to make finer-grained decisions. I hope the above helped. I realize there are more questions than answers here: design options need to be explored. -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr0zj-i2xcg6X0rNit%3DzRuYQ5f7P_FFocbEPjE1Va_KNDg%40mail.gmail.com.
