-
Notifications
You must be signed in to change notification settings - Fork 464
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
Optionally output AWS temporary credentials #859
Comments
Thanks for the time to submit this feature request, We do have the |
Thank you for your response. I'm sorry, for some reason I completely missed that (even after looking in code). However, this is not completely fixing the issue in our case (passing them from the step output to the job output) because the credentials are still marked as secrets from the following code: configure-aws-credentials/src/helpers.ts Lines 13 to 29 in fbaaea8
And, because they're marked as secrets, we are not allowed to output them from the job (check the example configuration in the initial message):
I think, in this case, we will need one more flag that allows the user to skip the |
I don't comfortable introducing this as an option, but if you need this and feel confident in a secure implementation and usage of this, there's nothing stopping you from using your own fork with this change implemented 🙂 |
I understand your concern, that's why I suggested adding it as an opt-in feature, with a warning message that indicates this might be a security vulnerability (similar to what the ecr-login action does about the docker-password).
There's no need to fork this project and invest in keeping it up-to-date as doing this manually with Workaround with aws-cli and jqjobs:
login-to-amazon:
name: Authenticate in AWS
steps:
- name: Assume Backup Role
id: backup-role
env:
AWS_ROLE_ARN: 'arn:aws:iam::[ACCOUNT-ID]:role/[ROLE-NAME]'
SESSION_NAME: 'backup-role'
SESSION_DURATION_SECONDS: '900' # 15 mins
run: |
credentials="$(aws sts assume-role --role-arn "$AWS_ROLE_ARN" --role-session-name "$SESSION_NAME" --duration-seconds "$SESSION_DURATION_SECONDS" --output json)"
access_key_id="$(echo $credentials | jq -r .Credentials.AccessKeyId)"
secret_access_key="$(echo $credentials | jq -r .Credentials.SecretAccessKey)"
session_token="$(echo $credentials | jq -r .Credentials.SessionToken)"
echo "access_key_id=$access_key_id" >> $GITHUB_OUTPUT
echo "secret_access_key=$secret_access_key" >> $GITHUB_OUTPUT
echo "session_token=$session_token" >> $GITHUB_OUTPUT
outputs:
access_key_id: ${{ steps.backup-role.outputs.access_key_id }}
secret_access_key: ${{ steps.backup-role.outputs.secret_access_key }}
session_token: ${{ steps.backup-role.outputs.session_token }} |
Exactly, I'm not comfortable with the idea of having this as an option. I'd love to trust that no one would ever slip up using it, but I can't. Masking these values is critical for the security of this workflow, I think to opt out of that the user needs to know what they're doing, and they can with a number of workarounds that don't take that long to setup (thanks for posting one that works for you) |
@valentindeaconu Thanks for the suggestion, but we're not interested in implementing this at this time. Credentials output this way could show up in debug logs and it would be too easy for people to accidentally compromise themselves - remember that logs for action runs on public repos are also public. This action exists to populate the standard environment variables that are recognized by the AWS SDKs and related tools; assuming an STS role and then doing other things with the keys like printing them to standard output are out of scope for us. If you need this functionality, you should implement it yourself. One way is with the AWS CLI like you mentioned. Another way might be to write your own simple SDK client and perform the AssumeRole call yourself. Regardless, because the workarounds are straightforward and because it would be too much of a security issue for some users of this action, we're going to close this. |
Comments on closed issues are hard for our team to see. |
Describe the feature
The action should support optionally exporting temporary AWS credentials to the output, so the job that is running the action can export them from the step output to the job output. In this way, we can collect them and pass them to a service container that is running for a subsequent job.
Use Case
We want to run our tests in GitHub Actions pipeline and we have a Docker image that provisions a temporary database. The database needs to be restored from a backup that is currently uploaded in a private S3 bucket. We run the database in a Docker service container and because we need to access the S3 bucket, we have to provide a set of AWS credentials. As we don't want to inject permanent credentials inside the image at build time, the only left solution would be to inject them at runtime from the container environment. In this case, we have two possible solutions: store a pair of permanent credentials in GA repository secrets and inject them at runtime OR generate a pair of temporary credentials by assuming a role in a previous job, then output the credentials from the job and fulfill them in the container environment.
Example configuration:
Proposed Solution
Add an opt-in flag that sets the credentials to the output (e.g.
output-temporary-credentials
). The flag should be marked with a warning that should inform the user that this is a security vulnerability and should be used with caution, similar to what the amazon-ecr-login action does.In this case (assuming a role and generating a pair of temporary credentials), the security risk of leaking credentials in GA logs is reduced as the credentials are set to expire in a given amount of time.
Other Information
As described above, for our use case only, there are some workarounds:
The first two "solutions" come with the disadvantage of being somewhat hard to rotate the credentials when needed; the third one would require a lot of effort in our case as we use the same image on multiple CI pipelines.
After having a look at the codebase, it looks like the action was built to export those credentials initially, but then the flag never made its way to the action input:
configure-aws-credentials/src/helpers.ts
Lines 31 to 41 in fbaaea8
To implement this feature, all we need to do is to connect an input flag to the
outputCredentials
parameter of theexportCredentials
helper method, and if this flag is set, output a warning message.Acknowledgements
The text was updated successfully, but these errors were encountered: