AWS_* credentials are persisted throughout the job steps

[0mnius]

Hello!

I can see that other actions in other steps are able to access AWS_* credentials set by aws-actions/configure-aws-credentials@v1:

Is there any flag like persist-credentials: false that i can use to unset those envars at the end of the step (like one in actions/checkout)?

Here is the workflow snips i use in my yaml file:

jobs:
  myjob:
    runs-on: windows-2016
    steps:

      # Do some stuff

      # Setup AWS CLI credentials
    - name: 'Configure AWS creds'
       uses: aws-actions/configure-aws-credentials@v1
       with:
         aws-access-key-id: ${{ secrets.MY_AWS_ACCESS_KEY_ID }}
         aws-secret-access-key: ${{ secrets.MY_AWS_SECRET_ACCESS_KEY }}
         aws-region: us-east-1

      # Publish to S3 
    - name: 'Copy to S3 bucket'
       run: |
         aws s3 cp ${{ github.workspace }}\foo\  s3://my-s3-bucket/bar/ --recursive --exclude "*" --include "*.baz"
       shell: pwsh

      # Send Slack notification
    - name: 'Slack channel notification'
       uses: 8398a7/action-slack@v3
       env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK_URL }}
       # other slack action config

Thanks in advance!

[clareliguori]

Hi @0mnius can you clarify for your sample workflow when you would expect the env vars to get unset?

• After the Configure AWS creds step and before the Copy to S3 bucket step?
• After the Copy to S3 bucket step and before the Slack channel notification step?
• At the end of the myjob job?

[0mnius]

Hi @clareliguori, thanks for a quick reply!

In my specific workflow i would either unite the aws steps and would expect the env vars to be unset after the run or at the end of the Copy to S3 bucket step:

    - name: 'Copy to S3 bucket'
       uses: aws-actions/configure-aws-credentials@v1
       with:
         aws-access-key-id: ${{ secrets.MY_AWS_ACCESS_KEY_ID }}
         aws-secret-access-key: ${{ secrets.MY_AWS_SECRET_ACCESS_KEY }}
         aws-region: us-east-1
         persist-credentials: false
       run: |
         aws s3 cp ${{ github.workspace }}\foo\  s3://my-s3-bucket/bar/ --recursive --exclude "*" --include "*.baz"
       shell: pwsh

or probably as a separate step in the workflow:

    - name: 'Configure AWS creds'
       uses: aws-actions/configure-aws-credentials@v1
       with:
         aws-access-key-id: ${{ secrets.MY_AWS_ACCESS_KEY_ID }}
         aws-secret-access-key: ${{ secrets.MY_AWS_SECRET_ACCESS_KEY }}
         aws-region: us-east-1

    - name: 'Copy to S3 bucket'
       run: |
         aws s3 cp ${{ github.workspace }}\foo\  s3://my-s3-bucket/bar/ --recursive --exclude "*" --include "*.baz"
       shell: pwsh

    - name: 'Unset AWS creds'
       uses: aws-actions/configure-aws-credentials@v1
       with:
         persist-credentials: false

I must admit that i'm still pretty new to the GH Actions world, so i hope this request does make sense in terms of the actions workflow design...

[clareliguori]

You can split your workflow into different jobs if you want a later step to have a "clean" environment. I believe this is the expected way to use Actions. Jobs do not share environment variables. For example (note the needs field to establish the order of the jobs:

jobs:
  myjob:
    runs-on: windows-2016
    steps:
      # Setup AWS CLI credentials
    - name: 'Configure AWS creds'
       uses: aws-actions/configure-aws-credentials@v1
       with:
         aws-access-key-id: ${{ secrets.MY_AWS_ACCESS_KEY_ID }}
         aws-secret-access-key: ${{ secrets.MY_AWS_SECRET_ACCESS_KEY }}
         aws-region: us-east-1

      # Publish to S3 
    - name: 'Copy to S3 bucket'
       run: |
         aws s3 cp ${{ github.workspace }}\foo\  s3://my-s3-bucket/bar/ --recursive --exclude "*" --include "*.baz"
       shell: pwsh

  notifyjob:
    runs-on: windows-2016
    needs: myjob
    steps:
      # Send Slack notification
    - name: 'Slack channel notification'
       uses: 8398a7/action-slack@v3
       env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK_URL }}
       # other slack action config

[allisaurus]

@0mnius does the guidance above make sense? We recently added an explicit cleanup step post-job, but your workflow will still need to be broken up like this to see its effects.

[0mnius]

@allisaurus, @clareliguori thank you for the suggestions, but isn't it a kind of a workaround to split and run on different runner? It makes the run a little bit longer ($). How complicated it to unset or maybe replace env vars with empty values? I tried this but couldn't actually make it work:

      # Unset AWS env vars
    - name: 'unset AWS env vars'
      uses: aws-actions/configure-aws-credentials@v1
      with:
        aws-access-key-id: null
        aws-secret-access-key: null
        aws-region: us-east-1

    - name: 'list all env vars after unset'
      run: |
        gci env: | Format-Table -Wrap -AutoSize
      shell: pwsh

    - name: 'dump ENV context'
      env:
        ENV_CONTEXT: ${{ toJson(env) }}
      run: echo "$ENV_CONTEXT"

      # test aws creds are actually unset
    - name: 'test aws creds'
      run: |
        aws s3 ls
      shell: pwsh

[allisaurus]

@0mnius I think your "unset AWS env vars" step will work if you pass in empty strings, vs. null (that's how we're executing the cleanup step).

Per Clare's comment, jobs are the recommended way to isolate environments within a workflow, which would address your use case. Though if it's more economical for you and you can make it work as intended, an "unset" step sounds like the right way to go. LMK if that helps

[0mnius]

@allisaurus unfortunately seems that it does not do the unset (probably they are set as read only?), i tried to unset with empty strings/dummy creds/tiny ducks :) but it didn't help

      # Unset AWS env vars
    - name: 'unset AWS env vars'
      uses: aws-actions/configure-aws-credentials@v1
      with:
        aws-access-key-id: ''
        aws-secret-access-key: ''
        aws-region: us-east-1

i was still able to get the s3 buckets list.

I eventually ended up splitting the next steps into separate jobs, so if you guys don't see this as security issue i'm ok to close it.

[allisaurus]

Hmmm that's unfortunate, you should be able to explicitly unset them somehow, I would think...
Glad to hear you're unblocked, but we'll investigate a bit more into why that doesn't work. Thank you for the additional info!

[clareliguori]

To unset the env var, you will need to directly use the GitHub Actions workflow commands to set the environment variables. This action won't unset them.

I haven't tested this, but something like this should work

    - name: Unset AWS creds env vars
      run: |
        echo '::set-env name=AWS_ACCESS_KEY_ID::'
        echo '::set-env name=AWS_SECRET_ACCESS_KEY::'
        echo '::set-env name=AWS_SESSION_TOKEN::'
        echo '::set-env name=AWS_DEFAULT_REGION::'
        echo '::set-env name=AWS_REGION::'

[piradeepk]

@0mnius is this still an issue?

[swinton]

I haven't tested this, but something like this should work

    - name: Unset AWS creds env vars
      run: |
        echo '::set-env name=AWS_ACCESS_KEY_ID::'
        echo '::set-env name=AWS_SECRET_ACCESS_KEY::'
        echo '::set-env name=AWS_SESSION_TOKEN::'
        echo '::set-env name=AWS_DEFAULT_REGION::'
        echo '::set-env name=AWS_REGION::'

Note, echo '::set-env' ... is deprecated, the equivalent now is echo "{name}={value}" >> $GITHUB_ENV , i.e.:

    - name: Unset AWS creds env vars
      run: |
        echo "AWS_ACCESS_KEY_ID=" >> $GITHUB_ENV
        echo "AWS_SECRET_ACCESS_KEY=" >> $GITHUB_ENV
        echo "AWS_SESSION_TOKEN=" >> $GITHUB_ENV
        echo "AWS_DEFAULT_REGION=" >> $GITHUB_ENV
        echo "AWS_REGION=" >> $GITHUB_ENV

[mpdude]

I think I have a similar issue in combination with the aws-actions/amazon-ecr-login action:

I'd like to login to ECR to pull Docker images, but will have to run untrusted code on the Action worker afterwards. Thus, I'd like to make sure at some point in my workflow that no sensitive information (access tokens and similar) are available anymore for subsequent workflow steps.

[mpdude]

@swinton's remark above sets the env vars to an empty value, but does not unset them.

Good enough to make sure sensitive values cannot be accessed anymore (e. g. when running untrusted code later on), but it might lead to other problems down the road if it makes a difference for programs whether a variable is empty or not set at all.