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

Permit to inject file credential from master filesystem

    Details

    • Similar Issues:

      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

          Activity

          olivergondza Oliver Gondža created issue -
          Hide
          olivergondza Oliver Gondža added a comment -

          Jesse Glick, Daniel Beck, I would appreciate your thoughts and concerns before I hop on implementing this. Thanks!

          Show
          olivergondza Oliver Gondža added a comment - Jesse Glick , Daniel Beck , I would appreciate your thoughts and concerns before I hop on implementing this. Thanks!
          Hide
          danielbeck Daniel Beck added a comment -

          Looks a lot like https://jenkins.io/security/advisory/2019-10-16/#SECURITY-1583 https://jenkins.io/security/advisory/2019-05-21/#SECURITY-1322 https://jenkins.io/security/advisory/2018-06-25/#SECURITY-440 if not done well (and I'm unsure whether it can be done well at all).

          As you're in CERT I recommend you read up on those fixes and related discussions.

          Show
          danielbeck Daniel Beck added a comment - Looks a lot like https://jenkins.io/security/advisory/2019-10-16/#SECURITY-1583 https://jenkins.io/security/advisory/2019-05-21/#SECURITY-1322 https://jenkins.io/security/advisory/2018-06-25/#SECURITY-440 if not done well (and I'm unsure whether it can be done well at all). As you're in CERT I recommend you read up on those fixes and related discussions.
          Hide
          jglick Jesse Glick added a comment -

          This indeed sounds rather dangerous and I would not advise it.

          require to intercept container creation

          Using an init container?

          You can also use the kubernetes-credentials-provider plugin, though that has a different access control model: Jenkins requires a role binding to get secrets by name, rather than having specific secrets be injected. If you feel the need for an enhancement of this type, rather than patching Credentials implementations, it would be more appropriate to supply a CredentialsProvider which is able to load secrets from well-known locations in the container’s filesystem, or from locations configurable only by “administrators” (thus JCasC but not project developers).

          Show
          jglick Jesse Glick added a comment - This indeed sounds rather dangerous and I would not advise it. require to intercept container creation Using an init container? You can also use the kubernetes-credentials-provider plugin, though that has a different access control model: Jenkins requires a role binding to get secrets by name, rather than having specific secrets be injected. If you feel the need for an enhancement of this type, rather than patching Credentials implementations, it would be more appropriate to supply a CredentialsProvider which is able to load secrets from well-known locations in the container’s filesystem, or from locations configurable only by “administrators” (thus JCasC but not project developers).
          Hide
          olivergondza Oliver Gondža added a comment -

          Thanks for suggesting kubernetes-credentials-provider. The way I understand it, 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?

          Using an init container?

          It is not the problem to intercept container creation, but adding another layer of processing between container creation and JCasC execution. As there does not seem to be a way to get JCasC to do the encoding of individual variable value, it either have do be baked in to container build (so the automation that creates container needs to be aware which secrets happens to be later used as file type secrets which wires things I am glad that are separate) or done somehow inbetween.

          I like the idea of using CredentialsProvider to implement JCasC only credentials (that would be safe to read from filesystem, I presume), though that would impose changes to JCasC format (I understood it will not be in system store anymore). Meaning, all credentials are ok to be in system section, but the one that refers to master FS needs to be in different section.

          Thank you both for your inputs. I will dig deeper to see, which of these is reasonable feasible.

           

           

           

          Show
          olivergondza Oliver Gondža added a comment - Thanks for suggesting kubernetes-credentials-provider . The way I understand it, 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? Using an init container? It is not the problem to intercept container creation, but adding another layer of processing between container creation and JCasC execution. As there does not seem to be a way to get JCasC to do the encoding of individual variable value, it either have do be baked in to container build (so the automation that creates container needs to be aware which secrets happens to be later used as file type secrets which wires things I am glad that are separate) or done somehow inbetween. I like the idea of using CredentialsProvider to implement JCasC only credentials (that would be safe to read from filesystem, I presume), though that would impose changes to JCasC format (I understood it will not be in system store anymore). Meaning, all credentials are ok to be in system section, but the one that refers to master FS needs to be in different section. Thank you both for your inputs. I will dig deeper to see, which of these is reasonable feasible.      
          Hide
          olivergondza Oliver Gondža 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?

          Show
          olivergondza Oliver Gondža 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?
          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.
          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.
          olivergondza Oliver Gondža made changes -
          Field Original Value New Value
          Component/s configuration-as-code-plugin [ 23170 ]
          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

            People

            • Assignee:
              Unassigned
              Reporter:
              olivergondza Oliver Gondža
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated: