If you read the source code, there’s actually a lot going on that you wouldn’t have known about if you didn’t take a look! More than that though, you don’t maintain the code that is running in that Action. For the “actions/checkout” action, that behind-the-scenes stuff lives in its own repo. That line that starts with “uses” means that there’s some work going on behind the scenes to get the code from your GitHub repo to the server that is running your workflow. The important part to consider is how it checks out your code. What could possibly be dangerous about that?” Uses: people probably think: “Well yeah, that just fetches my code. Almost all workflows begin with a step like the one below: - name: Check out repository Typically, when people make their own workflows on GitHub, they use Actions made by someone else. In contrast, defining them at the job level will make them available to all stages, including potentially compromised code (more on that later). To limit the scope of environment variables, you should always declare them at the step level, so that they won’t be accessible to other stages. This principle applies to environment variables as well. The set of permissions required to call each endpoint of the GitHub API is extensively documented, and you should verify what the default permissions are to match and adjust them. This will allow fine-grained control over the privileges of your GitHub Actions. You should make use of the ‘permission’ key in your workflows to configure the minimum required permissions for a workflow or job. Whether you choose one option or the other, the GITHUB_TOKEN should always be granted the minimum required permissions to execute a workflow/job. In either case, forked repos only have, at most, a read-access. It is temporary, meaning its validity start and ends with the workflow.īy default, the token’s permissions are either “permissive” (read/write for most of the scopes) or “restricted” (no permission by default in most scopes). This token is granting each runner privileges to interact with the repository. This is a general security principle for all the credentials used by your workflow, but let’s focus on a GitHub-specific one: the GITHUB_TOKEN. Let’s dive into the best practices: Set minimum scope for credentials This cheat sheet is here to help you mind the risks posed by some GitHub Action workflows, no matter if you are maintaining open-source projects or not. Sounds scary? Maybe, but far from impossible! This is why it is recommended that developers always check the code before downloading new third-party apps and set up billing alerts if necessary to avoid unexpected costs. Nightmare scenario: imagine a malicious GitHub Action stealing secrets passed to the CI is published in the GitHub Marketplace to mine cryptocurrencies. A step can be a shell script or an action, which is a reusable piece of code specially packaged for the GitHub CI ecosystem.īecause GitHub is hosting millions of open-source projects that can be forked and contributed to through pull requests, GitHub Actions security is paramount to prevent supply-chain attacks. For instance, they can be used to format the code, format the PR, sync an issue's comments with another ticketing system’s comments, add the appropriate labels to a new issue, or trigger a full-scale cloud deployment.Ī workflow is made of one or more jobs, which are run inside their own virtual machine or container (a runner), that execute one or more steps. Actions are triggered by GitHub events (a pull request is submitted, an issue is opened, a PR is merged, etc…) and can execute pretty much any command. It’s the mechanism used to run workflows from development to production systems. GitHub Actions is GitHub’s CI/Cd service.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |