On Wed, Feb 12, 2020 at 12:50 PM Chris Kilding <[email protected]> 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr0zj-i2xcg6X0rNit%3DzRuYQ5f7P_FFocbEPjE1Va_KNDg%40mail.gmail.com.
