Skip to content

Generating and using a JWT in a composite action #26309

Generating and using a JWT in a composite action #26309
Jun 9, 2022 · 3 answers

Howdy!

I am writing a composite action that first retrieves a JWT through a login-type api call, and then uses it as authentication bearer for curl. This works fine if done as a script in a Dockerfile. However in the composite action, there seems to be some expansion problem of the JWT. The line in question is here, and I would be glad if somebody can tell if my line of thinking is right or has some tips to tackle this.

Greetz,
Josef

TheYoctoJester:

Just a small follow-up - how does this compare to the output strategy that you mentioned? Up-/downsides?

Writing to GITHUB_ENV will make the token available to everything running in all later steps, including outside the composite action. Considering you’re handling an authentication token I’d consider that a security risk.

Well, and there’s the potential that something in the calling workflow also defined a JWT environment variable before and expects it to be available later.

Replies

3 suggested answers

Where is the JWT environment variable created? The only place I see it used otherwise is here:

  <a href="https://github.com/TheYoctoJester/mender-push-artifact/blob/69e1e612bb0c0cf62e65f1acafc4f643e7745842/action.yml#L22" target="_blank" rel="noopener">github.com</a>

TheYoctoJester/mender-push-artifact/blob/69e1e612bb0c0cf62e65f1acafc4f643e7745842/action.yml#L22

<pre class="onebox">      <code class="lang-yml">
    <ol class="start lines" start="12" style="counter-reset: li-counter 11 ;">
        <li>    description: 'URI for the hosted Mender backend account to be used'</li>
        <li>    required: false</li>
        <li>    default: 'https://hosted.mender.io'</li>
        <li>  mender_artifact:</li>
        <li>    description: 'path of the artifact to be uploaded, relative to GITHUB_WORKSPACE'</li>
        <li>    required: true</li>
        <li>runs:</li>
        <li>  using: "composite"</li>
        <li>  steps:</li>
        <li>    - id: get_access_token</li>
        <li class="selected">      run: JWT=$(curl -s -X POST -u ${{ inputs.mender_user }}:${{ inputs.mender_password }} ${{ inputs.mender_uri }}/api/management/v1/useradm/auth/login)</li>
        <li>      shell: bash</li>
        <li>    - id: show_environment</li>
        <li>      run: env</li>
        <li>      shell: bash</li>
        <li>    - id: show_GITHUB_WORKSPACE</li>
        <li>      run: tree $GITHUB_WORKSPACE</li>
        <li>      shell: bash</li>
        <li>    - id: upload_artifact</li>
        <li>      run: |</li>
        <li>        curl -s -X POST ${{ inputs.mender_uri }}/api/management/v1/deployments/artifacts \</li>
    </ol>
  </code>
</pre>

That’s in a different step though, which runs in a separate shell, so its variables are long gone by the time curl runs. The safest way to handle it is probably to set the token as a step output in the get_access_token step (maybe mask it, too?), and then use that output in the upload_artifact step.

0 replies

Thanks, yeah… the variable wasn’t being handled correctly. Being rather new to GA, coming from classic shell scripting. It seems to work now with the assignment being written into $GITHUB_ENV, and retrieved with ${{ env.JWT }}.

Just a small follow-up - how does this compare to the output strategy that you mentioned? Up-/downsides?

Thanks a lot!

0 replies
TheYoctoJester:

Just a small follow-up - how does this compare to the output strategy that you mentioned? Up-/downsides?

Writing to GITHUB_ENV will make the token available to everything running in all later steps, including outside the composite action. Considering you’re handling an authentication token I’d consider that a security risk.

Well, and there’s the potential that something in the calling workflow also defined a JWT environment variable before and expects it to be available later.

0 replies
Answer selected
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
2 participants