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

Permit to inject file credential from master filesystem

    XMLWordPrintable

    Details

    • Similar Issues:
    • Released As:
      configuration-as-code-1.42

      Description

      Using JCasC in kubernetes/openshift container and injecting secrets to /run/secrets. Some of the secrets are binary blobs and hence are cumbersome to include in any other way but file secret. The problem is the requirement to base64 the content is impractical as it essentially require to intercept container creation and JCasC interpretation.

      To address that, I suggest to introduce an alternative for secretBytes that would read the content from a file directly (/run/secrets/FOO in this case), and would not require the content to be substituted inside the JCasC at all.

      Ex.:

      secretPath: "/run/secrets/FOO"
      

        Attachments

          Issue Links

            Activity

            Hide
            olivergondza Oliver Gondža added a comment -

            Fixed in configuration-as-code-1.42

            Show
            olivergondza Oliver Gondža added a comment - Fixed in configuration-as-code-1.42
            Hide
            jetersen Joseph Petersen added a comment -

            created a PR for a fix in JCasC configuration-as-code PR #1408

            Show
            jetersen Joseph Petersen added a comment - created a PR for a fix in JCasC configuration-as-code PR #1408
            Hide
            olivergondza Oliver Gondža added a comment -

            Thanks Jesse, let's see what CasC folks thinks of this: https://github.com/jenkinsci/configuration-as-code-plugin/issues/1219

            Show
            olivergondza Oliver Gondža added a comment - Thanks Jesse, let's see what CasC folks thinks of this: https://github.com/jenkinsci/configuration-as-code-plugin/issues/1219
            Hide
            jglick Jesse Glick added a comment -

            it "creates" the credentials at the time they are being used in the pipeline code. Any way to use it for system config or from non-pipeline jobs?

            Has nothing to do with Pipeline that I know of. When the credentials APIs to look up credentials are called, it loads them from a cache which is updated by a K8s watch.

            there does not seem to be a way to get JCasC to do the encoding of individual variable value

            Perhaps the simplest solution would be to just patch configuration-as-code to allow some special syntax for reading named files (optionally as Base64) in place of a literal string value. Lots of configuration systems have something like this, for example treating values starting with @ as a file load. E.g. amending plain-credentials-plugin/src/test/resources/org/jenkinsci/plugins/plaincredentials/ConfigurationAsCode.yaml:

            credentials:
              system:
                domainCredentials:
                - credentials:
                  - file:
                      id: secret-file
                      scope: SYSTEM
                      description: "Some secret file"
                      fileName: my-secret-file
                      secretBytes: "$base64file(/run/secrets/whatever)"
            

            IIUC JCasC is only available to administrators, so it is safe to allow file reads.

            Show
            jglick Jesse Glick added a comment - it "creates" the credentials at the time they are being used in the pipeline code. Any way to use it for system config or from non-pipeline jobs? Has nothing to do with Pipeline that I know of. When the credentials APIs to look up credentials are called, it loads them from a cache which is updated by a K8s watch. there does not seem to be a way to get JCasC to do the encoding of individual variable value Perhaps the simplest solution would be to just patch configuration-as-code to allow some special syntax for reading named files (optionally as Base64) in place of a literal string value. Lots of configuration systems have something like this, for example treating values starting with @ as a file load. E.g. amending plain-credentials-plugin/src/test/resources/org/jenkinsci/plugins/plaincredentials/ConfigurationAsCode.yaml : credentials: system: domainCredentials: - credentials: - file: id: secret-file scope: SYSTEM description: "Some secret file" fileName: my-secret-file secretBytes: "$base64file(/run/secrets/whatever)" IIUC JCasC is only available to administrators, so it is safe to allow file reads.
            Hide
            danielbeck Daniel Beck added a comment -

            Btw, would not simply requesting Administer permission in the @DataBoundSetter for the secretPath field get us secure with minimal implementation changes and minimal user-visible / automation irregularities?

            CLI commands create-credentials-by-xml and import-credentials-as-xml bypass all of that. As does POST config.xml to folder stores.

            Again, please read the old conversations around past issues.

            Show
            danielbeck Daniel Beck added a comment - Btw, would not simply requesting Administer permission in the @DataBoundSetter for the secretPath field get us secure with minimal implementation changes and minimal user-visible / automation irregularities? CLI commands create-credentials-by-xml and import-credentials-as-xml bypass all of that. As does POST config.xml to folder stores. Again, please read the old conversations around past issues.

              People

              Assignee:
              Unassigned Unassigned
              Reporter:
              olivergondza Oliver Gondža
              Votes:
              1 Vote for this issue
              Watchers:
              5 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: