-
Notifications
You must be signed in to change notification settings - Fork 493
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
AWS_* credentials are persisted throughout the job steps #100
Comments
Hi @0mnius can you clarify for your sample workflow when you would expect the env vars to get unset?
|
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 - 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... |
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
|
@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. |
@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 |
@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 |
@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. |
Hmmm that's unfortunate, you should be able to explicitly unset them somehow, I would think... |
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
|
@0mnius is this still an issue? |
Note,
|
I think I have a similar issue in combination with the 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. |
@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. |
the unset step described above doesn't clean up the AWS_* env-vars.. just set to empty string.. It should be nice if add an input to logout like the |
The original post here has to deal with some confusion surrounding how long credentials last in a github action lifecycle. If you really need to get rid of your credentials before the end of the job, follow swinton's advice on how to get rid of the credentials. These last few comments are a slightly different topic. I'm not sure of a way to delete an environment variable completely in github actions. That might have to be done by another github action, but it cannot be directly supported by us unfortunately. |
This issue has not received a response in a while. If you want to keep this issue open, please leave a comment below and auto-close will be canceled. |
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 inactions/checkout
)?Here is the workflow snips i use in my yaml file:
Thanks in advance!
The text was updated successfully, but these errors were encountered: