I plan to send data from my github-hosted runner to an external server. Is there a way to verify whether a request is coming from a GitHub action?
Context: I'm using this in a classroom setting with the help of GitHub classroom. In this scenario, each student's repository is automatically generated from skeleton code. I can include the workflow files with their skeleton code, but I can't create secrets that could have been used for verification.
I am not very clear of your scenario.
How did you send data from your github-hosted runner to an external server? Through webhook or something else?
Which data do you want to send? There are the github contexts list: https://help.github.com/en/actions/automating-your-workflow-with-github-actions/contexts-and-express...
>> I can include the workflow files with their skeleton code, but I can't create secrets that could have been used for verification.
Can you provide detail steps for it better with some screenshots ? How did you create secrets? Did you get any error message?
Do you have any other services to send grade info to external server? Would you like to share your workflow yml content here? When you send grade information during your github actions workflow run, you could try to add some keyworks for the external server to identify the source.
I'm thinking of just sending json data or something like that. There is a program I created inside the container that runs the grader and sends an http request to the external server. The problem I struggle with is security. I'm trying to find a way for the external server to verify whether the data comes from a github action or from somewhere else.
Initially I was thinking of using a secret, but because GitHub classroom creates student repo automatically, it's too much work for me to manually add secrets into eachh student repo. We're talking about 60-120 students per lab exercise I give.
If you are considering send http request to external server, you could add a specific string in the headers for external server to distinguish data source.
For some security reason, do you have firewalls in your external server? Do you need to add some IP range for github actions? There is the IP addresses of GitHub-hosted runners.
I'm glad you suggested those as I arrived to similar conclusions. It doesn't solve everything but it's a step in the right direction. Some limitations I see though:
1. Our github action needs to be public so that they can run in any student repository. Therefore, the program code contaning the string in the header is going to be publicly accessible (in the case of scripting languages like python). If I generate a binary to run the program so as to hide the string, people could similarly run the binary themselves. So I guess the part where we attach a specific string may not work that well. I wished there was a way to generate secrets automatically to address the issue, but that is something still in development (https://github.community/t5/GitHub-Actions/Github-Apps-to-add-secrets/m-p/28259)
2. As the IP range is for all of Azure, there is a possiblity that a non-github machine with the same IP range can send data to the server thereby fooling it.
Putting asside secrets used to upload a mark, if you're relying on a workflow running in the student's repository to generate the mark, you've essentially built a self assessment system.
Maybe it would be better having a system where the student requests that their work be marked, and some system out of their control assesses their work. You could still use Github actions to perform the assessment though, instead relying on a workflow running in a repository you control. For example, you could have a workflow starting with:
steps: - name: Check out the assessment harness uses: actions/checkout@v2 - name: Check out the student's code uses: actions/checkout@v2 with: repository: student/repo ref: master # or whatever revision you want to test path: ./under-test # where you want to put the student's work
Since the workflow is in a repository you control, you can easily make use of secrets. It could even be a private repo if needed.
That leaves the question of how to trigger the workflow for a particular student's work. From the look of it, "on: repository_dispatch" looks promising. This would let you trigger the workflow with a simple HTTP POST request with parameters like the repository name in the request body. As the dispatch API endpoint requires authentication, you can't easily have students call it directly. You would probably want some simple system that takes the repository as input, checks that it actually belongs to a student and then sends the appropriate trigger.