How to transfer secrets securely? #599

Open
opened 2024-09-10 19:22:52 +00:00 by forestscience · 6 comments
forestscience commented 2024-09-10 19:22:52 +00:00 (Migrated from gitea.com)

When running the runner locally, the only way to transfer secrets seems to be through the "-s" flag on the CLI. This is problematic, because then the secrets is kept on the history of the terminal. Is there any better way of doing this, through a file or so?

When running the runner locally, the only way to transfer secrets seems to be through the "-s" flag on the CLI. This is problematic, because then the secrets is kept on the history of the terminal. Is there any better way of doing this, through a file or so?
lunny commented 2024-09-11 03:13:46 +00:00 (Migrated from gitea.com)

The local mode should only be used on development machines. It’s not advisable to use it on a production machine. Additionally, even on development machines, it’s always better to hide sensitive information than to leave it exposed.

The local mode should only be used on development machines. It’s not advisable to use it on a production machine. Additionally, even on development machines, it’s always better to hide sensitive information than to leave it exposed.
forestscience commented 2024-09-11 05:58:44 +00:00 (Migrated from gitea.com)

@lunny I see that act_runner is based on nektos/act, and that support for "--secrets-file" (defaulting to .secret) has been in place since 4 years ago. What is the reason for removing this from act? I can make a pull request bringing in the corresponding code to support secrets from nektos/act, but I want to make sure I am not breaking any design principles or something like that.

@lunny I see that act_runner is based on nektos/act, and that support for "--secrets-file" (defaulting to .secret) has been in place since 4 years ago. What is the reason for removing this from act? I can make a pull request bringing in the corresponding code to support secrets from nektos/act, but I want to make sure I am not breaking any design principles or something like that.
forestscience commented 2024-11-09 07:34:54 +00:00 (Migrated from gitea.com)

@lunny ? Did you see my previous question? Depending on your answer I can try to put everything together.

@lunny ? Did you see my previous question? Depending on your answer I can try to put everything together.
lunny commented 2024-11-13 23:38:40 +00:00 (Migrated from gitea.com)

act_runner doesn't need to read the secrets in the file. The secrets will be transferred from Gitea to the task container.

act_runner doesn't need to read the secrets in the file. The secrets will be transferred from Gitea to the task container.
MoisMoshev commented 2024-11-14 07:02:53 +00:00 (Migrated from gitea.com)

act_runner doesn't need to read the secrets in the file. The secrets will be transferred from Gitea to the task container.
Indeed the secrets are available in workflows. By the way where does this transfer happen in the code, could you point me to the location?

> act_runner doesn't need to read the secrets in the file. The secrets will be transferred from Gitea to the task container. Indeed the secrets are available in workflows. By the way where does this transfer happen in the code, could you point me to the location?
forestscience commented 2024-11-16 09:41:34 +00:00 (Migrated from gitea.com)

@lunny What you say is true for whenever the workflow is being run through gitea, but I think that is not the case when I am running the workflow through a standalone runner locally. Whenever debugging workflows, is handy to have the possibility to do this locally.

@lunny What you say is true for whenever the workflow is being run through gitea, but I think that is not the case when I am running the workflow through a standalone runner locally. Whenever debugging workflows, is handy to have the possibility to do this locally.
Sign in to join this conversation.