Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-60897

JEP-225: Folders-based access control for any credentials provider

    XMLWordPrintable

Details

    • JEP-225: Folders-based access control layer for any credentials provider

    Description

      Today the folders plugin provides an access control layer over its own local credentials provider. This works, but it means that if a user wants to restrict access to a particular credential by folder, they cannot store it in their preferred provider: instead they must copy it into the FolderCredentialsProvider.

      I would like to extend the plugin so that it can provide its access control layer (ACL) over any credentials provider.

      Benefits

      • Only write the access control logic once. Today, other providers would have to copy-paste the intricate ACL logic from the folders plugin, and then keep that up to date with any changes. Mistakes will inevitably be made.
      • It works the same way everywhere. Folders-based ACL will not have provider-specific behaviour, or a provider-specific storage schema for the ACL.
      • ACL can be written in JCasC YAML. Each folder entry just needs to have a list of allowed credential IDs.
      • Single Responsibility Principle. Providers do one thing: store and retrieve credentials. Folders plugin does one thing (for credentials): run the ACL over the providers.

      Tasks

      TODO convert these to sub-tasks

      • Design JCasC YAML schema for the ACL
      • Design Web UI for the ACL
      • Decide on default behaviour when folders plugin is present, a job accesses a credential, but no restrictions are configured for that credential:
        • Default allow? (Treat it as a global credential)
        • Default deny? (Don't ask, don't get)
      • Make ACL work with other folder types (GitHub/Bitbucket Organization Folders)
      • Deprecate/remove legacy bits of CredentialsProvider / CredentialsStore API that were meant to be used for access control (since it would not be their job any more)
      • Ensure ease of use with infrastructure tools like Terraform (it should be as simple as possible to have Terraform define Secrets Manager secrets, then interpolate the relevant IDs into the JCasC YAML).

      Attachments

        Issue Links

          Activity

            chriskilding Chris Kilding created issue -
            chriskilding Chris Kilding made changes -
            Field Original Value New Value
            Link This issue relates to JENKINS-60764 [ JENKINS-60764 ]
            chriskilding Chris Kilding made changes -
            Description Today the folders plugin provides an access control layer over its own local credentials provider. This works, but it means that if a user wants to restrict access to a particular credential by folder, they cannot store it in their preferred provider: instead they must copy it into the FolderCredentialsProvider.

            I would like to extend the plugin so that it can provide its access control layer (ACL) over *any* credentials provider.

            The benefits of this include:
             * *Only write the access control logic once.* Today, other providers would have to copy-paste the intricate ACL logic from the folders plugin, and then keep that up to date with any changes. Mistakes will inevitably be made.
             * *It works the same way everywhere.* Folders-based ACL will not have provider-specific behaviour, or a provider-specific storage schema for the ACL.
             * *ACL can be written in JCasC YAML.* Each folder entry just needs to have a list of allowed credential IDs.
             * *Single Responsibility Principle.* Providers do one thing: store and retrieve credentials. Folders plugin does one thing (for credentials): run the ACL over the providers.
            Today the folders plugin provides an access control layer over its own local credentials provider. This works, but it means that if a user wants to restrict access to a particular credential by folder, they cannot store it in their preferred provider: instead they must copy it into the FolderCredentialsProvider.

            I would like to extend the plugin so that it can provide its access control layer (ACL) over *any* credentials provider.
            h2. Benefits
             * *Only write the access control logic once.* Today, other providers would have to copy-paste the intricate ACL logic from the folders plugin, and then keep that up to date with any changes. Mistakes will inevitably be made.
             * *It works the same way everywhere.* Folders-based ACL will not have provider-specific behaviour, or a provider-specific storage schema for the ACL.
             * *ACL can be written in JCasC YAML.* Each folder entry just needs to have a list of allowed credential IDs.
             * *Single Responsibility Principle.* Providers do one thing: store and retrieve credentials. Folders plugin does one thing (for credentials): run the ACL over the providers.

            h2. Questions
             * JCasC YAML schema for the ACL
             * Default credential access behaviour when folders plugin is present, but no credential restrictions are configured for that credential:
             ** Default allow? (Treat it as a global credential)
             ** Default deny? (Don't ask, don't get)
             * Making ACL work with other folder types (GitHub/Bitbucket Organization Folders)
            chriskilding Chris Kilding made changes -
            Description Today the folders plugin provides an access control layer over its own local credentials provider. This works, but it means that if a user wants to restrict access to a particular credential by folder, they cannot store it in their preferred provider: instead they must copy it into the FolderCredentialsProvider.

            I would like to extend the plugin so that it can provide its access control layer (ACL) over *any* credentials provider.
            h2. Benefits
             * *Only write the access control logic once.* Today, other providers would have to copy-paste the intricate ACL logic from the folders plugin, and then keep that up to date with any changes. Mistakes will inevitably be made.
             * *It works the same way everywhere.* Folders-based ACL will not have provider-specific behaviour, or a provider-specific storage schema for the ACL.
             * *ACL can be written in JCasC YAML.* Each folder entry just needs to have a list of allowed credential IDs.
             * *Single Responsibility Principle.* Providers do one thing: store and retrieve credentials. Folders plugin does one thing (for credentials): run the ACL over the providers.

            h2. Questions
             * JCasC YAML schema for the ACL
             * Default credential access behaviour when folders plugin is present, but no credential restrictions are configured for that credential:
             ** Default allow? (Treat it as a global credential)
             ** Default deny? (Don't ask, don't get)
             * Making ACL work with other folder types (GitHub/Bitbucket Organization Folders)
            Today the folders plugin provides an access control layer over its own local credentials provider. This works, but it means that if a user wants to restrict access to a particular credential by folder, they cannot store it in their preferred provider: instead they must copy it into the FolderCredentialsProvider.

            I would like to extend the plugin so that it can provide its access control layer (ACL) over *any* credentials provider.
            h2. Benefits
             * *Only write the access control logic once.* Today, other providers would have to copy-paste the intricate ACL logic from the folders plugin, and then keep that up to date with any changes. Mistakes will inevitably be made.
             * *It works the same way everywhere.* Folders-based ACL will not have provider-specific behaviour, or a provider-specific storage schema for the ACL.
             * *ACL can be written in JCasC YAML.* Each folder entry just needs to have a list of allowed credential IDs.
             * *Single Responsibility Principle.* Providers do one thing: store and retrieve credentials. Folders plugin does one thing (for credentials): run the ACL over the providers.

            h2. Tasks
             * Design JCasC YAML schema for the ACL
             * Design Web UI for the ACL
             * Decide on default behaviour when folders plugin is present, a job accesses a credential, but no restrictions are configured for that credential:
             ** Default allow? (Treat it as a global credential)
             ** Default deny? (Don't ask, don't get)
             * Make ACL work with other folder types (GitHub/Bitbucket Organization Folders)
             * Deprecate/remove legacy bits of CredentialsProvider / CredentialsStore API that were meant to be used for access control (since it would not be their job any more)
             * Ensure ease of use with infrastructure tools like Terraform (it should be as simple as possible to have Terraform define Secrets Manager secrets, then interpolate the relevant IDs into the JCasC YAML).
            chriskilding Chris Kilding made changes -
            Issue Type Improvement [ 4 ] Epic [ 10001 ]
            chriskilding Chris Kilding made changes -
            Description Today the folders plugin provides an access control layer over its own local credentials provider. This works, but it means that if a user wants to restrict access to a particular credential by folder, they cannot store it in their preferred provider: instead they must copy it into the FolderCredentialsProvider.

            I would like to extend the plugin so that it can provide its access control layer (ACL) over *any* credentials provider.
            h2. Benefits
             * *Only write the access control logic once.* Today, other providers would have to copy-paste the intricate ACL logic from the folders plugin, and then keep that up to date with any changes. Mistakes will inevitably be made.
             * *It works the same way everywhere.* Folders-based ACL will not have provider-specific behaviour, or a provider-specific storage schema for the ACL.
             * *ACL can be written in JCasC YAML.* Each folder entry just needs to have a list of allowed credential IDs.
             * *Single Responsibility Principle.* Providers do one thing: store and retrieve credentials. Folders plugin does one thing (for credentials): run the ACL over the providers.

            h2. Tasks
             * Design JCasC YAML schema for the ACL
             * Design Web UI for the ACL
             * Decide on default behaviour when folders plugin is present, a job accesses a credential, but no restrictions are configured for that credential:
             ** Default allow? (Treat it as a global credential)
             ** Default deny? (Don't ask, don't get)
             * Make ACL work with other folder types (GitHub/Bitbucket Organization Folders)
             * Deprecate/remove legacy bits of CredentialsProvider / CredentialsStore API that were meant to be used for access control (since it would not be their job any more)
             * Ensure ease of use with infrastructure tools like Terraform (it should be as simple as possible to have Terraform define Secrets Manager secrets, then interpolate the relevant IDs into the JCasC YAML).
            Today the folders plugin provides an access control layer over its own local credentials provider. This works, but it means that if a user wants to restrict access to a particular credential by folder, they cannot store it in their preferred provider: instead they must copy it into the FolderCredentialsProvider.

            I would like to extend the plugin so that it can provide its access control layer (ACL) over *any* credentials provider.
            h2. Benefits
             * *Only write the access control logic once.* Today, other providers would have to copy-paste the intricate ACL logic from the folders plugin, and then keep that up to date with any changes. Mistakes will inevitably be made.
             * *It works the same way everywhere.* Folders-based ACL will not have provider-specific behaviour, or a provider-specific storage schema for the ACL.
             * *ACL can be written in JCasC YAML.* Each folder entry just needs to have a list of allowed credential IDs.
             * *Single Responsibility Principle.* Providers do one thing: store and retrieve credentials. Folders plugin does one thing (for credentials): run the ACL over the providers.

            h2. Tasks

            TODO convert these to sub-tasks
             * Design JCasC YAML schema for the ACL
             * Design Web UI for the ACL
             * Decide on default behaviour when folders plugin is present, a job accesses a credential, but no restrictions are configured for that credential:
             ** Default allow? (Treat it as a global credential)
             ** Default deny? (Don't ask, don't get)
             * Make ACL work with other folder types (GitHub/Bitbucket Organization Folders)
             * Deprecate/remove legacy bits of CredentialsProvider / CredentialsStore API that were meant to be used for access control (since it would not be their job any more)
             * Ensure ease of use with infrastructure tools like Terraform (it should be as simple as possible to have Terraform define Secrets Manager secrets, then interpolate the relevant IDs into the JCasC YAML).
            chriskilding Chris Kilding made changes -
            Component/s aws-secrets-manager-credentials-provider-plugin [ 25223 ]
            Component/s credentials-plugin [ 16523 ]
            Component/s kubernetes-credentials-provider-plugin [ 23531 ]
            chriskilding Chris Kilding made changes -
            Epic Name JEP-225: Folders-based access control layer for any credentials provider
            Labels JEP-225
            chriskilding Chris Kilding added a comment -

            JENKINS-58951 is to implement JCasC support for the folders plugin. This might need to be implemented before we can add the ACL on top.

            chriskilding Chris Kilding added a comment - JENKINS-58951 is to implement JCasC support for the folders plugin. This might need to be implemented before we can add the ACL on top.
            chriskilding Chris Kilding made changes -
            Link This issue relates to JENKINS-58951 [ JENKINS-58951 ]
            chriskilding Chris Kilding made changes -
            Summary Allow folders plugin to work with any credentials provider JEP-225: Allow folders plugin to work with any credentials provider
            chriskilding Chris Kilding made changes -
            Summary JEP-225: Allow folders plugin to work with any credentials provider JEP-225: Folders-based access control for any credentials provider
            chriskilding Chris Kilding made changes -
            Component/s aws-secrets-manager-credentials-provider-plugin [ 25223 ]
            Component/s kubernetes-credentials-provider-plugin [ 23531 ]

            People

              chriskilding Chris Kilding
              chriskilding Chris Kilding
              Votes:
              6 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

                Created:
                Updated: