Great suggestion, and indeed something we are starting to think about.

Do you happen to have any examples of plugins that take folder-scoped configuration? This would help to get started.

We are currently just using the CloudBees folder plugin, which allows you to scope credentials to a folder. But afaik it only works for secrets that are stored in Jenkins itself (i.e., the standard credentials provider). https://plugins.jenkins.io/cloudbees-folder

I had a poke around in the folder plugin - source code diving results below.

The classes of interest are FolderCredentialsProvider, AbstractFolder, and FolderCredentialsProperty.

When the provider is asked for credentials, it tests if the itemGroup is an AbstractFolder (or walks up the tree till it finds the nearest parent that is an AbstractFolder). Then it gets the credentials from the AbstractFolder's FolderCredentialsProperty (which just seems to be a holder class). The credentials are a plain old in-memory Map<domain, credentials>. Then it returns the credentials list, optionally filtered by domain.

It looks like the AbstractFolder is responsible for persistence of its components, on the Jenkins master's disk. The persistence structure looks like

• jobs/
  • foo/ (a normal job) 
  • <folder>
    • config.xml (folder-scoped config, including the serialized credentials)
    • jobs/
      • bar/ (a folder-scoped job)

This means that the folder plugin is not just an access control layer on top of the standard local disk credentials provider. Instead it has taken over credentials handling and persistence within folders, to the extent that it is its own credentials provider.

This design makes it harder for any third party credentials provider - not just this one - to integrate with the folders plugin.

There is a way to do it within the constraints of the current design, but it's not good.

AbstractFolder is public, and we do have access to the itemGroup in our own providers, so we could potentially do the same test on the itemGroup / walk up the tree, get the folder name, check that against something we can store in our credentials provider, and return a scoped list, and otherwise return the unscoped global credentials.

This is bad because:

• We would have to duplicate large amounts of folders plugin logic (and tests) in every credentials provider that wanted to support folder-scoped credentials. (Possibility for bugs to creep in, behaviour updates applied erratically across all providers etc.)
• We would be overloading credentials providers with responsibilities they shouldn't have. A provider should really have 1 purpose - store and retrieve a list of credentials - because this is already complex enough, especially with the retry/failure handling for remote providers.
• We would need the provider's data store to hold extra ACL metadata, which could make its storage schema more complicated, or could be a poor fit for some data stores.

I believe we are looking at some wider design changes like the following:

• The folders plugin stores and manages the ACL matrix (an association of credentials to folders).
• JCasC support to let the folders plugin read its ACL matrix from CasC YAML.
• FolderCredentialsProvider is either removed, or becomes a simple filtering proxy for other credential providers.
• (Optional) Remove ACL-related parameters like itemGroup from the CredentialsProvider getCredentials API.

I have started writing an epic for the work that would need to be done on the folders-plugin in JENKINS-60897. rittneje Could you take a look and comment with the kind of functionality you'd like to see?